Adapter Model

Overview

An adapter in Forge is a bounded execution unit that transforms input state into output state under a defined contract.

It exists at the boundary between external systems and the Forge execution layer.

Adapters are not compute engines.
They are state transformers and execution orchestrators.

---

Core Definition

An adapter can be described as:

Adapter: (Input State) → (Execution Plan?) → (Output State)

Where:

• Input State is any external or upstream data
• Execution Plan is an optional orchestration of Forge primitives
• Output State is a transformed, domain-specific result

---

State Transformation

At its core, every adapter performs:

S_out = A(S_in)

Where:

• S_in is the input state
• A is the adapter logic
• S_out is the output state

This transformation may include:

• Validation
• Normalization
• Enrichment
• Routing
• Aggregation
• Formatting

---

Execution Composition

Some adapters introduce an intermediate step:

S_in → Plan → Execution → S_out

Execution Plan

An execution plan defines:

• Which primitives are called
• In what order
• With what parameters
• How results are combined

Adapters do not execute compute directly.
They delegate execution to primitives.

---

Adapter as Function vs Pipeline

Adapters can operate in two modes:

1. Functional Adapter

A single-step transformation:

S_out = A(S_in)

Used for:

• Data ingestion
• Validation
• Output formatting

---

2. Pipeline Adapter

A multi-stage transformation:

S_in → A₁ → A₂ → ... → Aₙ → S_out

Where stages may include:

• Primitive execution
• Intermediate transformations
• Aggregations

---

Determinism Model

Adapters are not required to be strictly deterministic.

However:

• Any interaction with Forge primitives must preserve reproducibility
• Randomness must be controlled (e.g. seeded)
• Execution paths must remain traceable

---

Boundary Definition

Adapters define a clear boundary between:

Domain	Responsibility
External Systems	Input/output formats
Adapter Layer	Transformation & orchestration
Forge Primitives	Computation
Execution Layer	Distributed processing

Adapters must not blur these boundaries.

---

Compute Delegation

Adapters may:

• Trigger primitive execution
• Chain multiple primitives
• Combine outputs

Adapters must not:

• Reimplement primitive logic
• Execute hidden compute while presenting it as Forge execution

---

Execution Participation

Adapters fall into two categories:

Compute-Participating Adapters

• Call Forge primitives
• Orchestrate execution flows
• Produce results derived from distributed compute

---

Non-Compute Adapters

• Do not call primitives
• Perform shaping, validation, or formatting
• Serve as integration boundaries

Both are valid.

---

Input and Output Contracts

Adapters define:

Input Contract

• Expected schema
• Validation rules
• Optional defaults

---

Output Contract

• Structured result format
• Domain-specific representation
• Metadata (optional)

---

Error Model

Adapters must handle:

• Invalid input
• Execution failure (if primitives are used)
• Partial results
• External system errors

They must not:

• Hide execution failures
• Alter primitive error semantics

---

Composition Model

Adapters can be composed:

A₁ → A₂ → A₃

This enables:

• Modular pipelines
• Domain-specific workflows
• Reusable execution patterns

---

Mental Model

An adapter is:

• A translator between worlds
• A planner of execution
• A transformer of state

It is not:

• A compute engine
• A primitive replacement
• A hidden execution layer

---

Key Insight

Adapters define how computation is requested and consumed,
not how computation is performed.

---

Next

• Lifecycle
• Types
• Invariants
• Build