__ __ _ __ __ ____ _____
\ \ / /__ ___| |_ ___ _ __| \/ | __ )| ____|
\ \ / / _ \/ __| __/ _ \| '__| |\/| | _ \| _|
\ V / __/ (__| || (_) | | | | | | |_) | |___
\_/ \___|\___|\__\___/|_| |_| |_|____/|_____|
A model-based engineering runtime: one versioned, OWL-backed graph that engineers, CI pipelines and LLM tools all query.
On a safety-critical program, the path from a system specification to a verifiable architecture is walked by hand. An engineer decomposes the spec into functions, groups them into components, allocates each function to one, and maintains a matrix linking every requirement to the function that realises it, the component that performs it, and the test that verifies it. On a program of any size that takes months — and it is redone every time the spec changes.
Three costs follow:
- Decomposition is unrepeatable. Two competent engineers partition the same specification differently, and neither can state the basis beyond judgement. Nothing records why function A and function B ended up in the same component, so a reviewer cannot check the partition — only argue with it.
- Traceability decays. The matrix is correct the day it ships. Later changes update the model and the document at different times, and the two drift. Programs find the drift at a milestone review, when reconciling costs most.
- Geometry arrives late. Sensor field-of-view occlusion, thermal adjacency, harness length, isolation between mixed-criticality partitions — none of it reads correctly on a flat diagram. It surfaces at integration, when changing the architecture is most expensive.
A language model is an obvious candidate for the first cost and, as normally applied, a bad answer to it. A decomposition emitted as prose reads correctly and cannot be checked: no stated basis, no type discipline, nothing that fails when it is wrong. Under ARP4754A, ARP4761, DO-178C or ISO 26262, an artifact whose provenance is "the model said so" is not evidence.
So the ordering is inverted here: the ontology constrains what may be
generated, rather than a generator producing an ontology after the fact. The
OWL 2 TBox is versioned in this repository and compiled into the binary. Model
proposals are restricted to the typed specification-field catalog, grounded in
the block's own functions and requirement texts, and written only when a human
accepts them — each stamped <key>_source = ai-estimate with its rationale.
Fields the model already states are not proposable at all. Every generated value
is a graph write: typed, traceable, checkable by SHACL, reversible. An unchecked
assertion never becomes model state.
End to end: ingest (PDF, requirements spreadsheet, SysML v2, AADL, XMI, ReqIF, CSV, RDF) → functional decomposition against the requirements driving each function → synthesis by measured coupling, with the modularity score reported so a weak partition is visibly weak → allocation onto logical components → evaluation by typed executable constraints, SHACL and SPARQL → 3D placement on a provenance ladder that announces its weakest authority → export to STEP AP242, SysML v2, XMI, ReqIF and OWL/Turtle.
It is for systems engineers and program technical staff in aerospace, defense and automotive, where the requirement-to-architecture-to-verification chain is a deliverable rather than an internal convenience.
Where the scope stops. A component here is a logical black box carrying its own constraints — interface, allocated functions, the requirements that reach it, and its envelope, mass, power and thermal limits. It is not a vendor part: no parts catalog, no supplier selection. The CAD export is CAD, with a narrower scope than a mechanical CAD system — STEP AP242 solids for the physical boundaries and envelopes of logical components, usable for packaging studies, clash detection and envelope reservation, but not detailed part geometry, fasteners, fillets or manufacturing features.
VectorMBE is a venture of Vector Stream Systems LLC, independently developed and not affiliated with or funded by any employer or institution. The methods described are patent-pending; no patent has issued.
Full rationale, including the direction of travel toward CAD assemblies at
aircraft and transportation-network scale and PLM feedback into the original
design: docs/WHY.md.
VectorMBE keeps an OWL-backed graph with vector retrieval, typed constraints and
Model Context Protocol integration, so that
engineers, CI pipelines and LLM tools can reason over the same versioned model
instead of three drifting copies of it. This repository is the Rust
implementation: a graph–vector–constraint kernel (vectormbe), an Axum HTTP
server (vectormbed), import bridges for SysML v2 / AADL / XMI / CSV / RDF /
MATLAB, a SPARQL endpoint, and a React/Vite web UI.
A 153-entity ADAS model rendered as black boxes. Components are sized from their contents where the model says enough to size them; the findings panel names the ones that are placeholders instead of quietly drawing a box anyway.
Recorded walkthroughs on the Vector Stream Systems channel:
- Introducing the Vector Model Based Engineering Platform — a natural-language system description is turned into EARS-format requirements, components, functions and interfaces in one graph, then checked with the built-in coverage, FMEA and OWL/SHACL/SPARQL passes.
- BlackBox Architecture 3D — Level 4 ADAS — a Level 4 ADAS robotaxi specification runs the full pipeline: functional decomposition, functional synthesis into allocated logical components, 3D render, and STEP CAD export of the components' physical envelopes.
- Functional Hazard Assessment against ISO 26262 — an FHA is generated per component and function, each entry classified S0–S3 with an ASIL rating and written into the model graph, so the hazard lines stay linked to the architecture they came from.
- CAD-like manipulation in the 3D massing view. Select a solid and move,
rotate or scale it with the transform gizmo; drag items in the scene outline
to reorder or reparent them. Overrides persist as
render_transformandcomposition_orderattributes and are reflected in CAD export.
git clone https://github.com/radsilent/VectorMBE.git
cd VectorMBE
docker build -t vectormbe .
docker run --rm -p 8080:8080 vectormbeOpen http://localhost:8080 — UI and API share the port, and the bundled 174-entity aircraft propulsion demo is already loaded. The container runs unauthenticated: right for a local demo, wrong for anything other people can reach. The first build compiles the workspace and downloads LibTorch, so it takes a while; the image is about 840 MB.
Rust toolchain and Node 20+. Run these from the repository root, not from your
home directory — cargo needs to find the workspace Cargo.toml. Two processes
— the API server and the web UI:
# 1. API server, preloaded with the bundled demo model.
# vectormbed links against LibTorch, which `tch` downloads into the build
# directory rather than installing system-wide, so the binary needs it on
# the library path. Build first, then point LD_LIBRARY_PATH at it:
cargo build -p vectormbed
export LD_LIBRARY_PATH="$(find target/debug/build -path '*/libtorch/libtorch/lib' -type d | head -1)"
VECTORMBE_STARTUP_GRAPH=demo ./target/debug/vectormbed
# 2. In a second terminal, the web UI
cd ui && npm ci && npm run devWithout the library path the binary exits with error while loading shared libraries: libtorch_cpu.so. scripts/run-vectormbed.sh does the same setup for
a --release build if you would rather not do it by hand.
The UI opens on http://localhost:5173 and targets the API on :8080
(VECTORMBE_HOST, VECTORMBE_PORT). If 5173 is already taken Vite picks the
next free port and prints it. Without VECTORMBE_STARTUP_GRAPH=demo the
server starts empty; other bundled models are listed under Sample models.
If Vite throws module or HMR errors, npm run dev:clean clears its cache.
| Route | Method | Purpose |
|---|---|---|
/entity/create |
POST | Create an entity |
/query |
POST | Hybrid query (keyword + semantic) |
/query/sparql |
POST | Basic SPARQL SELECT |
/entities/search/semantic |
POST | Pure vector search |
/entities/search/hybrid |
POST | Hybrid ANN + keyword |
/entities/{id}/similar |
GET | k-NN similar entities |
/entities/{id}/neighborhood |
GET | Graph neighborhood |
/vector/status |
GET | Vector index health |
/import |
POST | Import model file |
/export |
GET | Export (owlf, xmi, aadl, sysmlv2) |
/openapi.json |
GET | Full OpenAPI catalog |
A thin HTTP client; the server holds authoritative state.
cargo run -p vectormbe-cli -- entity create --type Wing --attr area=20 --attr force=5000
cargo run -p vectormbe-cli -- entity link --from <uuid> --to <uuid> --relation contains
cargo run -p vectormbe-cli -- query --type Wing --dsl 'FIND Wing WHERE area > 10'
cargo run -p vectormbe-cli -- anchor create --type stress --target Wing
cargo run -p vectormbe-cli -- requirement create --key R001 --description "Max stress constraint"
cargo run -p vectormbe-cli -- import --file model.xmi --format xmicargo run --example car and --example aircraft build small models in-process.
Needs the Tauri CLI and system
WebKit/GTK dependencies. Build vectormbed first, stage it as the sidecar, then
cargo tauri build produces .deb, .rpm and .AppImage bundles:
cargo build --release -p vectormbed
mkdir -p src-tauri/binaries
cp target/release/vectormbed src-tauri/binaries/vectormbed-x86_64-unknown-linux-gnu
cargo tauri buildBy default vectormbed writes a JSON snapshot to VECTORMBE_STORAGE_PATH plus
a sibling JSONL event log — no extra dependencies. For a native graph database,
build with the oxigraph-store feature and set VECTORMBE_OXIGRAPH_PATH:
cargo run -p vectormbed --features oxigraph-store -- \
VECTORMBE_OXIGRAPH_PATH=./data/vectormbe.nqEntities and relations are then stored as RDF triples in an embedded Oxigraph
database persisted as N-Quads and queryable with SPARQL; existing JSON snapshots
migrate on first startup, and the event log stays a sibling .events.jsonl.
docs/architecture/persistence.md covers
what is written to disk, what is derived on demand, and which directories must
be mounted to survive a container restart.
export VECTORMBE_HOST=0.0.0.0 VECTORMBE_PORT=8080
export VECTORMBE_CORS_ALLOW_ORIGIN=https://your-site.com
cargo run -p vectormbed
cd ui && VITE_VECTORMBE_API_URL=https://api.your-site.com npm run buildSelf-hosted rollout: docs/self-hosted-production.md · deploy/deploy-prod.sh · deploy/systemd/vectormbed-prod.service · deploy/nginx/vectormbe-public.conf Single local URL via nginx: docs/local-reverse-proxy.md. Cloudflare Tunnel: deploy/cloudflared-config-vectormbe-api.yml · deploy/apply-cloudflared-tunnel.sh
Licence: Apache-2.0 · Site: vectorstreamsystems.com
Standards it aims at: INCOSE SE Handbook v4 · OMG UML 2.5.1 · OMG SysML v1.6 / v2 · OMG MOF 2.5.1 · SAE AS5506 (AADL) · DoDAF DM2 · ARP4761
Your models stay on your machine. No analytics, no usage tracking, no
phone-home. One thing deserves care: with VECTORMBE_LLM_PROVIDER unset the
provider is auto-detected, so an ANTHROPIC_API_KEY or OPENAI_API_KEY already
exported in your environment will be picked up — pin the provider if you need a
guarantee. PRIVACY.md explains it in full and shows how to verify
every claim rather than take our word for it.
VectorMBE has been built almost entirely by one person. It is open source as of August 2026 because it stands a much better chance of becoming genuinely useful with other people involved than it does on its own.
So, plainly, where things actually stand:
cargo check --workspacepasses, and CI runsfmt,clippy, build, tests,npm ci,wasm-pack,vite, andeslinton every push.- The kernel, the HTTP server, the MCP integration and the web UI all work, and get used regularly on real models.
- Plenty of the surface beyond that is uneven. Some import bridges are better tested than others, the STEP AP242 CAD export is deliberately described below as a walking skeleton, and there are corners where the design is further along than the implementation.
- Documentation assumes more context than a newcomer will have. If something reads as obvious to the author and not to you, that is a documentation bug — please say so.
If you try this and it breaks, that is not you doing it wrong. Open an issue and it will get read.
No contribution is too small, and fixing a typo in these docs is a completely legitimate first pull request.
The areas where another pair of hands would go furthest:
- Getting started. The build and run instructions below have only ever been followed on a handful of machines. Reports of what fails on yours are valuable.
- Import bridges. SysML v2, AADL, XMI, CSV, RDF and MATLAB importers all exist; real-world files that they mishandle make excellent bug reports and even better test fixtures.
- Tests. Coverage is thin in places. Tests pinning down current behaviour are welcome even where that behaviour later turns out to be wrong.
- CAD and 3D export. STEP AP242 generation is early and there is a lot of room here.
- Docs. See above.
CONTRIBUTING.md covers setup and workflow. Questions are
welcome in GitHub Discussions
or as an issue — asking one is genuinely helpful, because it usually reveals
something that should have been written down.
Two pipelines carry a specification to geometry. Both are documented in full, because both make claims that need to be checkable.
System generation: text → decomposition → 3D — seven replayable stages from a prompt or imported spec to a placed, wired arrangement: research (graph scan, then external sources), functional decomposition against the requirements that drive each function, synthesis by coupling-weighted community detection with the modularity score shown, allocation onto logical blocks, specification with gaps named before they are filled under review, render, and a manifest that states its own provenance. Every run records a reasoning trace; a run that cannot explain itself is treated as a defect.
3D rendering: spec → 3D → CAD — how a tiered specification becomes a conceptual solid model. Placement follows a provenance ladder — declared coordinates, then massing, then envelope-packing, then a flagged placeholder grid — and the view and the export manifest both announce the weakest authority present, so a logical arrangement cannot pass as a packaging study. Also covers form archetypes, parametric envelopes, agent-estimated properties, STEP AP242 export, wiring overlay and dimension callouts.
The React/Vite UI (ui/) is organised by the stage of the MBE workflow it
serves, and 3D Rendering is the landing view:
- Model — 3D Rendering, System Rendering, Graph Explorer, Diagrams, SysML v2 editor, Projects.
- Architecture — Components, Functions, Signals, ICD, BOM, Budgets (stated vs. rolled-up with margins and per-cell provenance), Allocation, Stakeholders.
- Analysis — Requirements, Req. Generation, Coverage, Traceability, Digital Thread, Ontology, Safety FHA (ARP4761), FMEA, Scenarios, Reports.
- Tools — Version Control (commits, branches, diff, merge, push/pull), Workflow Guide, Integrations.
Per-workspace detail: docs/ui-workspaces.md.
| Format | Extension(s) | Direction | Notes |
|---|---|---|---|
| SysML v2 | .sysml |
Import | part def, action def, attribute def, connect, satisfy, allocate; functional kind promotion |
| AADL | .aadl |
Import + Export | SAE AS5506 — all 13 component categories, features, connections, AGREE/EMV2 annexes; OSATE-compatible |
| SysML / UML XMI | .xmi, .xml, .uml |
Import | Cameo/MagicDraw exports; element types auto-mapped |
| STEP AP214 | .step, .stp |
Import | ISO 10303-21 — PRODUCT, ASSEMBLY, NEXT_ASSEMBLY_USAGE_OCCURRENCE |
| JSON | .json |
Import + Export | {nodes, edges}, {entities, relations}, ICD {interfaces, signals, system} |
| CSV | .csv |
Import | Tabular entity/relation import |
| RDF / OWL | .ttl, .owl, .rdf, .nt |
Import + Export | OWL/RDF triples; owl:equivalentClass/owl:sameAs auto-merged; OWL 2 Functional Syntax export |
| MATLAB | .m |
Import | Classdef → Block, function → Function, signal flows → Signal |
| Simulink MDL | .mdl |
Import | Subsystems, blocks, ports, signal lines |
| Simulink SLX | .slx |
Import | XML or MDL heuristics |
| ReqIF | .reqif |
Import | Requirements interchange format |
| XTCE | .xtce |
Import | XML Telemetric and Command Exchange |
Loadable from the Import modal with no external file:
- SysML v2 — Widebody Aircraft full system architecture (104 functions, 445 components, 78+ allocations, 36+ requirements) · High-Bypass Turbofan with FADEC-allocated control functions · EV Powertrain (100 kWh BEV, PMSM 350 kW, SiC inverter) · Aircraft Turbofan, LEAP-1B class (9-stage HPC, TAPS combustor, FADEC DO-178C Level A) · Apollo 11 Spacecraft (Airbus CoSMA, MPL-2.0) · OMG Vehicle Definitions and Usages from the spec examples.
- AADL / MATLAB / STEP — Aircraft Avionics Platform v2 (IMA core, FADEC, FMS, autopilot, ECAM, ECS) · Flight Control v2 (LQR design, Dryden turbulence, autoland) · Airframe v2 (STEP AP214).
- Engineering / analysis — EV Powertrain Control (Simulink MDL) · Battery Management System (MATLAB) · HVAC (RDF Turtle) · Power Grid (CSV) · Aerospace OWL (Turtle).
- Cameo / MDZIP — NIST Central Fill Pharmacy · NIST Electronics Assembly · MathWorks Electric Throttle Control (XMI).
| Path | Role |
|---|---|
vectormbe (root crate) |
Library: graph kernel, domain modules, API handlers, MCP sync, SPARQL |
vectormbed |
Axum server binary |
vectormbe-cli |
HTTP CLI |
vectormbe-wasm |
WebAssembly build for browser embedding |
src-tauri/ |
Tauri desktop shell |
ui/ |
Vite + React client |
examples/ |
Runnable scenarios (car, aircraft, demo) |
mcp/ |
MCP tooling — see mcp/README.md |
fixtures/ |
Engineering model fixtures (SysML v2, MATLAB, JSON, RDF) |
deploy/ |
Deployment scripts, nginx configs, systemd units, Cloudflare Tunnel configs |
| Crate | Purpose |
|---|---|
uuid, serde, serde_json |
Identity and JSON codecs |
tokio |
Async runtime, RwLock, broadcast |
axum, tower-http |
HTTP server and CORS |
tracing, tracing-subscriber |
Structured logs |
csv, rio_*, roxmltree |
Import bridges |
fast-hnsw |
Approximate nearest-neighbor (HNSW) in-process index |
qdrant-client |
Persistent vector store — production ANN tier when VECTORMBE_QDRANT_URL is set |
Licensed under the Apache License, Version 2.0.
Copyright 2026 Vector Stream Systems LLC and the VectorMBE contributors.
Contributions are accepted under the same licence, per section 5 of Apache-2.0. There is no CLA to sign.