VectorMBE is the autonomous platform for systems engineering. It connects your SysML models, signal databases, spec documents, and simulation tools into a living digital thread — autonomously generating formal requirements, synthesizing complex safety assessments, reasoning about architecture, propagating change impact, managing verification evidence, and keeping your entire program in sync. No custom build required.
Under the hood, VectorMBE extends the Web Ontology Language (OWL) with native vector embeddings and the Model Context Protocol as a coordination layer across your tool ecosystem. The architecture is grounded in the SERC Handbook on Digital Engineering with Ontologies v2.0 — the DoD OUSD(R&E) authoritative standard — and aligned with INCOSE's Model Characterization Pattern v1.8.1. The same substrate holds computational-model characterization (identity, envelope, credibility pointers, lifecycle) with trust-grade provenance. ("MCP" here is Anthropic's Model Context Protocol — not the INCOSE pattern acronym.)
VectorMBE is a research architecture / framework (runtime in development): OWL plus vectors plus MCP integration—it is not a replacement for Python, C++, or similar general-purpose languages.
Single source of truth: the versioned OWL graph is where governed system and data-model semantics, characterization, traces, and evidence converge. Tools feed it; they should not be the silent second book of record.
OWL is the formal ontology language for structure, constraints, and provenance in the graph.
The real integration surface is Model Context Protocol (vectormbe-mcp, stdio): register it in Claude Desktop, Cursor, or any MCP host so tools and resources talk to the runtime. A bundled SKILL.md is only optional prose for assistants; it does not replace the MCP server. (Do not confuse this with the INCOSE "Model Characterization Pattern" for computational models—that is metadata and requirements on models; see framework · characterization.)
Everything below stays the same—this section only orients readers who hit the symbols first.
What it is
Manifold-augmented ontologies with hybrid reasoning
In VectorMBE, every ontological entity (classes, individuals, and properties) carries both a symbolic identity (URI, OWL axioms) and a continuous vector representation learned from multi-modal engineering data. The two layers are reasoned over jointly.
Each entity e is formally:
e = ⟨ uri, type, AxiomSet, v ∈ ℝd, attributes ⟩
where AxiomSet holds OWL assertions and v is an embedding learned from CAD geometry, performance metrics, and historical telemetry.
Hybrid inference over two entities e₁, e₂:
Inference(e₁, e₂) = α · 𝟙(S₁ ⊢ S₂) + (1−α) · K(v₁, v₂)
α ∈ [0, 1] is learnable, balancing logical precision with statistical generalization. K is a kernel function (cosine similarity or hyperbolic distance for hierarchical structures).
DoD · OUSD(R&E) · Systems Engineering Research Center
Built on the DoD's authoritative digital engineering standard
VectorMBE's ontology-first architecture is grounded in the SERC Handbook on Digital Engineering with Ontologies v2.0 — the Systems Engineering Research Center's definitive reference for applying formal ontologies across DoD acquisition programs, published under the Office of the Under Secretary of Defense for Research and Engineering [OUSD(R&E)]. This is not an academic footnote. It is the standards foundation on which every layer of VectorMBE is built.
SERC · OUSD(R&E)DoD Official Publication
Handbook on Digital Engineering with Ontologies, Version 2.0
Published by the Systems Engineering Research Center (SERC) under the DoD Office of the Under Secretary of Defense for Research and Engineering [OUSD(R&E)]. This handbook establishes the authoritative DoD framework for applying formal ontologies in digital engineering programs — covering knowledge representation, semantic interoperability, model-based acquisition, system-of-systems integration, and the governance of authoritative sources of truth across the program and supply chain.
VectorMBE is the commercial-grade implementation of these principles. Every architectural decision — OWL 2 as the governed system-of-record, hybrid symbolic and vector reasoning, semantic interoperability via the Model Context Protocol, governed safety constraints, and trust-grade computational model characterization — maps directly to the guidance this handbook establishes for DoD-grade digital engineering programs.
SERC establishes formal ontologies as the semantic backbone for DoD digital engineering programs. VectorMBE extends OWL 2 with vector embeddings and governed safety constraints — fulfilling this mandate while adding probabilistic reasoning across high-dimensional simulation outputs, CAD geometry, and continuous telemetry data.
Principle 2 — Handbook §4
Semantic interoperability across heterogeneous tools
The handbook identifies semantic interoperability as the central challenge of multi-tool digital engineering programs. VectorMBE's MCP coordination layer solves this directly: a URI-based IdentityRegistry maps local tool entities (CATIA, Ansys, MATLAB, SysML v2) to global VectorMBE URIs without semantic loss or data translation artifacts.
Principle 3 — Handbook §6
Model-based acquisition and program-level trust
SERC addresses ontology use in model-based acquisition — authoritative sources of truth across the program and supply chain. VectorMBE's governed OWL graph with full provenance, VVUQ alignment, governed safety constraints, and trust-grade computational model characterization directly implements these program-level requirements.
DoD reference document — OUSD(R&E) / SERC
SERC Handbook on Digital Engineering with Ontologies v2.0
The definitive DoD guidance on integrating formal ontologies into digital engineering practice across acquisition programs. The research and standards foundation for VectorMBE. Published by the Systems Engineering Research Center under OUSD(R&E).
Extends OWL 2 by mapping entities into a continuous vector space ℝd alongside symbolic axioms. Every entity has a URI, an AxiomSet (symbolic), an EmbeddingManifold (vector), and a key-value attribute map.
Symbolic layer: tableaux-based OWL reasoning for consistency and satisfiability
Vector layer: kernel-based similarity (cosine / hyperbolic) for probabilistic inference
Hybrid inference weighted by learnable α
Multi-modal embeddings: CAD geometry, telemetry, performance metrics, simulation result metadata
Layer 2
Governed safety constraints
Hard predicates that override any probabilistic suggestion from the vector layer when violated. Safety-critical correctness is non-negotiable: governed constraints are the ground truth layer.
Scalar: f(x) ≤ θ, e.g. operating temperature < 150°C
Relational: x ∈ Neighbors(y); component A must mate to B
Functional: y = g(x₁,…,xₙ); derived performance relationships from verified models
Severity levels: Warning / Error / Critical, with full evaluation logs
Implemented via SMT solvers or custom rule engines
Layer 3
Model Context Protocol: the coordination kernel
The Model Context Protocol acts as the tool-and-assistant wiring for the architecture: a standardized interface for interoperability and governed context updates across heterogeneous engineering environments. It is not the same thing as the INCOSE Model Characterization Pattern (computational-model trust metadata).
Context Servers at each tool node (CATIA, Ansys, MATLAB)
URI-based IdentityRegistry mapping local tool IDs to global VectorMBE URIs
Asynchronous ContextUpdate events propagated through a dependency DAG
Eventually-consistent registry via consensus protocol
vectormbed (roadmap): Rust runtime with async I/O and a work-stealing queue
vectormbed: core runtime · roadmap
Rust runtime: streaming I/O and vector search
vectormbed is in active development as the production-grade runtime for VectorMBE. It is implemented in Rust for memory safety, predictable performance, and safe concurrency. The planned architecture emphasizes:
mmap: memory-mapped files for embedding manifolds and axiom sets, efficient access to large models with minimal copy overhead
Lock-free structures: RCU for read-heavy graph paths; Tokio-backed channels for inter-component messaging
HNSW / Faiss: approximate nearest-neighbor indexing for vector search, with optional GPU acceleration for large corpora
Layered stack · roadmap
Four layers, one substrate
These layers describe the same roadmap substrate: symbolic graphs, continuous embeddings, governed constraints, and MCP-mediated coordination.
Ontology layer: OWL/RDF persisted in an RDF triple store with SPARQL access. Maintains symbolic axioms and supports formal reasoning over the knowledge graph.
Vector layer: HNSW / Faiss ANN index for embedding similarity search, with live ingestion from simulation and telemetry streams.
Safety constraint layer: constraint solver (SMT or rules engine) continuously evaluates governed safety predicates; violations gate or annotate downstream inference.
Model Context Protocol layer: ContextUpdate event bus, IdentityRegistry, and dependency DAG. This is the coordination plane that connects tools and context servers across the workflow (Model Context Protocol, not "model characterization" metadata).
Hands-on
Try the VectorMBE MCP bridge (Cursor & Claude Desktop)
Cursor and Claude Desktop each read one JSON file on disk. If you built vectormbe-mcp and run vectormbed, paste one matching script below. It loads any existing config, sets mcpServers.vectormbe-runtime, and writes the file back—your other MCP entries stay in place. Then fully quit and restart the application. JSON shape and prerequisites: MBSE overview · Register the MCP server; sources: VectorMBE.
Before you paste
vectormbe-mcp is on your PATH, or change the line that sets "command" to the absolute path of your binary.
After the script prints "Done," restart Cursor or Claude Desktop (whichever config you patched).
Cursor — ~/.cursor/mcp.json (Linux, macOS, WSL)
Registers the server for all workspaces. For one repo only, edit the script: set config_path to your project’s .cursor/mcp.json path.
Cursor · ~/.cursor/mcp.json
python3 << 'EOF'
import json, os
config_path = os.path.expanduser("~/.cursor/mcp.json")
os.makedirs(os.path.dirname(config_path), exist_ok=True)
try:
with open(config_path) as f:
config = json.load(f)
except (FileNotFoundError, json.JSONDecodeError):
config = {}
config.setdefault("mcpServers", {})["vectormbe-runtime"] = {
"type": "stdio",
"command": "vectormbe-mcp",
"args": [],
"env": {
"VECTORMBE_LOG_LEVEL": "info"
}
}
with open(config_path, "w") as f:
json.dump(config, f, indent=2)
print("Done! Config written to:", config_path)
EOF
Claude Desktop — macOS (bash / zsh)
Claude Desktop · macOS
python3 << 'EOF'
import json, os
config_path = os.path.expanduser("~/Library/Application Support/Claude/claude_desktop_config.json")
os.makedirs(os.path.dirname(config_path), exist_ok=True)
try:
with open(config_path) as f:
config = json.load(f)
except (FileNotFoundError, json.JSONDecodeError):
config = {}
config.setdefault("mcpServers", {})["vectormbe-runtime"] = {
"type": "stdio",
"command": "vectormbe-mcp",
"args": [],
"env": {
"VECTORMBE_LOG_LEVEL": "info"
}
}
with open(config_path, "w") as f:
json.dump(config, f, indent=2)
print("Done! Config written to:", config_path)
EOF
Claude Desktop — Linux, WSL2, or Git Bash on Windows
Claude Desktop · Linux / WSL / Git Bash
python3 << 'EOF'
import json, os
config_path = os.path.expanduser("~/.config/Claude/claude_desktop_config.json")
os.makedirs(os.path.dirname(config_path), exist_ok=True)
try:
with open(config_path) as f:
config = json.load(f)
except (FileNotFoundError, json.JSONDecodeError):
config = {}
config.setdefault("mcpServers", {})["vectormbe-runtime"] = {
"type": "stdio",
"command": "vectormbe-mcp",
"args": [],
"env": {
"VECTORMBE_LOG_LEVEL": "info"
}
}
with open(config_path, "w") as f:
json.dump(config, f, indent=2)
print("Done! Config written to:", config_path)
EOF
Claude Desktop — Windows (PowerShell — paste as one block)
Writes %APPDATA%\Claude\claude_desktop_config.json. Uses a here-string so you do not need bash. If python is not found, try py -3 in place of python.
Claude Desktop · PowerShell
@'
import json
import os
from pathlib import Path
appdata = os.environ.get("APPDATA")
if not appdata:
raise SystemExit("APPDATA is not set.")
config_path = Path(appdata) / "Claude" / "claude_desktop_config.json"
config_path.parent.mkdir(parents=True, exist_ok=True)
try:
config = json.loads(config_path.read_text(encoding="utf-8"))
except (FileNotFoundError, json.JSONDecodeError):
config = {}
config.setdefault("mcpServers", {})["vectormbe-runtime"] = {
"type": "stdio",
"command": "vectormbe-mcp",
"args": [],
"env": {
"VECTORMBE_LOG_LEVEL": "info"
}
}
config_path.write_text(json.dumps(config, indent=2), encoding="utf-8")
print("Done! Config written to:", config_path)
'@ | python -
Git Bash or WSL on Windows can use the Linux script above. If python - does not read stdin on your install, save the Python lines (without the PowerShell wrappers) into patch_claude_mcp.py and run python patch_claude_mcp.py.
Prefer raw JSON?
Copy the block from MBSE overview · Register the MCP server into the right file (~/.cursor/mcp.json vs Claude’s path). If the file already lists other MCP servers, add only the vectormbe-runtime object inside mcpServers.
Industry alignment
Model Characterization Pattern × VectorMBE
The MBSE community’s Model Characterization Pattern (same "MCP" acronym as in the MBSE wiki—not Anthropic’s Model Context Protocol) is the official S*Pattern for universal characterization and labeling of computational models: stakeholder and technical requirement groups, VVUQ, lifecycle, interoperability, and trusted reuse across supply chains—exactly as summarized in the v1.8.1 specification’s stated purposes. VectorMBE aligns with that intent as governed-graph substrate: OWL individuals and properties hold structured characterization; vectors support similarity search across model families and evidence; governed safety constraints encode non-negotiable limits; Model Context Protocol (the AI tool protocol) connects authoring and execution tools so evidence stays attached to URIs. We do not claim a complete, out-of-the-box encoding of every configurable feature group in the pattern PDF—implementation evolves in the VectorMBE codebase.
Basic Formal Ontology (BFO): VectorMBE's class hierarchy is grounded in BFO:Entity — the OBO Foundry top-level ontology used across defense, life sciences, and engineering knowledge graphs. Aligning VectorMBE individuals to BFO enables interoperability with any BFO-conformant ontology, including those used in DoD digital engineering and acquisition programs.
DoD / OUSD(R&E)Systems Engineering Research Center
DoD Research Foundation: The SERC Handbook on Digital Engineering with Ontologies v2.0 — published by OUSD(R&E) — is the authoritative DoD reference for formal ontology application across acquisition programs. VectorMBE's architecture is built directly on its principles: OWL as the governed system-of-record, semantic interoperability, and trust-grade model characterization.
VectorMBE connects airworthiness requirements from FAR Part 25 through system architecture down to verification test records. When a design change touches a safety-critical function, governed safety constraints block progression until all affected verification items are resolved. The graph surfaces the full traceability chain on demand so teams spend less time hunting evidence and more time on engineering decisions.
Similarity search over historical simulation results and test evidence
Safety constraints for structural and thermal limits
MCP synchronization across CAD, analysis tools, and PLM in real time
FAA complianceSimulation integrationDesign reuse
Automotive
Closed-loop failure detection
Import Simulink models (`.slx` / `.mdl`) directly into the VectorMBE graph — blocks, subsystems, ports, and signal lines become first-class OWL individuals linked to requirements and verification evidence. Embed real-time vehicle fleet telemetry into the same space so anomalies cluster near known failure modes and MCP-based alerts fire to the design team before failure, not after.
Native .slx (R2012b+ OPC/ZIP) and .mdl (legacy plain-text) import
Blocks, subsystems, ports, and signal names ingested as OWL entities
Continuous telemetry ingestion into the embedding manifold
Anomaly detection via ANN proximity to known-bad clusters
Automated MCP ContextUpdate propagation to engineering tools
The transition from model-driven to autonomous engineering represents the final stage of industrial digitalization. In this vision, the engineering system is no longer a static blueprint or a manually maintained artifact. It is a continuously synchronized, learning program that generates its own requirements, detects its own change impacts, and closes its own verification loops as new data arrives.
VectorMBE provides the unified substrate to realize this future: a system that bridges formal logic and high-dimensional data, grounds statistical learning in governed safety constraints, propagates real-world signals autonomously into the model graph, and maintains trust-grade characterization for computational models alongside system architecture. Safely, traceably, and at scale.
This vision is not speculative — it is the direct commercial realization of the principles codified in the SERC Handbook on Digital Engineering with Ontologies v2.0, the DoD's authoritative standard for ontology-based digital engineering programs. VectorMBE is the engineering platform that brings that standard into production.
"VectorMBE + MCP: A Hybrid reasoning architecture for agent-ready systems engineering," Vector Stream Systems, April 2026. For research and decision support only.
Get started
VectorMBE is the autonomous systems engineering platform for safety-critical programs. If you work in aerospace, automotive, defense, or infrastructure and want to connect your engineering toolchain to generate requirements, synthesize complex safety assessments, reason about architecture, track change impact, and close verification loops automatically, reach out.
The mobile app is intentionally different from the desktop. It is built for engineers who are
physically with the hardware — on the test floor, in the lab, or in the field — not sitting at a workstation.
✅
What mobile is for
📋 Reviewing requirements — search, filter by status and priority, read full requirement text
📸 Capturing verification evidence — take photos of test setups, failures, inspection results
📎 Uploading test artifacts — attach PDFs, CSV test results, log files linked to specific requirements
🤖 AI assistant — ask questions about requirements, traceability, and verification status
⚠️
Not available on mobile
🚫 SysML block diagrams — impossible to read and interact with on a phone screen
🚫 Graph explorer — 400+ node graphs are not navigable on mobile
🚫 Diagram authoring — creating and editing diagrams requires a desktop
🚫 Ontology browser — hierarchy views require screen space
These features require the VectorMBE desktop app.
The mobile and desktop apps share the same backend — evidence you upload on mobile
is immediately visible in the desktop.
🔄
Typical field workflow
Engineer opens a requirement on mobile during a test
Takes a photo of the test setup or a failure mode
Attaches a CSV or PDF test result file
Adds a note describing the observation
Evidence syncs to the desktop model in real time
Systems engineer updates verification status on desktop
Mobile is a field companion, not a replacement for the desktop. If your workflow involves
diagramming, model editing, or large-scale graph exploration, use the VectorMBE desktop app.
The mobile app exists so engineers on the floor don't have to walk back to a workstation to log
a finding against a requirement.