Forge Pool

Appearance

Adapter Types ​

Overview ​

Forge does not require one adapter shape.

Adapters are categorized by responsibility, not by implementation style.

This matters because adapters may look very different in code while still playing a clear role in the system.

The same adapter may contain multiple internal steps, but it should remain legible in terms of its primary responsibility.

Canonical Adapter Categories ​

Forge adapters typically fall into one of the following categories:

  1. Ingest adapters
  2. Execution adapters
  3. Aggregation adapters
  4. Output adapters
  5. Bridge adapters

These categories are not rigid class hierarchies.

They are responsibility models.

1. Ingest Adapters ​

Ingest adapters receive external or domain-facing input and normalize it into a canonical internal structure.

They are typically the first boundary between an outside system and Forge.

Responsibilities ​

  • accept external payloads
  • validate schema and required fields
  • normalize source-specific formats
  • reshape data into canonical internal representation
  • attach coverage, warnings, or structural metadata

Typical Lifecycle ​

text
Input → Validate → Transform → Output

Characteristics ​

  • usually do not call primitives
  • usually do not perform distributed compute
  • often produce normalized envelopes for downstream adapters

Examples ​

Typical examples include:

  • portfolio ingest
  • telemetry ingest
  • structured CSV / JSON normalization
  • sensor payload normalization

Canonical Role ​

Ingest adapters turn messy external state into clean Forge-ready state.

They do not define compute truth.

2. Execution Adapters ​

Execution adapters orchestrate one or more primitive calls.

They are the most visible adapter type because they translate domain intent into canonical execution requests.

Responsibilities ​

  • receive normalized or semi-normalized input
  • map domain intent to primitive selection
  • build canonical execution requests
  • dispatch workloads through Forge execution surfaces
  • collect primitive outputs

Typical Lifecycle ​

text
Input → Validate → Transform → Plan → Execute → Finalize → Output

Characteristics ​

  • primitive-aware
  • profile-aware
  • orchestration-heavy
  • may run single-stage or multi-stage execution flows

Examples ​

Typical examples include:

  • ETA execution
  • risk execution
  • QR recovery orchestration
  • climate ensemble execution

Canonical Role ​

Execution adapters are the most direct domain-to-kernel boundary.

They do not compute directly. They request computation from primitives.

3. Aggregation Adapters ​

Aggregation adapters combine multiple outputs into a higher-level result surface.

They are used when one primitive result is not enough, or when a domain requires consensus, fusion, or summary construction.

Responsibilities ​

  • receive multiple execution results
  • combine outputs across stages or runs
  • build summary surfaces
  • compute higher-order views
  • preserve replay and lineage references

Typical Lifecycle ​

text
Input → Validate → Transform → Execute? → Aggregate → Finalize → Output

Some aggregation adapters call additional primitives. Others only combine already-computed outputs.

Characteristics ​

  • fusion-oriented
  • summary-oriented
  • often used in multi-stage domain chains
  • may expose confidence or disagreement structures

Examples ​

Typical examples include:

  • risk aggregation
  • ensemble fusion
  • multi-run consensus shaping
  • scenario consolidation

Canonical Role ​

Aggregation adapters combine execution truth. They must not silently invent it.

4. Output Adapters ​

Output adapters transform structured results into delivery-ready surfaces.

They usually sit near the end of a chain.

Responsibilities ​

  • shape results for presentation or delivery
  • prepare report-ready structures
  • generate export-safe bundles
  • preserve references to upstream execution artifacts
  • expose outputs for humans or downstream systems

Typical Lifecycle ​

text
Input → Transform → Finalize → Output

Characteristics ​

  • presentation-oriented
  • no canonical compute
  • downstream-facing
  • often audience-specific

Examples ​

Typical examples include:

  • executive report shaping
  • analyst export bundles
  • API delivery surfaces
  • UI-ready response builders

Canonical Role ​

Output adapters package execution results. They do not redefine them.

5. Bridge Adapters ​

Bridge adapters connect Forge-native outputs or inputs to external ecosystems.

They do not belong to a single domain. They exist to increase system interoperability.

Responsibilities ​

  • convert Forge structures into external tool formats
  • translate external system conventions into Forge-compatible surfaces
  • support handoff into notebooks, files, pipelines, or partner systems
  • preserve execution meaning during translation

Typical Lifecycle ​

text
Input → Transform → Output

or

text
Input → Validate → Transform → Output

Characteristics ​

  • interoperability-focused
  • ecosystem-facing
  • often file-, API-, or tool-oriented
  • usually compute-free

Examples ​

Typical examples include:

  • notebook bridges
  • JSON export bridges
  • file packaging adapters
  • external service connectors

Canonical Role ​

Bridge adapters extend the reach of Forge. They do not extend the kernel.

Mixed Adapters ​

Some adapters combine responsibilities.

For example, a single adapter may:

  • ingest input
  • orchestrate execution
  • aggregate outputs
  • shape final response

This is valid.

The important rule is not that every adapter must be minimal.

The important rule is that the adapter must remain conceptually legible and must not violate execution boundaries.

Type Selection Heuristic ​

When documenting or designing an adapter, ask:

What is its primary job? ​

If the primary job is:

  • normalization → it is mainly an ingest adapter
  • primitive orchestration → it is mainly an execution adapter
  • result fusion → it is mainly an aggregation adapter
  • delivery shaping → it is mainly an output adapter
  • ecosystem translation → it is mainly a bridge adapter

The primary job determines how it should be explained.

What Adapter Types Are Not ​

These types are not:

  • language bindings
  • inheritance classes
  • framework constraints
  • hard runtime categories

They are a way to keep the system understandable as the adapter ecosystem grows.

Why This Classification Matters ​

Without categories, adapters become a flat pile of services.

With categories, the system becomes easier to:

  • explain
  • extend
  • debug
  • govern
  • document

This is especially important because Forge intentionally allows wide freedom at the adapter layer.

Mental Model ​

A primitive answers:

What kind of computation is this?

An adapter type answers:

What role does this boundary play around computation?

That distinction is critical.

Summary ​

Forge adapter types are responsibility models, not implementation cages.

They help keep an open adapter ecosystem legible while preserving a single canonical execution truth underneath.

Next ​