sharkasmAT A GLANCE
- Create network workspaces and initialize model images from configuration bundles.
- Fork images to investigate changes without altering the original model.
- Query equipment and interfaces; visualize topology and packet paths with traceroute analysis.
- Export reports and expose model workflows to agents through MCP; use optional Neo4j replicas for approved images.
01 / 08
A working representation of the network
Digital Twin provides a place to build, analyze, and operate network models. Configuration bundles become images inside isolated network instances. Engineers can query those images, inspect equipment and interfaces, visualize topology and packet paths, and create divergent images for what-if analysis. The result is a concrete workspace for investigating network behavior before translating a finding into an operational decision.
The distinction between a model and the live network remains useful throughout the experience. An image represents a particular analytical context. A new scenario can be examined as its own image, preserving the original for comparison. This makes it easier to discuss exactly which configuration, model state, and assumptions support a conclusion.
02 / 08
Organize the work around instances and images
An instance is an isolated network workspace. An image is the model context selected within that workspace. The interface keeps this selection visible as users move between dashboards, queries, topology, path visualization, file workflows, and reports. That continuity reduces the risk of discussing one model while looking at results from another.
Images also provide the foundation for controlled experimentation. Rather than modifying a baseline without a reference, an engineer can fork an image and investigate changes in the resulting branch. The baseline, the proposed variation, and the outputs from each remain conceptually distinct. This is a particularly valuable structure when several people need to review the same change and understand what was actually compared.
03 / 08
Bring configuration into a navigable model
The platform initializes model images from configuration bundles. A File Manager experience supports working with those inputs, and a separate configuration gateway can expose approved configuration roots through the backend. The intention is to make the model’s input context accessible without turning the browser into an unrestricted filesystem client.
Once an image is available, users can inspect the equipment and interfaces represented in it. These are the building blocks for more specific questions about connectivity and paths. A useful investigation begins by confirming the relevant objects and their context, then narrows toward the behavior being examined. The model becomes a navigable engineering resource instead of an opaque calculation behind a single visualization.
04 / 08
Ask questions at the right level
Digital Twin includes a catalog of model queries and visualizations for topology and traceroute analysis. These let an engineer move from a broad view of the network to a focused question about a device, interface, or path. Query results are associated with the selected instance and image, maintaining the context needed to interpret them.
Path analysis makes the model tangible. Instead of stopping at a diagram that says two objects are connected, the engineer can investigate the modeled path relevant to a packet or scenario. The important result is the evidence produced by the model and the inputs that led to it. A clear review preserves those inputs alongside the result so another engineer can understand the same reasoning.
05 / 08
Use scenarios to make change review concrete
A representative workflow starts by selecting a baseline image and identifying the traffic or connectivity question that matters. The engineer creates a divergent image, introduces the intended configuration change within the modeling workflow, and runs relevant queries against the two contexts. The outputs can then be compared and discussed with the operational team.
For example, a routing adjustment may deserve investigation of the paths represented before and after the change. The modeled result informs review; operational validation still belongs to the live change process. This separation is part of the value of a digital twin: it gives a team a repeatable way to investigate a proposal while keeping the analytical scenario and the production action clearly identified.
06 / 08
Separate product workflows from the model engine
The application is organized around a React interface, a FastAPI backend, platform state in PostgreSQL and Redis, and background workers for longer-running work. Interaction with the underlying model engine passes through a dedicated private adapter. This allows the rest of the application to deal in product concepts such as instances, images, queries, jobs, and reports.
That boundary supports a coherent user experience. A model query does not need to expose the engine’s internal vocabulary to every consumer. The backend can manage access, audit, query history, and job behavior through its own application interface. Longer-running tasks can surface progress to the user rather than making a complex analytical operation appear as an unexplained pause.
07 / 08
Connect topology and agent-assisted workflows
The optional realtime sidecar maintains approved image replicas in Neo4j. This gives the portfolio a graph-oriented representation alongside the model workflow. It is useful to distinguish the approved model being represented from future modeling extensions or additional network layers: the graph is most valuable when its relationships have a clear meaning and provenance.
The separate MCP server exposes product workflows through the backend API. Agent clients can therefore work through the same application boundary used by other consumers. Backend access controls, jobs, audit records, query history, and reports remain the authoritative product mechanisms. This creates a bridge to agent-assisted analysis without requiring an agent to bypass the application and operate directly on its internal stores.
08 / 08
Turn investigation into reusable evidence
The platform supports exporting analytical results as reports, with documented output formats including PDF, CSV, spreadsheet, document, and Markdown representations. Different audiences need different presentations: an engineer may want structured results, while a review meeting may need a readable account of the scenario and its implications.
A useful handoff connects the original question, the selected instance and image, the queries performed, the resulting evidence, and the decision still to be made. Digital Twin’s contribution to the wider portfolio is this chain of context. OneInventory addresses resources and relationships; observability addresses operational signals; Digital Twin provides a structured environment for investigating modeled behavior. Together, those perspectives help a team move from knowing what exists to understanding how a proposed change should be examined.
LET’S MAKE THE CONNECTION
Put this experience
to work.
Bring your requirements, your operating context, and the question you want to answer.
Discuss Digital Twin ↗