Feature

AI-Assisted Twin Generation

Turn engineering intent, specs, and documentation into structured digital twin models that can be reviewed, run, and improved.

Why this capability matters

Creating a useful digital twin usually starts with incomplete material: system requirements, protocol notes, interface assumptions, vendor documentation, and engineering comments spread across multiple sources. The slow part is not only writing the model. The slow part is turning that fragmented input into a structured starting point that engineers can actually review, run, and improve.

SPX uses AI-assisted twin generation to shorten that first phase. Instead of hand-building the first model from scratch, teams can generate a reviewable twin draft that already reflects expected structure, interfaces, behaviors, and protocol surfaces.

Input problem

Requirements arrive as engineering text, not as runnable twins

Specifications and design documents describe intent, but they do not give software teams a runtime-ready model to validate against.
Modeling problem

Manual first-pass modeling slows every integration project

Teams lose time translating documents into attributes, actions, states, scenarios, and protocol mappings before testing can even begin.
Validation problem

Protocol expectations need to become explicit early

If communication assumptions stay implicit, integration bugs only show up later when clients finally meet real devices or gateways.
SPX approach

Generate a draft twin first, then refine it as an engineering artifact

SPX treats generated output as a structured starting point for review, iteration, runtime execution, and automation instead of a hidden black box.

What SPX generates

The goal is not to auto-write marketing copy around a model. The goal is to produce a twin draft that already has the right engineering shape, so teams can move faster into review, runtime testing, and protocol validation.

Model structure

Twin entities and interfaces

SPX can derive the initial model layout, component boundaries, exposed interfaces, and device relationships from the available engineering input.
Communication

Protocol-facing surfaces

Generated twins can be shaped around expected protocol endpoints and message flows so later runtime validation stays grounded in real integration behavior.
Behavior

Actions, state, and conditions

The first model draft can include state changes, command behavior, and operating assumptions that engineers later tighten and validate.
Output

Reviewable, code-defined twin models

Generated output remains structured and inspectable, so teams can version it, refine it, compare it, and reuse it in automation workflows.

Core capabilities

This page should read as a concrete product capability, not as a generic AI claim. The important part is how SPX helps engineers move from documentation to a twin that can be run and improved inside the same platform.

Generation

Generate twins from engineering inputs

Start from documentation, specifications, protocol notes, and system requirements instead of waiting for a fully hand-written model.
Normalization

Turn fragmented inputs into one structured modeling baseline

SPX helps consolidate multiple design sources into a single twin draft with explicit interfaces, behaviors, and assumptions.
Runtime continuity

Move directly from generated model to executable twin

The generated draft is meant to become part of a runtime workflow, not remain a disconnected design artifact or throwaway prototype.
Refinement

Keep the twin editable for engineers and automation pipelines

Teams can inspect, refine, and operationalize the generated twin as requirements evolve, protocols change, or new scenarios must be validated.
SPX dashboard view showing generated twin runtime and validation workflow.

A generated twin should not stop at model text. In SPX, the same twin can move into runtime execution, observation, and test workflows.

From draft twin to runtime twin

The useful pattern is simple: generate, review, connect, refine. That makes this capability usable both for early design work and for later validation flows.

Step 01

Start from source material

Bring in requirements, documentation, protocol notes, and architecture assumptions as the basis for the first twin draft.
Step 02

Review the generated model

Engineers validate the generated structure, states, actions, and interface assumptions before the model becomes part of the workflow.
Step 03

Attach protocol behavior

Map the twin to concrete protocol surfaces such as Modbus, OPC UA, BACnet, KNX, or MQTT when the scenario requires it.
Step 04

Run and improve in context

Use the twin in runtime observation, scenario validation, and automation flows, then keep refining it as the system matures.

Protocol-ready targets

AI-assisted generation is most useful when it helps teams get to concrete integration targets faster. In SPX, generated twins can become the starting point for runtime validation against the protocols you actually need to simulate and test.

Developer path

Generated twins are most valuable when engineers can inspect and reuse them. That is why this capability should connect directly to model language, examples, and developer workflows rather than ending at a static page.

Next step

Use generated twins as the start of a real validation workflow

The strongest version of this feature is not generation alone. It is generation tied to runtime behavior, protocol surfaces, developer workflows, and repeatable validation.