User Guide
From specs, models & tool data
to validated requirements
Ten steps from first ingest — via MCP or direct schema mapping — through agentic entity generation to constraint-driven trade analysis. Each step produces a concrete artifact the next step consumes.
Bring your engineering sources into VectorMBE two ways: live over the Model Context Protocol from connected CAD/CAE/PLM/MBSE tools, or by direct schema mapping that lands exports, requirement specs, and tool data straight into the graph — through the web UI or CLI. Agents parse each source and generate typed entities. Ingest multiple sources in one pass and the system merges them into a single versioned, ontology-grounded graph.
After ingest, VectorMBE presents the auto-classified OWL graph. Open the Ontology panel to inspect the class hierarchy, entity types, and property assignments the pipeline inferred. Add domain-specific subclasses, introduce missing object properties, or align classes to upper ontologies such as BFO or SOSA. Property restrictions and cardinality rules defined here become the semantic backbone that governs every extraction, generation, and validation step downstream. Tighter ontology means fewer false positives in requirements and stronger constraint enforcement.
VectorMBE scans the graph for all function-type nodes and resolves their typed interfaces. Input parameters, output parameters, and flow ports are extracted and stored as structured edges. The result is a queryable function catalog with full interface visibility.
Signal definitions, enumeration types, and bitfield layouts are parsed and attached to their function and component nodes as typed attributes. CAN/LIN DBC and ARXML signal catalogs are read directly. Each signal gets a unique URI so requirements can reference it without ambiguity.
Operating ranges, tolerance bands, and hard limits from your uploaded documents and model annotations are extracted and registered as candidate anchor constraints. Each limit is linked to the signal or function it governs so the boundary condition is traceable to its source document or standard.
With the graph populated, open the requirements generator. Optionally upload a specification document for additional context, then describe what you need in plain language. The AI reads your functions, signals, and existing requirements and produces formally structured candidates. Select the ones you want and add them to the requirements table in one click.
Every requirement must be allocated to at least one function, component, or system node. The traceability matrix shows which requirements are unallocated and which components have no requirement coverage. Fix gaps by drawing allocation edges directly in the graph or from the detail panel.
The AI quality checker inspects each requirement against a set of engineering rules: ambiguous terms, weak verbs, missing verification methods, missing rationale, and duplicate detection. Issues are ranked by severity. Apply suggested fixes inline without leaving the table. Each change is logged and versioned in the graph.
Once requirements are validated, export them to downstream tools. Use Export as CSV for spreadsheet workflows, or Export as ReqIF to import directly into DOORS, Jama, PTC Integrity, or any ReqIF 1.0-compatible tool.
Push validated requirements into the simulation layer via MCP. VectorMBE compares requirement bounds against outputs from your connected simulation tools. Formal constraints from Step 5 are enforced as gates: a simulation result that violates an anchor is flagged before it can be merged into the graph.
With a validated, evidence-backed graph, MCP-connected AI agents compare design alternatives against competing constraints and objectives. Each run queries the graph for bounds, executes the analysis, and logs results with full provenance: which requirement drove which decision, which model produced which output. Agents cannot override constraint gates, so the governed graph stays consistent throughout.