Adapter System

Adapters are not the execution system of Forge.

They are the boundary layer that connects external intent to internal execution.

---

Core Separation

Forge is built on a strict separation:

• Core execution → primitives, profiles, distributed compute
• Adapter layer → input shaping, orchestration, output shaping

This separation is non-negotiable.

---

Where Execution Actually Happens

All canonical execution happens inside Forge core:

Web / API
    ↓
Hub
    ↓
Agents
    ↓
Primitives + Profiles
    ↓
Distributed Execution

Adapters do not execute compute.

They trigger and shape it.

---

Role of Adapters

Adapters exist to:

• accept external input
• normalize and validate it
• map intent to primitive profiles
• trigger execution through the core
• process and return results

They are:

translation + orchestration boundaries

---

Adapter Position in the System

External System / User
        ↓
      Adapter
        ↓
Forge Core (Hub → Agents → Primitives)
        ↓
   Distributed Execution
        ↓
      Adapter
        ↓
External System / User

Adapters sit outside the execution layer.

---

Relationship to Flows

Flows in Forge are not defined by adapters.

Flows are defined by:

• primitive selection
• profile composition
• execution plans inside the core

Adapters may:

• initiate flows
• shape inputs to flows
• coordinate multi-stage execution

But they do not define execution truth.

---

Adapter vs Flow

Concept	Defined By	Responsibility
Flow	Core (primitives + profiles)	Execution logic
Adapter	Edge layer	Input/output + orchestration

---

Adapter Responsibilities

Adapters are responsible for:

• input validation and normalization
• building execution requests
• selecting primitives and profiles
• coordinating execution stages (if needed)
• aggregating results
• shaping output

Adapters are not responsible for:

• compute truth
• execution semantics
• distributed processing
• primitive behavior

---

Interaction with Primitives

Adapters interact with primitives by building canonical execution requests:

Adapter → builds request → Core executes → Adapter receives result

Adapters must:

• explicitly define primitive usage
• preserve execution parameters
• expose replay references

---

Multi-Stage Orchestration

Adapters may coordinate multi-stage execution.

Example:

Adapter
  → mc@1 (portfolio simulation)
  → graph@1 (contagion analysis)
  → aggregation

However:

• each stage is still executed by primitives
• the adapter only coordinates

---

State Handling

Adapters operate on state, but do not define system-wide state propagation.

They:

• receive state
• transform it
• pass it into execution
• reshape results

They do not:

• manage global execution state
• define distributed memory behavior

---

Determinism and Replay

Adapters must preserve:

• execution inputs
• primitive references
• seeds (if applicable)

This ensures:

• reproducibility
• auditability
• verification

Determinism is enforced by the core, not by adapters.

---

System Boundaries

Adapters must maintain a strict boundary between:

Layer	Role
Adapter	translation, orchestration
Core	execution, computation

If this boundary collapses:

• traceability breaks
• execution becomes ambiguous
• system integrity is lost

---

What the Adapter System Is

The adapter system is:

• an interface layer
• an orchestration layer
• a translation layer

It is not:

• an execution engine
• a flow engine
• a compute layer

---

Mental Model

Think of Forge as:

A core execution engine surrounded by adaptable boundaries.

Adapters shape how the world interacts with it.

---

Final Note

Adapters make Forge usable.

The core makes Forge correct.