Skip to content
Vector Stream Systems logoVector Stream Systems

Before the math

Framework, language, or skill?

  • 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.

Principle 1 — Handbook §2

Ontology as the authoritative system-of-record

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).

Core architecture

Three interlocking layers

Layer 1

VectorMBE: the ontology

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

  1. vectormbe-mcp is on your PATH, or change the line that sets "command" to the absolute path of your binary.
  2. 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.

Primary reference: Model Characterization Pattern v1.8.1. Product narrative: Framework · computational models.

Foundational OntologyOBO · BFO 2020

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.

BFO:Entity on Ontobee ↗
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.

See the full SERC foundation section ↓
Industrial application

Use cases

Aerospace

Aircraft design optimization

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
Simulink .slx/.mdlTelemetryAnomaly detectionProactive safety
Comparative analysis

VectorMBE + MCP vs. existing approaches

FeatureSysML v2Digital TwinVectorMBE + MCP
Reasoning modeSymbolic / LogicalPhysics-basedHybrid (OWL + vectors)
Data integrationManual / API-basedReal-time streamReal-time manifold sync
Model importNative SysML v2Tool-specific adaptersSysML v1/v2 · UML · XMI · Ecore · ReqIF · RDF · Simulink .slx/.mdl
Safety layerStatic constraintsSimulation-basedDynamic governed safety constraints
AI readinessLowMediumHigh (native embeddings)
Computational model catalog / trust metadataTool-dependent add-onsOften runtime-centricOWL + vectors + MCP evidence paths (aligned with characterization patterns)
Vision

The autonomous systems engineering substrate

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.

Contact us

Mobile companion

VectorMBE Mobile — Field-First, Not Desktop-Lite

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

  1. Engineer opens a requirement on mobile during a test
  2. Takes a photo of the test setup or a failure mode
  3. Attaches a CSV or PDF test result file
  4. Adds a note describing the observation
  5. Evidence syncs to the desktop model in real time
  6. 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.