[sinkog]

What

Documentation only: no module code, no WASM change, no Relay code. D5 asked where host, base_path, key_id, resource_id and revision should come from; its premise (the project owner's statement of the CIC model) is that they belong to the realization context, the provider contract and the observed state. This surveys what is written and what is in code about that context, marks each item implemented, scaffold, concept or not read, and proposes a contract (concept).

• docs/design/specs/realization-context.md (new): section 2 what exists, section 3 where the chain breaks, section 4 a proposal, section 5 open questions.
• docs/design/README.md: an index entry.

The cic-graph knowledge base (a 2026-10-16 snapshot) was used for orientation only; every claim in the document was re-read from a live file and is cited by file.

Found

• Exists: the logical identity (CIC uid) and its separation from the provider identity (provider_id), with correlation by uid and never by provider_id; the state object's binding, revision and provenance; the host-side comparison and conformance code in the Relay (core/nexus/iac, implemented, imported by the drift check and the IaC loader, not by the cabinet or the cic-flow execution path); the recorded decision "plan, then execute the exact signed plan, the module does not attest its own work"; the OIS seam (implemented, not on the module's execution path); the signing identity and the module's self-declared egress in its signed manifest.
• Does not exist: the realization context itself. No document in this repository defines it, and the Relay's cmd, core and pkg at 55a899f have no Go type for a realization, deployment context, environment or binding (searched by type name). In the state-model spec's example the state object's binding carries only provider and provider_id. The five target values reach the module as free request fields (measured in docs: what destroy and invoke do today, and a binding contract proposal #46 and docs: D5, what the module does with a caller-given host and base_path, and where target data should come from #47), and the registry records no API version, base path or host.
• The bridge: the model exists, but the implementation bridge breaks at the realization context, between the expanded intent object and the execution target.

Proposed (concept)

A versioned, authenticated realization context per logical object and provider (object, provider, environment, provider_contract digest, execution_identity as a handle never key material, binding, observation, issuer, policy decision, validity); each target field derived from it (host from environment and the provider contract's host rule, base_path from the registry's API version, key_id from the identity binding the Relay resolves, resource_id from the uid correlation, revision from the observation); a realization digest that makes target_digest a function of the context inside the chain that execution_digest commits to; the context reaching an execution through the authenticated execution context (R6), not the request body. OIS is separate: an approval of a consequence is not an identification of its target. Until such a context exists the module's target input stays what the M4a gate proves consistent: a caller-supplied value.

Not read in this pass (stated in the document)

The Forms engine and its docs (cic-primitive-forms, cic-primitive-engine), the schema registry, primitives, CIC-basic-knowledge and the OIS repository. The state commit model is cited from the knowledge base only. Statements about these are second-hand and marked. The Relay facts are from 55a899f, read, not run.

Open questions for the owner (the sources cannot decide them)

Where a context is authored and stored; granularity (per environment or per object); who issues and signs it; the provider contract's record of the host rule and API version (D5-1); routing and decomposition across providers and regions; lifecycle (rotation, revocation, an approved but unexecuted plan whose context changes); and where in the Forms steps "defaults with origin" and "policy resolution" a context-derived value would enter.

Not in this PR

No implementation, no registry or extractor change, no WASM rebuild or signature, no Relay change, no production-integration claim. A signed observation is evidence of what was read, not proof of the physical state. No merge without explicit owner GO.

🤖 Generated with Claude Code