Stage 1 of 7
System definition
The RBU (Responsible Business Unit) defines what the product must be — top-down, before any engineering begins. Requirements, interfaces, key items, and system attributes are captured formally in the SysML v2 model. This is the single source of truth that governs every downstream decision.
System requirementsrequirement def
Key system itemsitem def
System attributesattribute def
Packages & namespacespackage
Interface definitionsinterface def
Handover to architecture
Verified item def tree + requirement def set constitute the formal input contract for the architecture team. No design work begins until this contract is signed off.
AI governance at this stage
Parses the SysML v2 package into an AST via ANTLR — the model becomes machine-readable
Verifies completeness of requirement defs: no orphaned requirements, all attributes typed
Chases RBU stakeholders for missing item definitions before the architecture clock starts
Creates dependency map: which item defs are prerequisites for which architecture contracts
Stage 2 of 7
System architecture
Systems architects decompose the system into functional blocks, define how they connect, and allocate requirements to parts. The abstract item definitions from Stage 1 are elaborated into concrete part definitions with typed ports and connections. This is the structural blueprint.
Functional blockspart def
Block connectionsconnection def
Typed portsport def
Requirement allocationsatisfy
Function decompositionaction def
Receives from Stage 1
item def + requirement def package — the formal input contract
Handover to design teams
Verified part def decomposition with typed port defs and connection defs. Each part def carries the requirements it must satisfy — this becomes the engineering contract for electronics and mechanics.
AI governance at this stage
Traces every requirement def to at least one satisfy relationship — flags uncovered requirements
Validates port compatibility: connected ports must have matching interface types
Generates the dependency graph of part defs — identifies critical path blocks
Monitors architecture contract completion and alerts when a part def is missing a port spec
Stage 3 of 7
Electronics & mechanics design
Engineering teams take the part definitions from architecture and instantiate them — placing specific components, designing the PCBA schematic and layout, defining mechanical housing. Each physical realisation is expressed as a part usage in the model, making it traceable to its definition and requirements.
Physical instantiationpart usage
Port instanceport usage
Connection instanceconnection usage
Item flowitem usage
Simulation modelaction usage
Receives from Stage 2
part def + port def + connection def — the engineering contract
Handover to Gate Review G1
Complete part usage tree — every physical component instantiated, every connection realised, PSpice simulation results linked as action usage outcomes. This is what Gate 1 verifies.
AI governance at this stage
Tracks which part defs have been instantiated as part usages — chases outstanding assignments
Cross-checks PCBA BOM against the part usage tree: no component without a model anchor
Parses PSpice netlist and links simulation results back to the relevant action usage nodes
Validates electronics/mechanics interface contracts: mechanical envelope matches port usage specs
Gate Review — G1
Design gate
AI reads the live SysML v2 model and evaluates all design-phase contracts against defined gate criteria. Every check is traceable to a model element — not a slide, not a meeting note. The verdict is model-derived and objective.
All requirement defs covered by a satisfy relationship — no orphaned requirements
All part defs instantiated as part usages in the design model
PSpice simulation results linked and within specified operating envelopes — verified via action usage outcomes
All port usage connections verified: type-compatible, no dangling ports
Electronics / mechanics interface contracts signed off — dimensional and electrical envelopes met
When all checks resolve, AI issues a model-based gate verdict. Fail items are returned with model element references — not comments. Responsible parties are automatically notified with the exact contract that is unresolved.
Stage 4 of 7
Verification & test
The test team works against explicit verification cases that are part of the model. Every test is linked to the requirement it covers via a verify relationship. Test results feed back into the model, closing the loop between design intent and physical reality.
Test casesverification case def
Test–requirement linkverify
Concern captureconcern
Requirement coveragesatisfy
Test resultsanalysis case def
Receives from Stage 3 (post G1)
Verified part usage tree + simulation results. Gate 1 verdict confirms design is ready for physical test.
Handover to assembly
Complete verification case def results with all verify relationships resolved. Every requirement has at least one passing test result linked in the model.
AI governance at this stage
Generates the verification coverage matrix from the model: which requirements have test cases, which don't
Tracks test execution status per verification case def — chases test team for overdue results
Flags requirements with no verify relationship — these are coverage gaps, not oversights
When a test fails, AI traces impact: which part usage, which requirement def, which contracts are now at risk
Stage 5 of 7
Assembly & variants
AI assembles valid system configurations from the SysML v2 variant catalog. Variation points define where the product family branches; variant definitions constrain which combinations are valid. AI resolves these constraints and produces a verified BOM for each configuration.
Product variantsvariation point
Valid configurationsvariant
Part compositionpart usage
Part catalogpart def
Assembly sequenceaction def
Receives from Stage 4
Verified verification case def results confirming all tested configurations meet requirements
Handover to Gate Review G2
Complete variant matrix: all variation points resolved, verified BOMs per variant, assembly sequences validated. This package enters Gate 2.
AI governance at this stage
Reads variation points and variant definitions from the model — generates all valid configurations
Checks each variant BOM against part availability and test coverage: no configuration ships without a verify result
Detects constraint violations in variant combinations before physical assembly begins
Produces model-derived assembly instructions by sequencing the part usage tree topologically
Gate Review — G2
Assembly gate
AI verifies the complete assembly and test package. All variants must be traceable through the model from requirement def to verified configuration. No configuration proceeds to production preparation without a clean gate.
All variation points resolved — no open branches in the variant tree
Every variant has a verified BOM and at least one passing verification case def result
Full verify coverage: every requirement def covered in at least one tested variant
Assembly sequences validated against action def ordering constraints — no dependency violations
Gate 2 verdict is issued per variant — a configuration can pass while another remains open. Responsible engineers for failing variants are identified from the model's ownership allocations and automatically notified.
Stage 6 of 7
Production preparation
Manufacturing sequences, work instructions, and tooling specifications are derived from the model. Assembly actions are allocated to manufacturing steps. The model is locked for production — any change now triggers a formal impact analysis before the production model is updated.
Manufacturing allocationallocation
Process flowaction usage
Work instruction itemsitem usage
Resource bindingpart usage
Config baselinepackage
Receives from Stage 5 (post G2)
Verified variant BOMs + assembly gate verdict. Production package is model-derived — no manual transcription of BOM data.
Handover to Gate Review G3
Production-ready model baseline: all manufacturing allocations resolved, work instructions linked via action usage, model version locked. This is what G3 audits.
AI governance at this stage
Derives work instructions by traversing the action usage graph — sequence is model-mandated
Any engineering change order triggers model-based impact analysis before production model is touched
Monitors production readiness: tooling allocations, supplier contracts, lead times — all linked to model elements
Locks the model package for production and tracks all change requests against this baseline
Gate Review — G3
Release gate
The final model-based gate. AI verifies the entire chain from requirement definition through to production readiness. Every element in the release package must be traceable to the system model. This gate authorises shipment.
Model baseline is locked — no open change requests against the production package
All manufacturing allocations resolved — every assembly step has a resource and a sequence
Full end-to-end traceability: requirement def → part usage → verify → production baseline
Regulatory and compliance concerns captured in concern elements, each with a resolution linked in the model
Impact analysis clean: no open ECOs with unresolved downstream effects on the release variant
Gate 3 clearance is issued against the locked model baseline. The shipment authorisation is model-signed — cryptographically tied to the exact model version that passed all checks. Any post-gate model change voids the authorisation and requires a new G3 review.
Stage 7 of 7
Shipment & release
The product ships against a model-locked release baseline. Any field change, customer variant request, or post-ship defect immediately enters the MBAI change management process — AI traces the impact through the model before any engineering work begins. The model does not retire at shipment.
Locked release baselinepackage
Field variant configvariant
Change impact tracingdependency
ECO managementconcern
Post-shipment: change enters MBAI loop
Any engineering change → AI runs model-based impact analysis → affected contracts identified → re-verification scope defined → gate review triggered if scope exceeds threshold
AI governance — ongoing
Maintains the live model as the authoritative record — shipment is a snapshot, not the end
Customer variant requests are evaluated against the variant catalog before any engineering is authorised
Field defects are traced to their model element — root cause is model-located, not anecdotally described
The model evolves with the product: next generation begins with the released model as its foundation