Module support 

Canonical implementation inventory for external coding harnesses.

This registry describes wiring that exists in the compiled core. It does not claim that a harness has passed a real executable smoke test; the autonomy audit joins this inventory with behavioral probe receipts and tracker state before it calls anything verified.

Structs

ConceptSupport

One orchestration concept’s tiers for one harness (ORCH-4).

HarnessSupportDescriptor

NativeSupport

Persisted-session and translation implementation facts.

OrchestrationSupport

Per-concept observed / controlled tiers for one harness (additive to the v1 registry schema, like connect_launch).

RuntimeSupport

Live runtime wiring known without launching the real executable.

SupportRegistryReport

Machine-readable compiled support inventory.

Enums

ImplementationKind

How a primitive is wired into the compiled core.

Constants

ORCHESTRATION_CONCEPTS

One compiled harness implementation descriptor. The twelve Domain 11 concepts, in plan order (docs/plans/orchestration-domain-11-2026-09-02.md).

SUPPORT_REGISTRY_SCHEMA

Schema emitted by harness_support_registry.

Functions

harness_support

Look up one harness in the compiled registry.

harness_support_registry

orchestration_support

Return the single compiled inventory used by product surfaces and audits. Derive a harness’s orchestration tiers from what the registry already proves: a harness whose sessions load natively is observed for the conversation concept (sessions.discover/load), and a runtime door that answers protocol requests is controlled for pending requests (runtimes.respond). Every other cell is Absent until its ORCH item lands and adds its method here.