VectorMBE

A model-based engineering runtime: one versioned, OWL-backed graph that engineers, CI pipelines and LLM tools all query.

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.

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.

Quickstart

Docker

git clone https://github.com/radsilent/VectorMBE.git
cd VectorMBE
docker build -t vectormbe .
docker run --rm -p 8080:8080 vectormbe

Open http://localhost:8080. The UI and the API are both on that port, and the bundled demo model is already loaded — a 174-entity aircraft propulsion graph of functions, signals, components and pins. Nothing to configure and no key to enter; the container runs unauthenticated, which is right for a local demo and wrong for anything other people can reach.

The build compiles the whole workspace and downloads LibTorch, so expect it to take a while the first time. The resulting image is about 840 MB.

From source

Two processes: the API server, and the web UI that talks to it. You need a Rust toolchain and Node 20+.

# 1. API server, preloaded with the bundled demo model
VECTORMBE_STARTUP_GRAPH=demo cargo run -p vectormbed

# 2. In a second terminal, the web UI
cd ui && npm ci && npm run dev

Then open http://localhost:5173. The API listens on :8080. VECTORMBE_STARTUP_GRAPH=demo imports data/demo/aircraft_propulsion.json at boot, so the graph is already populated when the UI connects; without it the server starts empty. Other bundled models are listed under Sample models (built-in).

Licence: Apache-2.0 · Site: vectorstreamsystems.com · Framework overview · Technical paper

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. VectorMBE has no analytics, no usage tracking and no phone-home, and it never reports to Vector Stream Systems. One thing does deserve 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 that in full and shows you how to verify every claim in it rather than take our word for it.

---

Project status — worth reading before you dig in

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 --workspace passes, and CI runs fmt, clippy, build, tests, npm ci, wasm-pack, vite, and eslint on 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.

Where help would matter most

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.

---

Developer quick start (local)

Prerequisites: Rust toolchain (cargo). If cargo is not on your PATH, use $HOME/.cargo/bin/cargo.

1) Build

cargo check --workspace

2) Start API server

cargo run -p vectormbed

Listens on http://0.0.0.0:8080 by default (VECTORMBE_HOST, VECTORMBE_PORT).

Notable routes:

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

3) CLI

cargo run -p vectormbe-cli -- entity create --type Wing --attr area=20 --attr force=5000
cargo run -p vectormbe-cli -- entity get <uuid>
cargo run -p vectormbe-cli -- entity update <uuid> --attr area=25
cargo run -p vectormbe-cli -- entity delete <uuid>
cargo run -p vectormbe-cli -- entity link --from <uuid> --to <uuid> --relation contains
cargo run -p vectormbe-cli -- query --type Wing
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 xmi
cargo run -p vectormbe-cli -- rl step --action update_area=30
cargo run -p vectormbe-cli -- rl reset

The CLI is a thin HTTP client; the server holds authoritative state.

4) Examples

cargo run --example car
cargo run --example aircraft

5) Desktop app (Tauri)

Prerequisites: Tauri CLI and system WebKit/GTK dependencies.

# Build the server binary first
cargo build --release -p vectormbed

# Stage sidecar binary
mkdir -p src-tauri/binaries
cp target/release/vectormbed src-tauri/binaries/vectormbed-x86_64-unknown-linux-gnu

# Build desktop bundle (.deb, .rpm, .AppImage)
cargo tauri build

6) Web UI

cd ui
npm install
npm run dev

Opens on http://localhost:5173. If you see module or HMR errors:

npm run dev:clean   # clears Vite cache and restarts

The UI targets the API at http://localhost:8080. For a single local URL via nginx: docs/local-reverse-proxy.md and deploy/nginx/vectormbe-local.conf.

Deploy (API + CORS)

export VECTORMBE_HOST=0.0.0.0
export VECTORMBE_PORT=8080
export VECTORMBE_CORS_ALLOW_ORIGIN=https://your-site.com
cargo run -p vectormbed

UI production build:

cd ui
VITE_VECTORMBE_API_URL=https://api.your-site.com npm run build

Self-hosted rollout: docs/self-hosted-production.md · deploy/deploy-prod.sh · deploy/systemd/vectormbed-prod.service · deploy/nginx/vectormbe-public.conf

Cloudflare Tunnel: deploy/cloudflared-config-vectormbe-api.yml · deploy/apply-cloudflared-tunnel.sh · deploy/run-cloudflared-tunnel.sh

---

Frontend workspaces

The React/Vite UI (ui/) is organised by the MBE project workflow:

Model

Workspace	Key Features
3D Rendering	Landing view. Conceptual solids sized from the model's own data via a provenance ladder, form archetypes, parametric envelopes, CAD export, wiring overlay, dimension callouts — see 3D Rendering below
System Rendering	2D block view of the system by entity kind
Graph Explorer	3D force-directed canvas (Three.js/R3F), project tree, topology intelligence panel, live WebSocket updates
Diagrams	2D React Flow canvas, orthogonal edge routing, BDD/IBD/UseCase/OntologyLayout auto-layout, encapsulation toggle, resizable/draggable blocks, annotation tools, AI diagram generation, SysML-style kind filters
SysML v2	Textual SysML v2 editor with live parse and graph sync
Projects	Project browser with entity grouping and lifecycle management

Architecture

Workspace	Key Features
Components	Tabular component viewer with attribute editing
Functions	Function decomposition viewer with hierarchy
Signals	Signal / netlist viewer
ICD	Interface Control Document viewer; imports {interfaces, signals, system} ICD JSON natively
BOM	Bill of Materials — hierarchical BOM generation from the component graph
Budgets	Subsystem mass/power/thermal budgets — stated vs. rolled-up values with margins, >20% divergence flags, and per-cell provenance (declared / estimated / rollup / unknown)
Allocation	Requirement-to-component allocation breakdown
Stakeholders	Stakeholder registry and concerns matrix

Analysis

Workspace	Key Features
Requirements	Glide Data Grid with inline editing, AI quality analysis, traceability matrix
Req. Generation	AI-assisted requirement generation from model context
Coverage	Coverage dashboard — traced vs. untraced requirements
Traceability	Requirements traceability matrix
Digital Thread	Full lifecycle trace graph
Ontology	Hierarchy (XMI/OWL subclass tree), Graph (kind taxonomy), Merge (duplicate detection), Validate (schema conformance), Synthesize (LLM-driven semantic link proposals)
Safety FHA	ARP4761-compliant Functional Hazard Assessment — severity, DAL, probability, mitigation, CSV export
FMEA	Failure Mode and Effects Analysis — AI-generated entries per component, RPN scoring
Scenarios	Scenario viewer and simulation trace
Reports	Real-time system health dashboard: entity stats, traceability coverage, entity distribution

Tools

Workspace	Key Features
Version Control	Full git-like VC: commits, branches, diff, merge, remote push/pull
Workflow Guide	Interactive onboarding and step-by-step MBE workflow guide
Integrations	Integration hub for external tools and data sources

---

System generation: text → decomposition → 3D

The generation canvas turns a prompt or imported specification into a placed, wired, dimensioned 3D arrangement through seven replayable stages. Every stage is a view of one derivation (buildGenerationState), so scrubbing backwards re-invokes nothing — and every run records its own reasoning trace: what each stage found, on what basis it decided, and which rung of each ladder every block landed on. The trace is shown in the reasoning rail and exported in the manifest; a run that cannot explain itself is treated as a defect.

1 · Research — what the model knows, and what the web says

Two passes, internal first:

1. Graph scan — a grounded pass over the existing graph: requirements, standards cited anywhere in the model (recognised by designation — ISO/IEC/ASME/ARP/DO-/SAE/MIL-STD/EN/ASTM/RTCA/AUTOSAR/ECSS/NASA-STD patterns), imported documents, existing components, and interfaces that something actually connects to. This pass cannot introduce a claim the project did not already make.
2. External research — before specifying anything, the agent researches the system it is designing: a live web search (GET /research/web, backed by Wikipedia and DuckDuckGo, keyless and timeout-bounded) retrieves pages about the system under design, and the configured LLM reports applicable standards, off-the-shelf component classes with typical spec ranges, and specification guidance — its prompt is grounded in the live results. Web findings carry URLs and render as a distinct, clickable lead list; LLM findings are labelled model knowledge. If the search endpoint is unreachable the panel says so and proceeds with model knowledge only.

Research never writes to the graph. Its one downstream effect is a digest in the spec-proposal prompt, so proposed values can cite real-world ranges and pages — and every proposed value still lands in review, stamped ai-estimate.

2 · Decompose — functions and their drivers

Functional entities (function/activity/action/behavior/usecase kinds) are collected, and each is linked to the requirement texts that drive it through stated satisfies/derives/refines/traces relations. Functions with no requirement driver are reported as such — coverage is stated, not assumed.

3 · Synthesize — coupling-weighted community detection

Functions are grouped by how tightly they actually interact. A coupling graph is built from three weighted evidence sources: direct function→function flows (1.0), two functions touching the same signal/bus/port (0.7), two functions driven by the same requirement (0.4). The partition is found by directed Louvain community detection (Leicht–Newman modularity), and Q is displayed so a weak partition is visibly weak. A model stating no interactions yields one honest "no interaction data" group rather than a fabricated clustering.

4 · Allocate — groups become logical components

Stated allocation relations (allocated_to, implemented_by, performs, …) land functions onto logical blocks. Blocks get coarse roles (compute / sensor / software / logical) from kind and name — deliberately never vendor part numbers.

5 · Specify — gaps named, then filled under review

Each block's full specification is gathered: stated attributes, attached interfaces, and the requirements that reach it through its functions. Gaps are named explicitly ("not specified: interfaces, requirements, constraints").

AI proposals fill gaps under human control: the configured LLM is grounded in the block's functions, requirement texts and stated attributes, restricted to the typed spec-field catalog, and required to justify each value. Proposals render in a review list with rationale and confidence; only explicitly accepted values are written, each stamped <key>_source = ai-estimate and <key>_rationale. Fields the model already states are not proposable at all — stated truth changes only by human edit in the spec editor.

6 · Render — placement with spatial authority

Blocks are placed by a provenance ladder, strongest authority first:

Authority	Source
Declared	Stated installation coordinates (cad_originXMm …, installation_*_mm, position_mm)
Massing	Packed by the assembly massing scene against declared/estimated envelopes
Envelope-pack	Own envelope exists; packed against siblings at true relative size
Logical	Nothing physical stated — placeholder in a grid, flagged

All positions are computed in millimetres and scaled uniformly into scene units, so sizes stay true to each other across rungs; packed groups sit clear of authoritatively placed content. The chrome marker and the manifest announce the worst authority present (full / partial / none) — a logical arrangement can never masquerade as a packaging study. Shapes come from the form archetypes with volume preserved. Blocks that state a stakeholder access need (a use case or stakeholder requirement to reach, service, see or operate the part) are pulled to the layout periphery with the driver shown, and parts orient to their function — long-axis parts lie down, panels face outward. Connections route as typed wiring (power / data / mechanical / thermal / interface) lifted clear of the hardware. Wiring comes from stated block-to-block relations first; where none are stated, the render derives connections — drawn dashed, counted separately — from function-level coupling, then from blocks sharing a signal or densified interface node. When none of those exist the reasoning says so and names what to add, rather than silently showing an unwired system.

7 · Export — a manifest that says what it is

The v2 manifest carries every block's specification, its placement authority and basis, the roll-up spatial_authority (full/partial/none), the research evidence the run stood on, and the full reasoning trace — so the file leaving the tool states its own provenance rather than needing the UI to disclaim it.

---

3D Rendering: spec → 3D → CAD

The 3D Rendering workspace is what opens when you start VectorMBE. It turns a tiered specification into a conceptual solid model, exports that to CAD, and routes the system's connections through it.

The provenance ladder

At specification time a model has no geometry — it has a containment tree, some masses, and rarely an envelope. Rather than require dimensions and draw nothing, every entity is resolved through a ladder, and which rung it landed on is carried on the solid and shown as its colour:

Tier	Source
Declared	The model states an envelope (literal or expression)
Estimated	An agent filled the gap — marked, never mistaken for fact
Derived	mass ÷ density → volume → shaped by archetype
Sized by contents	Packed bounds of the node's own children
Allocated	Pro-rata share of the parent's volume, by mass
Unspecified	Nothing known — a placeholder

A model with no geometry at all still renders; it just renders as obviously unspecified, which is the useful signal at that stage. Nothing inferred is ever presented as measured.

Solved placement

Size has always carried its ladder; position now carries its own. The packer's grid is a layout, not a location — so every solid's centre is labelled with a placement authority, and only the top rungs may be dimensioned from:

Authority	Source
Declared	Position attributes state it
Mated	Solved from a stated interface — the position is a consequence of the model
Datum	Located from a named reference frame
Packed	Grid tiling — no spatial authority
Unplaced	Nothing known

Two relation families become placement constraints. Mounting relations (mounted_on, bolted_to, …) become bolted joints: faces coincident, one shared hole pattern drilled through both parts. Mechanically unambiguous power relations (drives, geared_to, coupled_to, …) become coaxial mates, so inverter → motor → transmission lays out end to end on one shaft axis, the way the hardware actually goes together — while powers and connects move nothing, because a cable is happy to cross the vehicle and a vague connection is not a placement. A BFS spanning tree solves the mates in closed form, anchored at the part that supports the most others; every mate the tree didn't use is checked, and a contradiction surfaces as a mate-conflict finding rather than a silent average. Containers then re-fit around their solved contents — except a declared envelope, which is contractual: overflow there is a finding, not a resize.

Form archetypes

A volume alone says how much, not what shape. 32 archetypes map an entity to a representative form and proportions — a motor is a cylinder, a PCB a 1.6 mm plate, a tank a capsule, a harness a long thin run, a pressure vessel a sphere — resolved by explicit form_factor attribute, then kind, then name. The solver preserves the derived volume exactly, so shaping a part never changes the mass budget it represents.

Parametric envelopes

An envelope attribute may hold an expression instead of a number:

envelope_x = "=wheelbase"
envelope_y = "=max(motor_dia, pump_dia) + 20"
envelope_z = "={Battery Pack}.envelope_z * 1.1"
diameter   = "=bore"

Full precedence, units on literals (=1m + 500 → 1500), and min/max/abs/sqrt/round/floor/ceil/clamp. References resolve to the entity's own attributes, then named Parameter entities, then any entity by braced name. The leading = is required so values like 6061-T6 and 1/4-20 UNC are never misread as arithmetic. Parameters driving the model are editable in the panel.

Agent-estimated properties

Parts with no mass or envelope can be estimated by an agent from their name, kind and context. Estimates are range-checked, reconciled against the request (entities nobody asked about are refused, duplicates dropped, skipped gaps reported) and land in a review list — nothing is written without approval. Saved values carry <field>_source = ai-estimate, which puts them on the estimated tier permanently.

CAD export

Target	Notes
OpenSCAD (.scad)	Editable script; container shells use % so they give context without material
CadQuery (.py)	Builds a cq.Assembly and exports STEP, which round-trips back through src/import/step.rs as traced entities
STL (.stl)	Opens anywhere; verified watertight — no non-manifold edges, normals consistent with winding

Every solid carries its entity id and the basis for its size as comments. The scene is Y-up and CAD is Z-up, so points convert on export.

These three targets serve the concept stage — they answer "how big, roughly, and does it fit". None of them writes a STEP file directly: the CadQuery target emits a script you run, and that script builds a flat assembly. For a STEP file with a real product structure, see below.

Parametric CAD generation — STEP AP242 (walking skeleton shipping)

A separate backend, cadgen/, generates parametric CAD assemblies from the system model and writes STEP AP242 directly: named products and instances in a real XCAF assembly tree, explicit millimetre units, colours, validity-checked B-rep, and a round-trip harness that re-reads every file it writes. The acceptance criterion is that the output opens cleanly in SolidWorks and CATIA with a correct feature tree — round-tripping through OCCT alone does not count.

It is deliberately stricter than massing. Massing renders honestly when data is missing; cadgen refuses to run on an underspecified model, naming every missing parameter, because a plausible guess in a manufacturing artefact is worse than a refusal.

The skeleton runs end to end today: ABox Turtle (file or GET /export/owl-abox from the daemon) → one SPARQL CONSTRUCT → SHACL gate that fails closed → build123d part registry → closed-form mate solving → XCAF → STEP AP242, plus frames/BOM/reconciliation sidecars. cd cadgen && ../.venv-cadgen/bin/python -m pytest runs its 72-test suite; see cadgen/README.md for the pipeline, the layering rules, and the honest limitations (no frame triads, --level skeleton|envelope refuse rather than fake it).

• Orientation — what exists today, and three defects it turned up (the Turtle export carries no instances, so SHACL validation of instance data is currently vacuous; the only instance-level export drops Quantity units; the Y-up→Z-up conversion mirrors handedness)
• Design — proposed vmbecad: ontology terms, the extraction query, module layout, and the validation harness spec

Status: proposal under review. Nothing in this section ships yet.

Wiring overlay

Power, signal, fluid, thermal and mechanical connections route as smooth overhead harness runs between placed solids — out of the source's top face, up to a travel plane that hugs the hardware, level across the span with filleted corners, and down into the target. Runs stay level mid-span: a tie-wrapped harness does not droop like a transmission line. Clearance, lane spacing and bus lift scale with the height of the connected hardware rather than using fixed offsets, so runs dress small parts as closely as large ones. Lanes keep parallel runs separate, and interfaces shared by three or more legs collapse into a bus concentrator above the cluster centroid. Electrical runs draw as round-section cable; mechanical and fluid runs draw as rectangular-section duct so the two are never confused. Endpoints resolve to the nearest placed ancestor, so port-to-port connections still draw between the components that own them. Each run reports its routed length, which is what harness mass, voltage drop and pressure loss are calculated from.

Dimension callouts

Extension lines, dimension lines, arrowheads and values, in drafting convention. Following ASME Y14.5, a size that is not declared is written as a reference dimension in parentheses — derived information, not something to build to. Tolerances pass through per axis where the model states them and are never placed on a reference dimension; feature control frames and datums pass through verbatim and are never synthesised.

Scope: massing is a concept model, not a part model. Archetype shapes are informed guesses from a component's class, and the expression evaluator does length arithmetic in millimetres rather than full dimensional analysis — the Rust parametric module owns unit algebra. Parts with real CAD should render their real CAD; this is what to draw until then.

---

Import / Export formats

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

---

Sample models (built-in)

Accessible from the Import modal without any external file:

Commercial Widebody Aircraft (SysML v2)

• Widebody Aircraft Full System Architecture — 104 functions, 445 components, 78+ allocation relationships, 36+ requirements
• High-Bypass Turbofan Engine — 28 engine control functions allocated to FADEC/combustor/compressors/oil system

SysML v2

• EV Powertrain — 100 kWh BEV (BatteryPack, PMSM 350 kW, SiC inverter, CCS DCFC)
• Aircraft Turbofan (LEAP-1B class) — 9-stage HPC, TAPS combustor, FADEC DO-178C Level A
• Apollo 11 Spacecraft — Airbus CoSMA open-source model (MPL-2.0)
• OMG Vehicle Definitions — official SysML v2 spec example
• OMG Vehicle Usages — configurations C1/C2/C3 with interface connections

Commercial Aircraft (AADL / MATLAB / STEP)

• Aircraft Avionics Platform v2 (AADL) — IMA core, FADEC, FMS, autopilot, ECAM, ECS
• Aircraft Flight Control v2 (MATLAB) — FCS requirements, LQR design, Dryden turbulence, autoland
• Commercial Aircraft Airframe v2 (STEP AP214) — fuselage sections, wing assemblies, landing gear

Engineering / Analysis

• EV Powertrain Control (Simulink MDL)
• EV Battery Management System (MATLAB)
• HVAC System (RDF Turtle)
• Power Grid (CSV)
• Aerospace OWL (Turtle)

Cameo / MDZIP

• NIST Central Fill Pharmacy — discrete-event SysML
• NIST Electronics Assembly — production logistics SysML
• MathWorks Electric Throttle Control (XMI)

---

Workspace layout

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

---

Dependency manifest (root crate)

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

---

 __     __        _             __  __ ____  _____
 \ \   / /__  ___| |_ ___  _ __|  \/  | __ )| ____|
  \ \ / / _ \/ __| __/ _ \| '__| |\/| |  _ \|  _|
   \ V /  __/ (__| || (_) | |  | |  | | |_) | |___
    \_/ \___|\___|\__\___/|_|  |_|  |_|____/|_____|

License

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.