sharkasmAT A GLANCE
- Manage service and resource inventories through TMF638 and TMF639 interfaces.
- Work with service and resource catalogs, geographic addresses, sites, and locations.
- Support IPAM, discovery and reconciliation, inventory history, and topology.
- Provide a React administration interface and MCP access to inventory workflows.
01 / 08
An operational model of resources and services
OneInventory brings resource, service, geographic, and IP-address information into a modular inventory platform. Its role is to make network objects and their relationships usable by the applications and people that depend on them. A resource list is useful, but the larger operational question is how the listed objects support services, occupy locations, and relate to other parts of the environment.
The platform combines service and resource inventory, catalogs, IPAM, discovery and reconciliation, topology, and history with an administration interface. It also exposes inventory capabilities to agent clients through MCP. These functions give the portfolio a concrete foundation for discussing what exists and how that information can be consumed.
02 / 08
Distinguish instances from specifications
OneInventory includes service and resource catalogs alongside inventories. The catalogs hold definitions that can be referenced by the corresponding operational records. The inventories represent service and resource instances. This distinction helps consumers understand whether they are looking at a type of thing that can exist or an actual thing represented in the environment.
That separation matters in service operations. A catalog definition can describe an available resource or service concept, while the inventory record carries its instance-specific information and relationships. Consumers need both perspectives when interpreting an assignment or investigating a mismatch. Clear definitions and explicit references make the model easier to use across applications that otherwise might maintain different local descriptions of the same concept.
03 / 08
Expose resource and service information through APIs
The platform provides resource inventory and service inventory interfaces associated with TMF639 and TMF638, alongside catalog and geographic functions. A consumer can use the appropriate application boundary instead of depending directly on internal database structure. This makes the inventory’s responsibilities visible at the interface level.
The documented implementation uses modular FastAPI services behind a gateway with PostgreSQL as the principal persistence layer. The important architectural point is the relationship between capability and interface: resource operations, service operations, catalog operations, and geographic information have identifiable places in the system. A consumer can therefore discuss its data needs in domain terms rather than treating inventory as a single undifferentiated store.
04 / 08
Add geographic and addressing context
Addresses, sites, locations, IP address blocks, and other assignment information connect an inventory object to the environment in which it is used. These details matter when a service question begins with a location or network assignment rather than a known device identifier. They provide additional routes through which a consumer can locate the relevant resources.
OneInventory includes geographic inventory and platform IPAM capabilities in its documented service set. Bringing these domains together supports a more complete operational picture. The design conversation still needs clear ownership of each fact and a definition of the relationships between objects. The value comes from those relationships being meaningful, rather than simply increasing the number of fields attached to a resource record.
05 / 08
Reconcile observations with inventory knowledge
Discovery and reconciliation are part of the platform’s capability set. They address the relationship between information observed in the environment and information maintained in inventory. The engineering challenge is to decide how an observation should affect an existing record, which identity it refers to, and what evidence supports the resulting view.
An inventory is most useful when consumers can understand where its information came from and how it changes. Reconciliation is therefore related to history as well as current state. A team investigating a discrepancy needs to know whether it is seeing an assignment, a discovered observation, or a change that has already been interpreted by another process. The platform provides a place to organize these concerns within the inventory domain.
06 / 08
Make relationships visible through topology
Topology adds a relational view to the inventory experience. Instead of considering each object independently, an operator can examine how resources and services connect. Graph-oriented capabilities and optional Neo4j infrastructure are part of the broader platform documentation and the surrounding inventory discussions.
The useful distinction is between inventory relationships and analytical scenarios. OneInventory represents resources and the relationships used by operational consumers; Digital Twin provides a separate environment for modeled analysis and what-if work. They are complementary responsibilities. Keeping that distinction visible helps avoid assuming that an inventory graph alone answers every question about modeled network behavior or that a model should become the owner of every operational inventory fact.
07 / 08
Support both operators and connected tools
The React administration interface provides a human-facing route to the platform’s capabilities. API consumers use the service interfaces, and MCP exposes inventory workflows to agent clients. These are different ways to interact with the same domain responsibilities. The product experience can therefore support direct investigation as well as integration into a larger operational workflow.
For example, a configurable diagnostic agent may need inventory context before selecting the next technical lookup. The inventory service provides the relationship information; the agent decides how to use it within its configured task. This separation keeps the source of inventory knowledge identifiable and avoids hiding the inventory’s role inside the reasoning behavior of an unrelated application.
08 / 08
Follow a resource-to-service inquiry
An illustrative inquiry starts with a known resource or location and asks which service context is relevant. The user locates the record, examines its relationships, checks the applicable service and catalog information, and considers the history or reconciliation context if the view appears inconsistent. The result is a more precise starting point for the next operational step.
OneInventory’s place in the portfolio is foundational: OSS/BSS processes need resource and service context; access investigations need equipment assignments; data consumers need stable identifiers; network modeling needs a clear relationship to operational knowledge. The platform concentrates these concerns into an inventory capability that people, applications, and agents can use through explicit interfaces and an understandable domain model.
LET’S MAKE THE CONNECTION
Put this experience
to work.
Bring your requirements, your operating context, and the question you want to answer.
Discuss OneInventory ↗