AI Initiative logoAI Initiative
Reading room / Conduir Spatial

3D Product Forge — Architecture Specification

Proposes building products in a shared 3D environment, applying physics and constraints, then extracting specifications.

Product concept architecture
This is the retained source text, not a new validation of its claims. Numerical results and comparative claims require the accompanying source review before public reuse.

Read the connected case study or article →

Not explicitly attributed in document header · 2026-03-03

Provenance, authorship and editorial notes

3D Product Forge — Architecture Specification

Id

spatial-product-forge

Project

Conduir Spatial

Source path

conduir-spatial/docs/ARCHITECTURE-3D-PRODUCT-FORGE.md

Source host

genesis

Source sha256

2d9510da1c943684fea4dab23c9716589ca31971ee2bd4db915823bba93f867b

Repo root

conduir-spatial

Repo head

af341d6fc10f561455f76649800bbb064b82b083

Date

2026-03-03

Author

Not explicitly attributed in document header

Document status

Product concept architecture

Source status statement

Architecture Draft

Summary

Proposes building products in a shared 3D environment, applying physics and constraints, then extracting specifications.

Topics
  • Shared Worlds
  • Simulation
  • Orchestration
  • Conduir Spatial
  • Product concept architecture
Related ids
  • spatial-long-vision
  • spatial-technical
  • spatial-xr
Evidence concerns
  • Explicit version 0.1 vision draft. Physics-validated products, automatic gates and graph integration are proposed, not certified.
  • Private source selection. Source inspection only; no fresh build, deployment or effectiveness certification.
Copy scope

Full original document, byte-identical

Copy status

copied-private-review

Format

markdown

Bytes

69524

Word count

7371

Headings
  • 3D Product Forge — Architecture Specification
  • 1. The Thesis
  • 2. Architecture Overview
  • 3. Concrete Scenario: Drone Frame
  • 3.1 The Journey
  • 4. Product Kernel
  • 4.1 Core Data Model
  • 4.2 Assembly Graph
  • 4.3 Constraint Propagation
  • 5. Physics Runtime
  • 5.1 Solver Architecture
  • 5.2 Solver Strategy by Fidelity
  • 5.3 Visualization Modes
  • 6. Domain Agents
  • 6.1 Agent Taxonomy
  • 6.2 Agent Communication
  • 6.3 Agent Conflict Resolution
  • 7. The Constraint Graph (GraFOSa Integration)
  • 7.1 Node Types for Product Development
  • 7.2 GraFOSa Queries in the Forge
  • 7.3 Product Health Dashboard (L7)
  • 8. Validation Gates
  • 8.1 Gate Architecture
  • 8.2 Gate Types
  • 8.3 Gate Visualization
  • 9. Spec Extraction Engine
  • 9.1 Extraction Pipeline
  • 9.2 Drawing Auto-Generation
  • 10. Multi-Domain Product Types
  • 10.1 Electronics Product
  • 10.2 Mechanical Assembly (e.g., Gearbox)
  • 10.3 Software-Hardware Hybrid (IoT Device)
  • 11. Technology Stack
  • 11.1 Core Dependencies (extends conduir-spatial)
  • 11.2 WASM Modules
  • 11.3 Cloud Fallback
  • 12. Integration with Conduir-Spatial
  • 12.1 Scene Node Extensions
  • 12.2 New Overlay Renderers
  • 12.3 Store Extensions
  • 12.4 SSE Events (Product Forge additions)
  • 13. Implementation Phases
  • Phase F0: Foundation (Weeks 1-3)
  • Phase F1: Physics Runtime (Weeks 4-6)
  • Phase F2: Generative Design (Weeks 7-9)
  • Phase F3: Validation Pipeline (Weeks 10-12)
  • Phase F4: Spec Extraction (Weeks 13-14)
  • Phase F5: Domain Expansion (Weeks 15+)
  • 14. Key Architectural Decisions
  • D1: Physics in Browser (WASM) vs Cloud
  • D2: Geometry Kernel Choice
  • D3: Constraint Graph = GraFOSa (not a separate system)
  • D4: Agents Use Constraint Graph, Not Direct Messaging
  • D5: Hard Gates Cannot Be Overridden
  • D6: Spec is Always Extractable
  • 15. Success Criteria
  • Functional
  • Performance
  • Quality
Sensitive content review
Automated secret patterns
Email occurrences

0

Customer record terms
Limitation

Pattern scan plus editorial review; not a guarantee of no personal or proprietary material. Private copies retain source code examples, internal locations and attributions.

Attribution note

Source document attribution is preserved. Repository ownership or an agent role is not automatically authorship.

Date basis

Document header or dated filename; source may contain later updates

Source pin note

SHA-256 binds exact copied working-file bytes; repo_head is repository context, not proof that every byte is committed at that head.

Publication recommendation

Private technical reading candidate; editorial selection and claim review required before public use

3D Product Forge — Architecture Specification

Version: 0.1 (Vision)
Date: 2026-03-03
Status: Architecture Draft
Extends: conduir-spatial (TECHNICAL-SPEC.md), GraFOSa (constraint graph)


1. The Thesis

Products should be born in 3D, validated by physics, and extracted as specs —
never the reverse. Today's workflow starts with documents, translates them
into CAD, bolts on simulation as an afterthought, and hopes the spec
matches the physical reality. The 3D Product Forge inverts this:

Traditional                              3D Product Forge
═══════════                              ═══════════════
Written spec → CAD model → Simulate      Speak intent → 3D entity materializes
→ Fix → Re-simulate → Spec update        → Physics always on → Agents optimize
                                          → Validation gates auto-pass/fail
Sequential, document-first               → Spec extracted from validated state

Core principle: The 3D space IS the development environment.
The spec is a derivative artifact, not the source of truth.


2. Architecture Overview

╔══════════════════════════════════════════════════════════════════════════════╗
║                           3D PRODUCT FORGE                                  ║
║                                                                             ║
║  ┌─────────────────────────────────────────────────────────────────────┐    ║
║  │                    SPATIAL INTERFACE (conduir-spatial)               │    ║
║  │  Three.js + R3F + XR │ Voice │ Gesture │ Desktop + Quest 3         │    ║
║  └──────────────┬──────────────────────────────┬──────────────────────┘    ║
║                 │ scene mutations               │ physics overlays          ║
║  ┌──────────────┴──────────────┐  ┌────────────┴──────────────────┐       ║
║  │      PRODUCT KERNEL         │  │      PHYSICS RUNTIME          │       ║
║  │                             │  │                                │       ║
║  │  Parametric Geometry (BRep) │  │  Rapier (rigid body, joints)  │       ║
║  │  Constraint Solver          │  │  FEA Solver (stress, strain)  │       ║
║  │  Material Database          │  │  CFD Solver (flow, thermal)   │       ║
║  │  Assembly Graph             │  │  Kinematic Solver (motion)    │       ║
║  │  Tolerance Engine           │  │  Electromagnetic (optional)   │       ║
║  └──────────────┬──────────────┘  └────────────┬──────────────────┘       ║
║                 │ parametric state               │ physics state            ║
║  ┌──────────────┴──────────────────────────────┴──────────────────┐       ║
║  │                    CONSTRAINT GRAPH (GraFOSa)                   │       ║
║  │                                                                  │       ║
║  │  Nodes: Part, Assembly, Material, Constraint, LoadCase,         │       ║
║  │         Standard, Tolerance, ManufacturingProcess, CostDriver   │       ║
║  │  Edges: CONSTRAINS, DEPENDS_ON, COMPOSED_OF, MADE_FROM,        │       ║
║  │         VALIDATED_BY, MANUFACTURED_BY, AFFECTS_COST             │       ║
║  │                                                                  │       ║
║  │  blast_radius(part) → what breaks if this changes               │       ║
║  │  validate_changes(part) → are all constraints still met          │       ║
║  │  trace_path(load → failure) → how does force propagate          │       ║
║  └──────────────┬──────────────────────────────┬──────────────────┘       ║
║                 │                               │                          ║
║  ┌──────────────┴──────────────┐  ┌────────────┴──────────────────┐       ║
║  │      DOMAIN AGENTS          │  │      VALIDATION GATES         │       ║
║  │                             │  │                                │       ║
║  │  Structural Agent           │  │  Structural Integrity Gate    │       ║
║  │  Thermal Agent              │  │  Thermal Envelope Gate        │       ║
║  │  Manufacturing Agent        │  │  Manufacturability Gate       │       ║
║  │  Cost Agent                 │  │  Cost Budget Gate             │       ║
║  │  Compliance Agent           │  │  Standards Compliance Gate    │       ║
║  │  Assembly Agent             │  │  Assembly Feasibility Gate    │       ║
║  └─────────────────────────────┘  └───────────────────────────────┘       ║
║                                                                             ║
║  ┌─────────────────────────────────────────────────────────────────────┐    ║
║  │                    SPEC EXTRACTOR                                   │    ║
║  │  BOM │ Drawings (2D from 3D) │ Tolerances │ Assembly Sequence       │    ║
║  │  STEP/IGES export │ G-code │ Cost Estimate │ Test Plan              │    ║
║  └─────────────────────────────────────────────────────────────────────┘    ║
╚══════════════════════════════════════════════════════════════════════════════╝

3. Concrete Scenario: Drone Frame

To ground every decision, we walk through a complete product:
a carbon-fiber quadcopter frame carrying a 2kg payload at 40km/h.

3.1 The Journey

╭──────────────────────────────────────────────────────────────────────────────╮
│                                                                              │
│  USER enters /forge/new — empty void with Forge Orb                         │
│                                                                              │
│  USER (voice): "I need a quadcopter frame. Carbon fiber.                    │
│  2 kilo payload, 40 km/h cruise, IP54 rated."                               │
│                                                                              │
│  ═══ CONSTRAINT FIELD MATERIALIZES ═══                                      │
│                                                                              │
│  The void transforms. Visible constraints appear as spatial boundaries:     │
│                                                                              │
│  • Weight envelope: translucent sphere showing max mass budget              │
│    (2kg payload + frame + motors + battery = ~3.5kg total)                  │
│  • Force vectors: red arrows showing gravity (2kg down),                    │
│    thrust (4 × upward at motor mounts), drag (horizontal)                  │
│  • Airspeed corridor: blue tunnel showing 40km/h flow regime                │
│  • IP54 boundary: subtle grid showing ingress protection requirements       │
│  • Material properties panel: CF layup options floating nearby              │
│                                                                              │
│  These aren't decorations — they're ACTIVE CONSTRAINTS.                     │
│  The geometry that evolves must fit inside them.                             │
│                                                                              │
│  ═══ PLATFORMS RISE (same horseshoe as Scenario A) ═══                     │
│                                                                              │
│  ┌────────────┐     ┌──────────────┐     ┌───────────────┐  ┌───────────┐  │
│  │ CONSTRAIN  │────▶│  GENERATE    │────▶│   VALIDATE    │─▶│  EXTRACT  │  │
│  │            │     │              │     │               │  │           │  │
│  │ 2 agents   │     │ 3 agents     │     │ 4 agents      │  │ 1 agent   │  │
│  │ ~5 min     │     │ ~15 min      │     │ ~5 min        │  │ ~2 min    │  │
│  └────────────┘     └──────────────┘     └───────────────┘  └───────────┘  │
│       ▲                                                                     │
│  (user here)                                                                │
│                                                                              │
│  USER (voice): "Go"                                                         │
│                                                                              │
│  ═══ PLATFORM 1: CONSTRAIN ═══                                             │
│                                                                              │
│  Standards Agent (blue orb):                                                │
│  • Pulls FAA Part 107 weight limits → adds regulatory constraint node      │
│  • Pulls ASTM F3322 structural requirements                                │
│  • Constraint nodes appear as glowing boundary surfaces                    │
│                                                                              │
│  Materials Agent (amber orb):                                               │
│  • Queries material DB: T700 carbon fiber, Toray T800, recycled CF         │
│  • Material cards float at workbench showing:                              │
│    tensile strength, density, cost/kg, layup options                       │
│  • User touches T700 card → material selected → constraint field updates   │
│    (weight budget recalculates, stiffness bounds appear)                   │
│                                                                              │
│  ⟐ CHECKPOINT — Constraints defined                                        │
│  Gate shows: material selection, load cases, regulatory constraints         │
│  USER reviews force diagram, touches green orb → approved                  │
│                                                                              │
│  ═══ PLATFORM 2: GENERATE ═══                                              │
│                                                                              │
│  This is where it gets extraordinary.                                       │
│                                                                              │
│  Topology Agent (indigo orb, primary):                                      │
│  • Starts with a bounding volume (payload cube + 4 motor mounts)           │
│  • Runs topology optimization: material distributes itself in 3D            │
│  • User WATCHES the frame take shape:                                       │
│    - Arms grow outward toward motor positions                              │
│    - Central body forms around payload bay                                 │
│    - Material thickens at stress concentrations (arm roots)                │
│    - Material thins where load is low (between arms)                       │
│    - Lattice structure emerges in low-stress regions                       │
│  • Physics overlay (always on):                                            │
│    - Von Mises stress shown as heat map (blue=safe, red=yield)            │
│    - Displacement shown as exaggerated deformation                         │
│    - Weight counter ticking in HUD                                         │
│                                                                              │
│  USER walks around the forming frame at 1:1 scale.                          │
│  Points at an arm joint: "This needs to be a bolt connection,              │
│  not bonded — I want field-replaceable arms."                               │
│                                                                              │
│  Topology Agent pauses, acknowledges:                                       │
│  → Joint geometry restructures to accommodate M5 bolt pattern              │
│  → Stress recalculates (bolt holes are stress risers)                      │
│  → Material thickens around holes automatically                            │
│  → Weight counter ticks up 12g                                             │
│                                                                              │
│  Manufacturing Agent (green orb):                                           │
│  • Watches geometry evolve, flags issues in real-time:                     │
│    "Wall thickness 0.8mm at section B — below minimum for CF layup"       │
│  → Topology Agent adjusts, minimum wall 1.2mm                             │
│  • Checks draft angles, undercuts, tool access                             │
│  • Mold complexity estimate updates continuously                           │
│                                                                              │
│  Cost Agent (red orb, floating):                                            │
│  • Tracks material volume × $/kg                                           │
│  • Tooling cost estimate (mold complexity from Manufacturing Agent)         │
│  • Assembly time estimate                                                   │
│  • Running total displayed on HUD: "$142 unit cost @ 1000 qty"             │
│                                                                              │
│  ⟐ CHECKPOINT — Design complete                                            │
│  Gate shows: full 3D model, stress map, weight, cost                       │
│  USER examines: walks inside payload bay, checks wire routing paths        │
│  USER: "Add a cable channel from the flight controller bay to each ESC"    │
│  → Topology Agent adds internal channels, stress recalculates              │
│  USER touches green orb → approved                                         │
│                                                                              │
│  ═══ PLATFORM 3: VALIDATE ═══                                              │
│                                                                              │
│  Four agents run SIMULTANEOUSLY — results overlay on the same model:       │
│                                                                              │
│  Structural Validation Agent (red orb):                                     │
│  • Full FEA: 6 load cases (hover, forward flight, crash 10g, each arm)    │
│  • Results paint directly onto the 3D frame:                               │
│    - Load case 1 (hover): model glows green (all safe)                     │
│    - Load case 4 (crash 10g): arm roots go amber (1.8× FoS, pass)        │
│    - Load case 6 (single arm loss): remaining arms go RED (fail)          │
│  • Failure visualization: exaggerated deformation animation                │
│  • Result: PASS (with advisory: single arm loss exceeds limits,            │
│    acceptable per flight controller auto-land spec)                         │
│                                                                              │
│  Thermal Agent (orange orb):                                                │
│  • Motor heat dissipation through arm structure                            │
│  • Thermal gradient paints onto model (blue=ambient to red=motor)          │
│  • Checks: ESC bay temperature under sustained hover                       │
│  • Result: PASS (max 62°C at ESC mount, limit 85°C)                       │
│                                                                              │
│  Aerodynamics Agent (cyan orb):                                             │
│  • Simplified CFD: drag coefficient at 40km/h                              │
│  • Flow lines visualize around the frame                                   │
│  • Propwash interaction with frame surfaces                                │
│  • Result: PASS (Cd=0.42, acceptable for quad)                             │
│                                                                              │
│  Compliance Agent (white orb):                                              │
│  • FAA Part 107: weight ✓, no exposed blades ✓                            │
│  • ASTM F3322: structural margins ✓                                        │
│  • IP54: checks seal paths at bolt joints — FLAGS WARNING                  │
│    "Bolt pattern at arm joints needs O-ring groove for IP54"               │
│  → Model highlights joint faces, shows where seal groove needed            │
│  • Result: CONDITIONAL PASS (O-ring groove required)                       │
│                                                                              │
│  USER sees the IP54 flag. Walks to the arm joint.                           │
│  Sees the highlighted face where O-ring groove is needed.                   │
│  USER: "Add the O-ring groove."                                             │
│  → Topology Agent adds groove, stress recalculates, passes.                │
│  → Compliance Agent re-checks: PASS                                        │
│                                                                              │
│  All four validation gates now GREEN.                                       │
│                                                                              │
│  ═══ PLATFORM 4: EXTRACT ═══                                               │
│                                                                              │
│  Spec Extraction Agent (gold orb):                                          │
│  Artifacts materialize on the workbench:                                    │
│                                                                              │
│  • STEP file (ISO 10303) — full parametric geometry                        │
│  • 2D drawings (auto-generated from 3D):                                   │
│    - General arrangement (3-view + isometric)                              │
│    - Detail views (bolt patterns, O-ring grooves, cable channels)         │
│    - GD&T annotations extracted from tolerance engine                     │
│  • Bill of Materials:                                                       │
│    ┌──────────────────────────────────────────────────────┐                │
│    │ # │ Part           │ Material │ Qty │ Mass  │ Cost  │                │
│    │ 1 │ Central body   │ T700 CF  │ 1   │ 186g  │ $38   │                │
│    │ 2 │ Arm (×4)       │ T700 CF  │ 4   │ 62g   │ $14   │                │
│    │ 3 │ M5 bolt kit    │ Ti-6Al4V │ 4   │ 8g    │ $6    │                │
│    │ 4 │ O-ring (×4)    │ NBR 70   │ 4   │ 1g    │ $0.40 │                │
│    │ 5 │ Vibration mount│ Silicone │ 4   │ 4g    │ $2    │                │
│    │   │ TOTAL          │          │     │ 514g  │ $142  │                │
│    └──────────────────────────────────────────────────────┘                │
│  • Assembly sequence (3D animation):                                        │
│    1. Insert O-rings into body grooves                                     │
│    2. Align arm to body (locating pins)                                    │
│    3. Insert M5 bolts (4 per arm) → torque to 3.5 Nm                     │
│    4. Mount vibration isolators                                            │
│    5. Route cables through channels                                        │
│  • G-code for CNC mold cutting (if injection-molded CF)                   │
│  • Test plan:                                                               │
│    - Static load test: 5× payload at each arm                             │
│    - Vibration test: 20-2000Hz sweep per DO-160                           │
│    - IP54 spray test per IEC 60529                                        │
│    - Flight endurance: 30min hover at max payload                         │
│                                                                              │
│  All artifacts float as touchable 3D cards.                                │
│  USER touches STEP file → downloads.                                       │
│  USER touches assembly sequence → watches 3D animation.                    │
│  USER: "Send the BOM to procurement" → integration fires.                  │
│                                                                              │
│  ═══ FORGE COMPLETE ═══                                                     │
│                                                                              │
│  The validated drone frame hovers as a golden artifact in the center.       │
│  All four platforms glow green. Every constraint satisfied.                 │
│  From spoken intent to full manufacturing spec: ~27 minutes.               │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

4. Product Kernel

The Product Kernel extends conduir-spatial's SceneNode model with
parametric geometry and physics-aware properties.

4.1 Core Data Model

// Extends conduir-spatial's SceneNode
interface ForgeNode extends SceneNode {
  // Parametric geometry (replaces simple shape)
  geometry: ParametricGeometry | null

  // Physics binding
  physics: PhysicsBinding | null

  // Constraint participation
  constraints: ConstraintRef[]

  // Manufacturing metadata
  manufacturing: ManufacturingInfo | null
}

interface ParametricGeometry {
  type: "brep" | "mesh" | "voxel" | "point-cloud"

  // BRep: boundary representation (exact geometry)
  brep?: {
    format: "step" | "iges" | "opencascade"
    data: ArrayBuffer        // Serialized geometry
    parameters: Parameter[]  // Driving dimensions
  }

  // Mesh: triangulated approximation (for display + FEA)
  mesh?: {
    vertices: Float32Array
    indices: Uint32Array
    normals: Float32Array
    quality: "coarse" | "medium" | "fine"  // LOD
  }

  // Voxel: volumetric (for topology optimization)
  voxel?: {
    resolution: [number, number, number]
    data: Uint8Array  // density field (0=void, 255=solid)
    cellSize: number  // meters per voxel
  }
}

interface PhysicsBinding {
  // Rigid body (Rapier)
  rigidBody?: {
    mass: number           // kg
    centerOfMass: Vec3
    inertia: [number, number, number]  // principal moments
    colliderShape: "convex-hull" | "trimesh" | "compound"
  }

  // Structural (FEA)
  structural?: {
    material: MaterialId
    thickness?: number      // for shell elements
    meshType: "tet4" | "tet10" | "hex8" | "shell"
    loadCases: LoadCaseRef[]
  }

  // Thermal
  thermal?: {
    conductivity: number    // W/(m·K)
    heatSources: HeatSource[]
    convectionBoundary?: ConvectionBC
  }

  // Fluid
  fluid?: {
    domain: "internal" | "external"
    inletVelocity?: Vec3
    fluidProperties: FluidProperties
  }
}

interface Parameter {
  id: string
  name: string             // "arm_length", "wall_thickness"
  value: number
  unit: string             // "mm", "deg", "N"
  min?: number
  max?: number
  drivenBy?: ConstraintId  // parameter controlled by a constraint
  drivesGeometry: boolean  // changing this rebuilds geometry
}

interface MaterialDefinition {
  id: MaterialId
  name: string             // "T700 Carbon Fiber (unidirectional)"
  category: "metal" | "polymer" | "composite" | "ceramic" | "elastomer"

  // Mechanical
  youngsModulus: number    // Pa
  poissonsRatio: number
  yieldStrength: number   // Pa
  ultimateStrength: number // Pa
  density: number          // kg/m³
  fatigueLimit?: number    // Pa

  // Thermal
  thermalConductivity: number   // W/(m·K)
  thermalExpansion: number      // 1/K
  maxServiceTemp: number        // °C

  // Manufacturing
  minWallThickness: number // mm (process-dependent)
  maxPartSize: [number, number, number]  // mm
  availableProcesses: ManufacturingProcess[]

  // Cost
  costPerKg: number
  leadTimeDays: number

  // Visual (for 3D rendering)
  color: string
  roughness: number
  metalness: number
}

4.2 Assembly Graph

Products are hierarchical assemblies. The assembly graph is a tree
with constraint edges:

Assembly: Quadcopter Frame
├── Part: Central Body
│   ├── Feature: Payload Bay (pocket)
│   ├── Feature: FC Mount (boss pattern)
│   ├── Feature: Arm Interface ×4 (bolt pattern + O-ring groove)
│   └── Feature: Cable Channel ×4 (internal passage)
├── Part: Arm ×4
│   ├── Feature: Body Interface (matching bolt pattern)
│   ├── Feature: Motor Mount (4× M3 pattern)
│   └── Feature: ESC Bay (pocket)
├── Fastener: M5×16 Ti bolt ×16
├── Seal: NBR O-ring ×4
└── Isolator: Silicone mount ×4

Constraint Edges:
  Arm Interface ──MATES_WITH──▶ Body Interface  (position, bolt pattern)
  Central Body ──WEIGHS_LESS_THAN──▶ WeightBudget(350g)
  Arm ──WITHSTANDS──▶ LoadCase(hover, 4×thrust/4)
  O-ring groove ──SEALS──▶ IP54Requirement
  Cable Channel ──ROUTES──▶ ESC_to_FC_wiring
  Motor Mount ──THERMALLY_CONDUCTS──▶ ArmStructure

4.3 Constraint Propagation

When any parameter changes, constraints propagate through the graph:

User changes: arm_length = 200mm → 220mm

Constraint graph traversal:
  arm_length
    → arm_mass (recalculate: volume × density)
      → total_mass (sum of parts)
        → thrust_required (total_mass × g × safety_factor)
          → motor_selection (thrust table lookup)
            → motor_mount_pattern (new bolt pattern?)
              → arm_tip_geometry (rebuild if pattern changed)
    → arm_bending_moment (longer arm = higher moment at root)
      → root_stress (FEA re-solve for this load case)
        → structural_FoS (stress / yield)
          → VALIDATION GATE: still > 1.5?
    → frame_footprint (wider = more drag)
      → drag_at_cruise (CFD or empirical)
        → flight_time_estimate (drag → power → battery life)
    → cost_estimate (more material, larger mold)

This propagation is visible in 3D: constraint edges glow as they
propagate, affected parts pulse, and validation gates update in real-time.


5. Physics Runtime

5.1 Solver Architecture

Physics runs as a persistent background process, not a triggered batch:

┌─────────────────────────────────────────────────────┐
│                PHYSICS RUNTIME                       │
│                                                      │
│  ┌─────────────────┐  ┌──────────────────────────┐  │
│  │ Rapier Engine    │  │ FEA Engine               │  │
│  │ (WASM, 60Hz)    │  │ (WASM or cloud, on-demand)│  │
│  │                  │  │                           │  │
│  │ • Rigid body sim │  │ • Linear static          │  │
│  │ • Collision det  │  │ • Modal analysis         │  │
│  │ • Joint dynamics │  │ • Thermal steady-state   │  │
│  │ • Assembly test  │  │ • Fatigue (Miner's rule) │  │
│  └────────┬─────────┘  └────────────┬─────────────┘  │
│           │                          │                │
│  ┌────────┴──────────────────────────┴─────────────┐ │
│  │              Results Compositor                   │ │
│  │                                                   │ │
│  │  Merges physics results into unified overlay:    │ │
│  │  • Von Mises stress → color map on geometry      │ │
│  │  • Temperature → separate color map              │ │
│  │  • Displacement → exaggerated deformation        │ │
│  │  • Flow → particle streamlines                   │ │
│  │  • Safety factor → pass/fail per element         │ │
│  └───────────────────────┬───────────────────────────┘ │
│                          │ overlay data                 │
└──────────────────────────┼─────────────────────────────┘
                           ▼
                    3D Scene (conduir-spatial)
                    Physics overlay rendered on geometry

5.2 Solver Strategy by Fidelity

Not every change needs full FEA. The system uses tiered fidelity:

TriggerSolverFidelityLatencyUse
Parameter drag (real-time)Analytical beam/plateLow<16msLive feedback during manipulation
Parameter releaseRapier + simplified FEAMedium<2sQuick validation after each change
Checkpoint gateFull FEA (all load cases)High10-60sFormal validation before proceeding
Final validationFull FEA + CFD + thermalMaximum2-10minProduction-grade results

5.3 Visualization Modes

User can toggle overlays by voice or gesture:

CommandOverlayVisual
"Show stress"Von Mises stressBlue→green→yellow→red heat map
"Show displacement"Structural deformationExaggerated wireframe (10× scale)
"Show temperature"Thermal fieldBlue (cold) → white (hot)
"Show flow"Aerodynamic streamlinesAnimated particle paths
"Show safety"Factor of safetyGreen (>2×) → amber (1.5×) → red (<1×)
"Show weight"Mass distributionDensity heat map
"Show cost"Cost per region$/unit heat map (expensive regions glow)
"Clear overlays"NoneRaw material appearance

6. Domain Agents

6.1 Agent Taxonomy

Each agent is a specialized AI with domain knowledge, tools, and authority:

┌─────────────────────────────────────────────────────────────────────┐
│                        DOMAIN AGENTS                                │
│                                                                     │
│  CONSTRAIN PLATFORM                                                 │
│  ├── Standards Agent (blue)                                        │
│  │   Tools: regulatory DB, standards library (ISO, ASTM, FAA)     │
│  │   Authority: adds constraint nodes, cannot modify geometry      │
│  │   Knowledge: domain-specific regulations, certification paths   │
│  │                                                                  │
│  └── Materials Agent (amber)                                       │
│      Tools: material database (MatWeb/Granta/internal)             │
│      Authority: proposes materials, sets material constraints       │
│      Knowledge: material properties, process compatibility          │
│                                                                     │
│  GENERATE PLATFORM                                                  │
│  ├── Topology Agent (indigo, primary)                              │
│  │   Tools: topology optimizer, parametric modeler, constraint      │
│  │          solver                                                  │
│  │   Authority: creates/modifies geometry within constraints       │
│  │   Knowledge: structural optimization, design patterns,          │
│  │              generative design algorithms                       │
│  │                                                                  │
│  ├── Manufacturing Agent (green)                                   │
│  │   Tools: DFM analyzer, process selector, cost estimator         │
│  │   Authority: flags manufacturability issues, proposes DFM fixes │
│  │   Knowledge: CNC, injection molding, 3D printing, casting,     │
│  │              sheet metal, composites layup                      │
│  │                                                                  │
│  └── Cost Agent (red, advisory)                                    │
│      Tools: cost model (material + tooling + labor + overhead)     │
│      Authority: advisory only — displays cost, flags overruns      │
│      Knowledge: manufacturing economics, volume scaling             │
│                                                                     │
│  VALIDATE PLATFORM                                                  │
│  ├── Structural Validation Agent (red)                             │
│  │   Tools: FEA solver, load case manager, fatigue calculator      │
│  │   Authority: runs analysis, issues PASS/FAIL/CONDITIONAL        │
│  │   Knowledge: structural mechanics, failure modes, safety factors│
│  │                                                                  │
│  ├── Thermal Agent (orange)                                        │
│  │   Tools: thermal solver, convection calculator                  │
│  │   Authority: runs thermal analysis, issues PASS/FAIL            │
│  │   Knowledge: heat transfer, thermal management strategies       │
│  │                                                                  │
│  ├── Aerodynamics Agent (cyan)                                     │
│  │   Tools: CFD solver (simplified), drag calculator               │
│  │   Authority: runs flow analysis, issues PASS/FAIL               │
│  │   Knowledge: aerodynamics, propeller interaction                │
│  │                                                                  │
│  └── Compliance Agent (white)                                      │
│      Tools: standards checker, certification path analyzer         │
│      Authority: issues PASS/FAIL/CONDITIONAL against regulations   │
│      Knowledge: regulatory requirements, certification processes    │
│                                                                     │
│  EXTRACT PLATFORM                                                   │
│  └── Spec Extraction Agent (gold)                                  │
│      Tools: STEP exporter, drawing generator, BOM builder,         │
│             G-code post-processor, test plan generator              │
│      Authority: generates output artifacts from validated state     │
│      Knowledge: drafting standards, GD&T (ASME Y14.5),            │
│                 manufacturing documentation                        │
└─────────────────────────────────────────────────────────────────────┘

6.2 Agent Communication

Agents communicate through the constraint graph, not direct messaging:

Topology Agent modifies arm geometry
  → GraFOSa: arm node updated
  → GraFOSa: blast_radius(arm) = [root_stress, arm_mass, total_mass, ...]
  → Manufacturing Agent sees geometry change → re-checks DFM
  → Cost Agent sees material volume change → recalculates
  → Structural Agent sees geometry change → queues re-solve
  → All results written back to constraint graph nodes
  → Visualization updates automatically

This is event-driven via graph mutations, identical to how conduir-spatial
already handles SSE events → scene mutations.

6.3 Agent Conflict Resolution

When agents disagree (e.g., Topology wants thin walls, Manufacturing says minimum 1.2mm):

CONFLICT DETECTED:
  Topology Agent: wall_thickness = 0.8mm (optimal for weight)
  Manufacturing Agent: wall_thickness >= 1.2mm (minimum for CF layup)

Resolution hierarchy:
  1. Hard constraints win (physics, safety, regulations) → auto-resolve
  2. Manufacturing constraints override optimization → auto-resolve
  3. Cost vs performance → escalate to user (gate checkpoint)
  4. Aesthetic vs engineering → escalate to user

In this case: Manufacturing constraint is hard → auto-resolve to 1.2mm
Topology Agent acknowledges, re-optimizes with 1.2mm floor.
User sees: brief amber flash at the constrained region, tooltip explains.

7. The Constraint Graph (GraFOSa Integration)

7.1 Node Types for Product Development

# GraFOSa node types for the Product Forge
FORGE_NODE_TYPES = {
    # Product structure
    "Assembly":    {"icon": "layers",      "color": "#6366f1"},
    "Part":        {"icon": "cube",        "color": "#22c55e"},
    "Feature":     {"icon": "hexagon",     "color": "#3b82f6"},
    "Fastener":    {"icon": "link",        "color": "#64748b"},

    # Materials & manufacturing
    "Material":    {"icon": "circle",      "color": "#f59e0b"},
    "Process":     {"icon": "settings",    "color": "#10b981"},

    # Constraints & requirements
    "Constraint":  {"icon": "lock",        "color": "#ef4444"},
    "LoadCase":    {"icon": "arrow-down",  "color": "#dc2626"},
    "Standard":    {"icon": "shield",      "color": "#8b5cf6"},
    "Tolerance":   {"icon": "ruler",       "color": "#06b6d4"},

    # Validation
    "Validation":  {"icon": "check",       "color": "#16a34a"},
    "TestCase":    {"icon": "flask",       "color": "#0ea5e9"},

    # Cost
    "CostDriver":  {"icon": "dollar",      "color": "#e11d48"},
    "BOMLine":     {"icon": "list",        "color": "#78716c"},
}

FORGE_EDGE_TYPES = {
    "COMPOSED_OF":       "Assembly structure (parent → child)",
    "MADE_FROM":         "Part → Material",
    "CONSTRAINS":        "Constraint → Parameter/Feature",
    "DEPENDS_ON":        "Parameter → Parameter (driven)",
    "VALIDATED_BY":      "Part/Feature → Validation/TestCase",
    "MANUFACTURED_BY":   "Part → Process",
    "MATES_WITH":        "Feature → Feature (assembly interface)",
    "THERMALLY_CONDUCTS":"Part → Part (heat path)",
    "LOADS":             "LoadCase → Part/Feature",
    "COMPLIES_WITH":     "Part/Assembly → Standard",
    "AFFECTS_COST":      "Any change → CostDriver",
    "SEALS":             "Feature → Constraint (IP rating)",
    "ROUTES":            "Feature → Constraint (wiring/fluid path)",
}

7.2 GraFOSa Queries in the Forge

Every existing GraFOSa tool maps to product development operations:

GraFOSa ToolForge Use
blast_radius("arm-left")What parts, constraints, and validations are affected if this arm changes?
validate_changes("arm-left")After changing the arm, do all structural/thermal/compliance gates still pass?
trace_path("motor-heat", "esc-temperature")How does motor heat reach the ESC? Through which parts and interfaces?
dependencies("central-body")What materials, processes, constraints, and standards does the body depend on?
dependents("T700-carbon-fiber")Which parts use this material? What happens if we switch to T800?
what_if_remove("O-ring-seal")What fails if we remove the O-ring? (IP54 compliance)
bottlenecks()Which parts are the most constrained / hardest to change?
find_cycles("DEPENDS_ON")Are there circular parameter dependencies? (dangerous in constraint solving)
plan_change("arm-length")Full impact: which validations need re-running, estimated time, risk
optimize()Find over-constrained regions, redundant features, cost reduction opportunities
dead_code() → dead_features()Features that don't contribute to any constraint or requirement (waste)
project_health()Overall product health: constraint coverage, validation status, cost status

7.3 Product Health Dashboard (L7)

The GraFOSa health report adapted for product development:

╔══════════════════════════════════════════════════════════════╗
║  PRODUCT HEALTH: Quadcopter Frame v2.3          Grade: B+   ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  STRUCTURE          ██████████████████░░  90%  🟢            ║
║  12 parts, 4 assemblies, 16 interfaces                      ║
║  All mates defined. 2 features lack tolerance specs.         ║
║                                                              ║
║  CONSTRAINTS        ████████████████████  100% 🟢            ║
║  24 constraints, all bound to parameters                     ║
║  No unconstrained features. No circular dependencies.        ║
║                                                              ║
║  STRUCTURAL         ██████████████████░░  92%  🟢            ║
║  6 load cases, 5 PASS, 1 CONDITIONAL (single arm loss)      ║
║  Minimum FoS: 1.8× (arm root, crash 10g case)              ║
║                                                              ║
║  THERMAL            ████████████████████  100% 🟢            ║
║  Max temperature: 62°C (ESC bay) — limit 85°C              ║
║  All thermal paths validated.                                ║
║                                                              ║
║  MANUFACTURING      ████████████████░░░░  80%  🟡            ║
║  2 warnings: tight tolerance at cable channel entry,         ║
║  mold complexity high (8-piece mold for central body)        ║
║                                                              ║
║  COMPLIANCE         ██████████████████░░  95%  🟢            ║
║  FAA Part 107: PASS. ASTM F3322: PASS. IP54: PASS.         ║
║  Missing: CE marking documentation (non-blocking).           ║
║                                                              ║
║  COST               ████████████░░░░░░░░  65%  🟡            ║
║  Unit cost $142 @ 1000 qty (target: $120)                   ║
║  Tooling: $18,400 (amortized over first 1000 units)         ║
║  Primary driver: 8-piece mold for central body ($12,200)    ║
║                                                              ║
╚══════════════════════════════════════════════════════════════╝

8. Validation Gates

8.1 Gate Architecture

Validation gates are the 3D Product Forge equivalent of conduir-spatial's
checkpoint gates. They are physics-backed — not human opinion.

CHECKPOINT GATE (conduir-spatial)        VALIDATION GATE (Product Forge)
═══════════════════════════════         ═══════════════════════════════
Human reviews artifacts                  Physics engine evaluates
Human touches green/red orb             Auto-PASS/FAIL from solver results
Subjective approval                     Objective: FoS > 1.5? Temperature < Tmax?
Can be overridden                       Hard gates CANNOT be overridden
                                        Soft gates can be overridden with justification

8.2 Gate Types

GateTypeCriterionOverride?
Structural IntegrityHARDAll load cases FoS > requiredNever
Yield StrengthHARDNo element exceeds yieldNever
Fatigue LifeHARDCycles > required service lifeNever
Thermal LimitHARDMax temp < material service tempNever
Weight BudgetSOFTTotal mass < budgetWith justification
Cost TargetSOFTUnit cost < targetWith justification
ManufacturabilitySOFTAll features producibleWith process change
ComplianceMIXEDRegulatory = HARD, advisory = SOFTDepends

8.3 Gate Visualization

     ┌───┐
     │ ▲ │ ← Solver result indicator (▲=pass, ●=running, ✕=fail)
    ╱│   │╲
   ╱ │   │ ╲
  │  │ S │  │     Gate pillar (same arch as conduir-spatial)
  │  │ t │  │     But instead of approval orbs:
  │  │ r │  │
  │  │ u │  │     HARD GATE: auto-opens when solver says PASS
  │  │ c │  │                stays locked when FAIL (no override)
  │  │ t │  │
  │  │   │  │     SOFT GATE: auto-opens on PASS
  │  └───┘  │                shows override orb on FAIL
  │         │                (amber = override with justification)
  │  ═════  │ ← Energy barrier
  │         │    Color: green (pass), red (fail), amber (conditional)
  └─────────┘
  ▓▓▓▓▓▓▓▓▓▓▓ ← Bridge

Solver results displayed ON the gate:
  ┌──────────────────────────────────┐
  │  STRUCTURAL INTEGRITY            │
  │  Load case 1 (hover):    ✓ 3.2× │
  │  Load case 2 (forward):  ✓ 2.8× │
  │  Load case 3 (bank 45°): ✓ 2.1× │
  │  Load case 4 (crash 10g):✓ 1.8× │
  │  Load case 5 (drop 1m):  ✓ 2.4× │
  │  Load case 6 (arm loss): ⚠ 0.9× │ ← below threshold
  │                                   │
  │  RESULT: CONDITIONAL PASS         │
  │  (arm loss case exempted per      │
  │   flight controller auto-land)    │
  └──────────────────────────────────┘

9. Spec Extraction Engine

The spec is not authored — it's extracted from the validated 3D state.

9.1 Extraction Pipeline

Validated 3D Product State
  │
  ├── Geometry Kernel ──────────▶ STEP file (ISO 10303-214)
  │                              IGES file (legacy compatibility)
  │                              STL/3MF (for 3D printing)
  │
  ├── Drawing Generator ────────▶ 2D drawings (PDF/DXF)
  │   (auto-views from 3D)       General arrangement
  │   (auto-GD&T from             Section views
  │    tolerance engine)          Detail views with GD&T
  │                               Balloon callouts from BOM
  │
  ├── BOM Builder ──────────────▶ Bill of Materials
  │   (traverses assembly         Hierarchical (indented)
  │    graph via GraFOSa)         Flat (purchasing)
  │                               With costing
  │
  ├── Assembly Sequencer ───────▶ Assembly instructions
  │   (topological sort of        3D animation sequence
  │    MATES_WITH edges)          Torque specs from fastener DB
  │                               Tool requirements
  │
  ├── Manufacturing Planner ────▶ Process sheets
  │   (from MANUFACTURED_BY       CNC tool paths (G-code)
  │    edges + process params)    Mold design parameters
  │                               Quality inspection plan
  │
  └── Test Plan Generator ──────▶ Verification & validation plan
      (from VALIDATED_BY           Test procedures per load case
       edges + standards)          Pass/fail criteria
                                   Required equipment
                                   Certification path

9.2 Drawing Auto-Generation

The system generates engineering drawings from the 3D model automatically:

3D Model → View Selection Algorithm → 2D Projection → GD&T Annotation

View selection:
  1. Principal views: find model's 3 principal axes → front/top/right
  2. Isometric: standard ISO projection
  3. Section views: auto-detect internal features (bays, channels)
     → place section plane through feature centroid
  4. Detail views: auto-detect small features (bolt patterns, grooves)
     → 4:1 scale detail circles

GD&T annotation:
  1. Datum features: auto-select from assembly interfaces (MATES_WITH edges)
  2. Tolerances: extract from Tolerance nodes in constraint graph
  3. Surface finish: from manufacturing process requirements
  4. Material callout: from MADE_FROM edges

10. Multi-Domain Product Types

The architecture generalizes beyond drones. Domain-specific agent sets
plug into the same forge pipeline:

10.1 Electronics Product

CONSTRAIN:
  Standards Agent → IEC 62368, FCC Part 15, UL 60950
  Components Agent → selects ICs, passives from distributor DB (Digi-Key API)

GENERATE:
  Schematic Agent → creates circuit from requirements
  PCB Layout Agent → places components, routes traces
  Enclosure Agent → 3D enclosure around PCB + connectors
  Physics overlay: current density on traces, thermal on ICs, EMI field

VALIDATE:
  Electrical Agent → SPICE simulation, signal integrity
  Thermal Agent → junction temperatures, heatsink sizing
  EMC Agent → radiated emissions estimate, shielding effectiveness
  Compliance Agent → FCC pre-scan, CE self-declaration checklist

EXTRACT:
  Gerber files, BOM, pick-and-place, schematic PDF, test fixtures

10.2 Mechanical Assembly (e.g., Gearbox)

CONSTRAIN:
  Standards Agent → ISO 6336 (gears), ISO 281 (bearings)
  Requirements Agent → torque, speed, duty cycle, environment

GENERATE:
  Gear Train Agent → ratio selection, tooth profile generation
  Bearing Agent → bearing selection from SKF/Timken catalog
  Housing Agent → enclosure with seal design, oil galleries
  Physics overlay: contact stress on teeth, bearing life (L10), oil flow

VALIDATE:
  Structural Agent → gear tooth FEA, shaft deflection, key stress
  Tribology Agent → lubrication film thickness, wear prediction
  NVH Agent → gear mesh frequency, resonance check
  Thermal Agent → oil temperature rise, bearing thermal rating

EXTRACT:
  STEP files, gear inspection sheets (profile/lead/pitch), assembly sequence,
  lubrication specification, maintenance schedule

10.3 Software-Hardware Hybrid (IoT Device)

CONSTRAIN:
  Standards Agent → Bluetooth SIG, Matter protocol, IP67
  Requirements Agent → sensor accuracy, battery life, form factor

GENERATE:
  Firmware Agent → embedded C from requirements (Claude Code integration)
  PCB Agent → sensor + MCU + radio layout
  Enclosure Agent → IP67 enclosure with sensor windows
  Antenna Agent → PCB antenna or external, radiation pattern
  Physics overlay: RF field, battery discharge curve, thermal on MCU

VALIDATE:
  Electrical Agent → power budget vs battery capacity
  RF Agent → antenna pattern, link budget, interference
  Environmental Agent → IP67 ingress, drop test, thermal cycling
  Firmware Agent → static analysis, MISRA compliance, unit tests
  Integration Agent → end-to-end: sensor → MCU → radio → cloud

EXTRACT:
  Gerber + STEP + firmware binary + OTA update package + FCC test report
  + manufacturing test fixture design + user manual (from constraint graph)

11. Technology Stack

11.1 Core Dependencies (extends conduir-spatial)

ComponentTechnologyPurposeRuntime
3D EngineThree.js + R3FRendering, XRBrowser
Physics (rigid body)Rapier.rs (WASM)Real-time collision, jointsBrowser
Physics (FEA)CalculiX (WASM) or cloudStructural analysisHybrid
Physics (thermal)Elmer (WASM) or cloudHeat transferHybrid
Physics (CFD)Simplified panel method (WASM)AerodynamicsBrowser
Geometry kernelOpenCascade (WASM)BRep modeling, STEP I/OBrowser
Topology optimizerCustom SIMP/BESO (WASM)Generative designBrowser
Mesh generatorTetGen (WASM)FEA mesh from BRepBrowser
Constraint graphGraFOSaDependency tracking, blast radiusServer
Material DBMatWeb API + local cacheMaterial propertiesHybrid
Standards DBInternal + API hooksRegulatory requirementsServer
Agent runtimeClaude API (Anthropic)Domain agentsServer
Drawing generatorOpenCascade (HLR algo)2D from 3D projectionServer
STEP exporterOpenCascadeISO 10303 exportBrowser

11.2 WASM Modules

Heavy computation runs as WASM in the browser for responsiveness:

┌──────────────────────────────────────────┐
│            Browser (WASM sandbox)         │
│                                           │
│  ┌────────────┐  ┌───────────────────┐   │
│  │ Rapier.rs  │  │ OpenCascade.js    │   │
│  │ (2.3 MB)   │  │ (15 MB, lazy-load)│   │
│  │ rigid body │  │ BRep geometry     │   │
│  │ 60Hz step  │  │ on-demand rebuild │   │
│  └────────────┘  └───────────────────┘   │
│                                           │
│  ┌────────────┐  ┌───────────────────┐   │
│  │ TetGen     │  │ SIMP Optimizer    │   │
│  │ (0.8 MB)   │  │ (custom, 0.5 MB)  │   │
│  │ mesh gen   │  │ topology opt      │   │
│  │ on-demand  │  │ iterative, visual │   │
│  └────────────┘  └───────────────────┘   │
│                                           │
│  ┌────────────────────────────────────┐  │
│  │ CalculiX (WASM) — 4 MB            │  │
│  │ Linear static FEA, small models    │  │
│  │ Falls back to cloud for >50k DOF   │  │
│  └────────────────────────────────────┘  │
└──────────────────────────────────────────┘

11.3 Cloud Fallback

For models exceeding browser WASM limits:

Browser WASM                        Cloud (Kubernetes)
═══════════════                     ═══════════════════
< 50,000 DOF FEA                   > 50,000 DOF FEA
< 10 parts assembly                > 10 parts assembly
Simplified CFD (panel method)       Full Navier-Stokes CFD
Real-time preview fidelity          Production-grade fidelity
16ms physics budget (60fps)         Minutes-scale solver runs

Handoff: Browser sends geometry + BCs → Cloud solves → Results stream back
via SSE (same pattern as conduir-spatial agent responses)

12. Integration with Conduir-Spatial

12.1 Scene Node Extensions

// Extended node types (add to existing NodeType union)
type ForgeNodeType =
  | "part"           // 3D parametric geometry
  | "assembly"       // Group of parts with interfaces
  | "feature"        // Geometric feature (hole, boss, pocket)
  | "constraint"     // Physics/dimensional constraint (visible)
  | "material"       // Material definition
  | "load-case"      // External load definition
  | "validation"     // Validation result
  | "tolerance"      // GD&T annotation in 3D
  | "measurement"    // Dimensional measurement
  // Plus existing: concept, task, agent, person, artifact, decision, group, annotation

12.2 New Overlay Renderers

// New Three.js components for the Product Forge

<StressOverlay geometry={mesh} results={feaResults} />
// Vertex-colored mesh showing Von Mises / principal stresses

<ThermalOverlay geometry={mesh} results={thermalResults} />
// Vertex-colored mesh showing temperature field

<DisplacementOverlay geometry={mesh} results={feaResults} scale={10} />
// Deformed wireframe (exaggerated)

<StreamlineRenderer domain={cfdDomain} results={cfdResults} />
// Animated particles along flow paths

<ForceArrows loads={loadCases} scale={0.001} />
// 3D arrows showing applied forces and reactions

<ConstraintField constraints={activeConstraints} />
// Translucent boundary surfaces showing constraint envelopes

<ToleranceAnnotation feature={feature} tolerance={gdtSpec} />
// 3D GD&T callouts (leader line + frame + value)

<SectionPlane position={pos} normal={dir} model={geometry} />
// Interactive cutting plane with cross-section display

<ExplodedView assembly={assembly} factor={explodeFactor} />
// Animated exploded assembly view along assembly axis

12.3 Store Extensions

// Extends spatialStore for product forge

interface ForgeState extends SpatialState {
  // Product state
  product: ProductAssembly | null
  materials: Record<MaterialId, MaterialDefinition>
  loadCases: Record<string, LoadCase>

  // Physics runtime
  physicsMode: "realtime" | "on-demand" | "paused"
  activeOverlay: "none" | "stress" | "displacement" | "thermal" | "flow" | "safety" | "cost"
  feaResults: Record<string, FEAResult>
  thermalResults: Record<string, ThermalResult>
  cfdResults: Record<string, CFDResult>

  // Constraint graph connection
  constraintGraph: GraFOSAConnection  // WebSocket to GraFOSa MCP

  // Validation gates
  gates: Record<string, ValidationGate>

  // Agent states
  agents: Record<string, ForgeAgent>

  // Actions
  updateParameter: (partId: string, paramId: string, value: number) => void
  runValidation: (gateId: string) => Promise<ValidationResult>
  extractSpec: () => Promise<SpecBundle>
}

12.4 SSE Events (Product Forge additions)

SSE EventPayloadScene Mutation
constraint_field_updateUpdated constraint boundariesConstraint envelope surfaces reshape
topology_iterationVoxel density fieldGeometry morphs (topology optimization step)
fea_progressSolver iteration countProgress bar on validation gate
fea_resultStress/displacement fieldOverlay paints onto geometry
thermal_resultTemperature fieldThermal overlay updates
cfd_resultVelocity/pressure fieldStreamlines appear
dfm_warningFeature + issue descriptionAmber highlight on feature
cost_updateUpdated cost breakdownHUD cost counter changes
gate_resultPASS/FAIL/CONDITIONALGate opens/locks/warns
material_selectedMaterial propertiesConstraint field updates, geometry material changes
parameter_propagatedChain of affected paramsConstraint edges glow in sequence
spec_artifactArtifact type + data URLCard materializes on Extract platform

13. Implementation Phases

Phase F0: Foundation (Weeks 1-3)

TaskDescription
OpenCascade.js integrationLoad OCCT WASM, basic BRep operations (box, cylinder, boolean)
Parametric geometry nodeForgeNode with parameters, geometry rebuild on param change
Rapier.js integrationRigid body physics, collision detection for assembly preview
Material databaseLocal JSON material library (50 common engineering materials)
Constraint visualizationTranslucent boundary surfaces from constraint definitions

Phase F1: Physics Runtime (Weeks 4-6)

TaskDescription
TetGen meshingGeometry → FEA-ready mesh (tetrahedral)
CalculiX WASMLinear static FEA in browser (<50k DOF)
Stress overlay rendererVon Mises color map on geometry mesh
Load case managerDefine/apply forces, pressures, constraints
Real-time parameter → stress feedbackChange dimension → see stress update in <2s

Phase F2: Generative Design (Weeks 7-9)

TaskDescription
SIMP topology optimizerDensity-based topology optimization (WASM)
Voxel → mesh conversionMarching cubes on optimized density field
Live optimization visualizationWatch material redistribute during optimization
Constraint-bounded optimizationOptimizer respects manufacturing + material constraints
Agent: Topology AgentLLM-backed agent that drives optimization parameters

Phase F3: Validation Pipeline (Weeks 10-12)

TaskDescription
Validation gate systemHard/soft gates with auto-PASS/FAIL from solver results
Multi-physics orchestratorRun structural + thermal + CFD in parallel
Cloud solver fallbackShip large models to cloud CalculiX/OpenFOAM, stream results back
Agent: Structural Validation AgentReviews FEA results, issues verdict
Agent: Compliance AgentChecks against standards database

Phase F4: Spec Extraction (Weeks 13-14)

TaskDescription
STEP exportFull assembly export via OpenCascade
BOM generationTraverse assembly graph via GraFOSa
Drawing generator2D projection + GD&T from 3D model
Assembly sequenceTopological sort of mate relationships
Test planGenerated from validation results + standards

Phase F5: Domain Expansion (Weeks 15+)

TaskDescription
Electronics domainSchematic + PCB + enclosure agents
Thermal domainElmer WASM or cloud solver
CFD domainPanel method (browser) + OpenFOAM (cloud)
Multi-domain couplingThermal-structural, electro-thermal
Manufacturing process planningCNC, injection molding, 3D printing paths

14. Key Architectural Decisions

D1: Physics in Browser (WASM) vs Cloud

Decision: Browser-first with cloud fallback.

Rationale: The core value proposition is seeing physics in real-time.
A 2-second round-trip to cloud destroys the "always-on physics" experience.
WASM gives us <16ms for simplified FEA on small models. Cloud is the
fallback for production-grade analysis at validation gates.

D2: Geometry Kernel Choice

Decision: OpenCascade via opencascade.js (WASM build).

Rationale: Only mature open-source BRep kernel with STEP I/O.
15MB WASM bundle is acceptable with lazy loading. Alternative (Manifold)
lacks STEP support. Commercial (Parasolid) is not embeddable in browser.

D3: Constraint Graph = GraFOSa (not a separate system)

Decision: Extend GraFOSa with product-specific node/edge types.

Rationale: GraFOSa already has blast_radius, validate_changes,
trace_path, bottlenecks, cycles — exactly what constraint propagation
needs. Adding Material/Part/Constraint node types is trivial.
The intel dashboard (L7) maps directly to product health.

D4: Agents Use Constraint Graph, Not Direct Messaging

Decision: Agents communicate via graph mutations, not agent-to-agent messages.

Rationale: The constraint graph IS the shared state. When Topology Agent
modifies geometry, Manufacturing Agent learns about it through the graph
mutation event, not a direct message. This prevents agent coordination
complexity and ensures all agents work from the same truth.

D5: Hard Gates Cannot Be Overridden

Decision: Physics-backed hard gates (structural, thermal) auto-lock
and cannot be human-overridden.

Rationale: The entire point of the forge is that the product MUST
satisfy physics. If a human can click "override" on a structural failure,
we've recreated the document-first world where specs are aspirational.
Soft gates (cost, weight budget) allow justified overrides.

D6: Spec is Always Extractable

Decision: At any point during development, a partial spec can be extracted.

Rationale: Unlike traditional workflows where the spec is written
at the end, the forge always has a current state that can be serialized.
Early specs are incomplete (missing tolerances, partial BOM) but the
extraction pipeline always works. This enables early procurement,
early supplier engagement, and progressive specification.


15. Success Criteria

Functional

Performance

Quality

Continue exploring