[sinkog]

What

Documentation only, an addition to docs/design/specs/realization-context.md (merged in #48): the second reading pass on its open question 7, the Forms side. No module code, no WASM change, no Relay code.

What was read

The Forms library README.md, docs/P1-SUPPORTED-SUBSET.md, docs/P5-RESOLVE-MATERIALIZE-RECEIPT.md and the ADR list (cic-primitive-forms at 5531111); the engine's docs/MATERIALIZATION-SPEC.md (the scope note at its top) and docs/RECEIPT-SCHEMA.md (cic-primitive-engine at 93c793a); a text search of both repositories; the top level of the schema registry. Not read: the ADR bodies, the source of the two repositories beyond the text search, the schemas in the registry, primitives, CIC-basic-knowledge, OIS. The document says so.

Found

• The Forms library is a pure library (no Git, network, filesystem policy or execution context). Its defaults are schema-declared; value_origins is authored or default; expand keeps an origin (authored or materialized) and an attestation.
• P5 (Resolve from a supplied snapshot, materialize, receipt) is design with no code, and the engine's documents show no receipt producer anywhere in the ecosystem.
• The engine's scope correction: Parse, Normalize, Resolve and Validate are "permanently the environment's job"; the engine receives a candidate materialized object, checks its Complete property, canonicalizes and digests it.
• The receipt contract is closed (15 required fields); derived_values[] names its inputs as a set of paths of the object.
• A text search of cic-primitive-forms finds no occurrence of realization, deployment context, tenancy, oraclecloud, base_path, key_id or provider_id; in cic-primitive-engine provider_id appears only in the OCI conformance fixtures and plan.rs tests as a state-only field.

Concluded (stated in the document)

A schema default cannot carry a realization value (the rule is schema-default; a host or region in a default would make the schema environment-specific); the library cannot derive it (no execution context); the named seam for facts from outside is Resolve from a supplied snapshot, which is not in code, and proposing a realization context as such a snapshot is a proposal: nothing in the P5 document says it is an accepted kind of snapshot; and the closed receipt cannot name an input that is not a path of the object. Two ways to close that, neither implemented: (i) the context materialized into the object, which requires reconsidering the object's schema and boundary (the object becomes environment-specific); whether the existing receipt contract can represent the derivation without an extension is not verified (if the context is part of the object's schema, a derived_values[].inputs entry could in principle name its paths, so a new receipt field is not shown to be necessary); or (ii) the context outside the object, bound at the execution layer by the realization digest (the receipt contract is not involved and the object stays provider-independent). Section 4 of the document was written for (ii). The engine's word "environment" (the processing layer) and the realization "environment" (a provider account, region and realm) are different things.

Review F1 (commit f2c9c39)

The first version said that putting the context into the object changes the engine's closed receipt contract. The documents read do not show that, so the text now says what is shown: a reconsideration of the schema and the object boundary, with the receipt question left unverified. D5-6 is now stated as not a choice for this repository alone: it touches the object boundary and has to be decided together with the Forms library, engine and Relay contracts.

Decisions this adds (not decided here)

D5-6: the context inside the object or outside it. D5-7: a distinct name for the realization environment. Open question 7 is answered in part: a context-derived value does not enter through defaults or policy resolution.

Not in this PR

No implementation, no engine or registry change, no WASM rebuild or signature, no Relay change, no production-integration claim. Nothing here is verified against the source of the repositories read. No merge without explicit owner GO.

🤖 Generated with Claude Code