Appearance
Adapter Invariants
Overview
Adapters are flexible by design.
But they are not unconstrained.
There are a small number of rules that every adapter must follow.
These are not recommendations.
They are invariants.
If an adapter violates any of these, it is no longer Forge-compatible.
Why Invariants Exist
Forge separates:
- execution (truth)
- orchestration (control)
- integration (adaptation)
Adapters operate at the boundary.
Without strict invariants, that boundary collapses.
The result would be:
- inconsistent outputs
- non-replayable execution
- broken trust
Invariants exist to prevent this.
Invariant 1 — Compute Truth Is External
Adapters must not implement canonical compute.
All probabilistic or deterministic execution that defines result truth must be performed through Forge primitives.
Adapters may:
- prepare inputs
- orchestrate execution
- combine outputs
They must not:
- replicate primitive logic
- approximate primitive behavior
- substitute local compute for canonical execution
If compute truth is defined inside the adapter, the adapter is invalid.
Invariant 2 — No Semantic Override
Adapters must not change the meaning of primitive outputs.
They may:
- format results
- aggregate results
- filter results
They must not:
- reinterpret values
- relabel meaning
- distort statistical interpretation
- alter probabilistic semantics
Output shaping is allowed.
Semantic rewriting is not.
Invariant 3 — Explicit Execution Boundary
Every adapter must make it clear whether it:
- participates in Forge execution
- or operates purely as a transformation layer
There must be no ambiguity.
If an adapter calls primitives, that must be visible in its behavior and structure.
If it does not, it must not imply that it does.
Invariant 4 — Traceability Must Be Preserved
If an adapter participates in execution, it must preserve traceability.
At minimum, this includes:
- primitive identifiers
- execution references
- input parameters
- adapter version
- execution context
Without this, results cannot be:
- verified
- replayed
- audited
Traceability is not optional.
Invariant 5 — No Hidden State That Affects Truth
Adapters must not rely on hidden or implicit state that changes execution outcomes.
All inputs that influence results must be:
- explicit
- observable
- reproducible
Invalid patterns include:
- hidden configuration affecting execution
- implicit defaults that change results silently
- environment-dependent behavior without disclosure
Execution must be explainable.
Invariant 6 — Determinism Claims Must Be Honest
If an adapter claims that a result is reproducible, it must ensure:
- identical inputs
- identical execution requests
- preserved seeds (if applicable)
- stable execution context
Adapters must not:
- claim determinism when randomness is uncontrolled
- omit parameters required for replay
- hide sources of variance
Reproducibility must be real, not implied.
Invariant 7 — No Boundary Collapse
Adapters must maintain clear internal boundaries.
Even if implementation is flexible, the following roles must remain conceptually distinct:
- validation
- transformation
- execution orchestration
- output shaping
An adapter may implement these however it wants.
But if these roles become indistinguishable, the adapter becomes:
- untestable
- untraceable
- unreliable
Clarity of flow is required.
Invariant 8 — Output Must Reflect Reality
Adapters must not produce outputs that misrepresent what occurred.
This includes:
- claiming execution when none happened
- hiding failed execution
- presenting partial results as complete
- masking uncertainty
The output must reflect:
- what was executed
- what was not
- what is known
- what is uncertain
Trust depends on this.
Invariant 9 — No Implicit Primitive Substitution
Adapters must not silently switch primitives, profiles, or execution strategies.
Any change in:
- primitive selection
- execution profile
- policy
- parameters
must be:
- explicit
- visible
- traceable
Silent substitution breaks reproducibility.
Invariant 10 — Compatibility Over Convenience
Adapters must prioritize system compatibility over local convenience.
This means:
- adhering to canonical execution patterns
- preserving traceability even when costly
- avoiding shortcuts that break invariants
A simpler adapter that breaks invariants is worse than a complex one that preserves them.
Practical Interpretation
A valid adapter:
- uses primitives for compute truth
- clearly defines its execution role
- preserves all inputs required for replay
- does not distort results
- produces outputs that reflect actual execution
An invalid adapter:
- hides compute
- changes meaning
- loses traceability
- misrepresents results
Enforcement Philosophy
Forge does not enforce invariants through strict framework constraints.
Instead, it relies on:
- explicit documentation
- clear mental models
- ecosystem discipline
This allows flexibility while preserving integrity.
Summary
Adapters are free to evolve.
But they must always respect:
- where truth lives
- how execution is defined
- how results are represented
These invariants ensure that:
- the system remains coherent
- results remain trustworthy
- execution remains replayable
Without them, Forge cannot function as a unified system.