System Vision: AI-Native Hardware Design Platform

The definitive architectural blueprint for MetaForge

Table of Contents

1. What MetaForge Is
   1. Digital Twin Evolution Layers
2. High-Level Architecture
3. Architectural Principles
   1. 1. Twin Owns Semantic Truth
   2. 2. Files Are Projections
   3. 3. Skills Are Pure
   4. 4. Tool Isolation
   5. 5. Extensibility
   6. 6. Human-In-The-Loop
   7. 7. Event-Driven Coordination
   8. 8. Everything Versioned
4. Layer Details
   1. Digital Twin Core
   2. Orchestrator
   3. Domain Agents
   4. Skill Registry
   5. MCP Layer
   6. IDE Assistants
5. Data Flow
6. Strategic Positioning
7. Terminology
8. Related Documents

What MetaForge Is

MetaForge is an AI-Native Hardware Design Platform built on five foundational pillars:

This is not just agents, just MCP, just skills, or just workflow. It is the integrated whole.

Digital Twin Evolution Layers

The Digital Twin is delivered incrementally across four layers:

See Digital Twin Evolution for the full architecture.

High-Level Architecture

IDE Assistants and Domain Agents operate on the Digital Twin concurrently. Assistants surface previews and diffs to the engineer while agents read context, execute tools, and write artifacts — all against the same shared artifact graph. The Orchestrator coordinates both tracks and routes change proposals back through the approval loop.

flowchart TD
    HUMAN(("Engineer")) -->|"design intent"| UI["IDE / CLI"]
    UI -->|"structured request"| GW["Gateway · Assistant API"]

    GW --> ORCH

    subgraph ORCH["Orchestrator"]
        direction LR
        EB["Event Bus"] ---|publish / subscribe| DEP["Dependency Engine"]
        DEP ---|resolve order| SCHED["Scheduler · DAG"]
    end

    ORCH -->|"coordinate"| ASSIST
    ORCH -->|"dispatch tasks"| AGENTS

    subgraph ASSIST["IDE Assistants — concurrent"]
        direction LR
        A_CAD["CAD"]
        A_PCB["PCB"]
        A_FW["Firmware"]
        A_SIM["Simulation"]
    end

    subgraph TWIN["Digital Twin — Single Source of Truth"]
        direction LR
        GRAPH["Artifact Graph"]
        VER["Versioning"]
        CONST["Constraint Engine"]
    end

    subgraph AGENTS["Domain Agents — concurrent"]
        direction LR
        ME["Mechanical"]
        EE["Electronics"]
        FW["Firmware"]
        SIM["Simulation"]
    end

    ASSIST <-->|"read state · show diffs · propose changes"| TWIN
    AGENTS <-->|"read context · write artifacts · validate constraints"| TWIN

    AGENTS -->|"invoke skills"| SR["Skill Registry<br/>Loader · Schema Validator · MCP Bridge"]
    SR -->|"MCP protocol"| MCP["MCP Layer<br/>Client · Protocol · Tool Registry"]
    MCP -->|"execute"| TOOLS

    subgraph TOOLS["External Tools"]
        direction LR
        T1["FreeCAD"]
        T2["KiCad"]
        T3["SPICE"]
        T4["CalculiX"]
        T5["Supplier APIs"]
    end

    TOOLS -.->|"results"| MCP
    MCP -.->|"structured output"| SR
    SR -.->|"skill output"| AGENTS

    TWIN -.->|"change proposal"| ORCH
    ORCH -.->|"approval request"| GW
    GW -.->|"diff preview"| UI
    UI -.->|"approve / reject"| GW
    GW -.->|"commit"| TWIN

    style TWIN fill:#2C3E50,color:#fff,stroke:#E67E22,stroke-width:3px
    style ORCH fill:#8e44ad,color:#fff
    style GW fill:#2C3E50,color:#fff
    style HUMAN fill:#E67E22,color:#fff
    style ASSIST fill:#3498db,color:#fff,stroke:#3498db
    style AGENTS fill:#3498db,color:#fff,stroke:#3498db
    style MCP fill:#e67e22,color:#fff

Data flow key:

Architectural Principles

1. Twin Owns Semantic Truth

The Semantic Digital Twin owns all design state. Entities, constraints, relationships, and versions live in the twin’s graph — this is the authoritative representation. Files are projections of twin state, not the source of truth. When an agent modifies a design, it proposes a semantic mutation to the twin; the twin then projects updated artifacts (CAD files, schematics, BOMs) through the MCP execution layer.

2. Files Are Projections

Design files (STEP, KiCad, Gerbers) are generated outputs of the semantic twin, not primary data. The twin maintains the semantic model; MCP adapters project it into tool-specific file formats. This means:

• The twin can exist without files (semantic iterations happen without artifact projection)
• Files are always regenerable from twin state
• Drift detection ensures file-world stays synchronized with twin-world — the Assistant Mode layer provides bidirectional sync via watchfiles change detection (file → graph) and MCP projection (graph → file), with a periodic reconciler to catch offline edits

3. Skills Are Pure

Skills must produce structured, reproducible outputs given the same inputs. Skills are deterministic capability modules invoked by agents — they are not autonomous. A skill must never:

• Trigger another agent
• Emit events
• Call MCP directly
• Persist state

Only agents orchestrate, decide, emit mutation proposals, and trigger projection. Skills are the analytical capabilities agents use to reason about engineering problems.

4. Tool Isolation

All external tools are accessed exclusively through the MCP protocol layer. No agent directly invokes a tool binary. This ensures:

• Consistent error handling
• Execution logging and tracing
• Tool version management
• Container-based isolation

5. Extensibility

Tools and skills are auto-discoverable via their respective registries. Adding a new tool or skill requires:

• A schema definition
• A handler implementation
• Registration in the appropriate registry
• No core platform changes

6. Human-In-The-Loop

IDE Assistants mediate all changes to the Digital Twin. No autonomous modification of design artifacts without human review and approval. The assistant layer provides:

• Change previews and diffs
• Approval workflows
• Context-aware suggestions
• Domain-specific UI integration

7. Event-Driven Coordination

All state changes flow through an event bus. Components subscribe to relevant events rather than polling or directly calling each other. This enables:

• Decoupled multi-agent coordination
• Safe cross-domain propagation
• Complete audit trail
• Reactive UI updates

8. Everything Versioned

Both semantic state and artifact state maintain independent version histories linked through Git commits. The dual state machine ensures that semantic evolution can proceed independently of file projection, while maintaining traceability between the two.

Layer Details

Digital Twin Core

The Digital Twin begins as a Digital Thread (L1) — a versioned, constraint-aware artifact graph — and evolves through synchronization (L3) and simulation (L4) layers into a full Digital Twin per ISO/IEC 30173:2025.

Orchestrator

The Orchestrator coordinates multi-agent workflows through event-driven execution.

Domain Agents

Each domain agent encapsulates engineering expertise as a collection of skills.

Skill Registry

Skills are the atomic units of domain expertise — deterministic, schema-validated, independently testable.

MCP Layer

The MCP (Model Context Protocol) layer provides standardized tool access.

IDE Assistants

IDE-embedded assistants provide contextual AI assistance within engineering tools.

Data Flow

sequenceDiagram
    participant User as Engineer (IDE)
    participant Assist as IDE Assistant
    participant Orch as Orchestrator
    participant Twin as Digital Twin
    participant Agent as Domain Agent
    participant Skill as Skill Registry
    participant MCP as MCP Layer
    participant Tool as External Tool

    User->>Assist: Design intent
    Assist->>Orch: Structured request
    Orch->>Twin: Query current state
    Twin-->>Orch: Artifact graph + constraints
    Orch->>Agent: Execute with context
    Agent->>Skill: Invoke skill
    Skill->>MCP: Tool call (MCP protocol)
    MCP->>Tool: Execute tool
    Tool-->>MCP: Result
    MCP-->>Skill: Structured result
    Skill-->>Agent: Skill output
    Agent->>Twin: Propose state change
    Twin->>Twin: Validate constraints
    Twin-->>Orch: Change proposal
    Orch-->>Assist: Change preview
    Assist-->>User: Show diff + approval
    User->>Assist: Approve
    Assist->>Twin: Commit change

Strategic Positioning

MetaForge is positioned as:

Open AI-Native Hardware Infrastructure — not “AI Agents for fun.”

This attracts serious engineers — mechanical engineers, PCB designers, firmware developers, and open-source tool developers.

Terminology

Related Documents

Document Version: v1.1 Last Updated: 2026-02-28 Status: Technical Program Document