Enforce granular realization constraints through planning and runtime validation

[Brad-Edwards]

Corrective design intent — 2026-09-05

This issue deliberately corrects a tendency against RAE's design intent: backend recipes and captured specimens becoming compulsory author detail, core catalogs or unconditional evidence obligations. Open scopes delegate unspecified descendants; explicit constraints remain binding. Abstract models can be complete. Actual backend choices are reportable at requested depth; experimental observation, retention and export are independent. See the governing examples and rules.

Purpose

Parsing a nested designation does not ensure its constraints survive compilation, planning, disclosure and result comparison. The same admitted constraint relation must govern each boundary; aggregate open/exact decisions and normalized full-object equality are insufficient.

Runtime backend-result integrity characterized by #158/#1150 belongs to the same admission boundary. Plan-authorized membership and identity, runtime-domain ownership, and snapshot-transition accounting must be enforced before backend results replace accepted state.

Parent: #1198. Program: Progressive Specification & Language Extensibility. Work package L5; findings F2, F3, F6. Baseline: 384e8b19 (2026-09-04).

Design review and research basis: #1201. Reproducer: #1200. Runtime-result characterization: #158/#1150.

Scope

Carry the admitted leaf and structure constraints through planning, authenticated
handoff, realization disclosure and comparison. Unknown capabilities do not
authorize execution; open siblings do not weaken exact siblings. Evaluate
actual declared values and coverage under the same constraint relation as
authoring. Negative cases must fail before mutation when knowable at admission,
and reject non-conforming results before replacing accepted state. Extend
existing SEM-218/219 contracts and retain honestly selected evidence-strength
requirements. Resolve delegated choices in the backend rather than demanding
author values where a supported completion exists. Distinguish chosen-witness
admission from full-envelope coverage claims, with explicit migration for any
changed gate. L13 determines requested observations; #1112 admits those actual
requirements. Exact scenario detail alone must not invent capture obligations.

Complete ASR-532 runtime backend-result admission using the #158/#1150
characterization. Apply resolved structural and collection authority when
deciding whether an additional portable resource is permitted; absence from
plan.operations alone is not universal proof of prohibition. Preserve
plan-owned resource identity and runtime-domain ownership. Require honest
snapshot-transition and changed-address accounting across CREATE, UPDATE,
DELETE and UNCHANGED operations. A rejected successful claim must retain the
trusted predecessor snapshot and identify the violated invariant with a
structured diagnostic. This issue supersedes the implementation proposed by
PR #1158.

Acceptance criteria

• Compiler and authenticated plan/handoff retain leaf domains, structural closure, defaults and author provenance without broadening exact siblings.

• Admission checks backend semantic/capability support; unsupported requirements fail before mutation when knowable there.

• Runtime comparison evaluates the declared values and collection coverage, rejects non-conforming results before replacing accepted state, and retains evidence-strength requirements.

• Core and extension fields use the same relation; SEM-218/219 authority and the L1 correction remain effective.

• Integration tests trace nested positive/negative constraints through parser, compiler, plan, handoff, observation projection and accepted state.

• A backend that can provide one allowed completion can resolve a delegated request without claiming support for every possible Linux distribution/version; distinguish this from universal conformance using explicit contract/version changes.

• Do not return backend-resolvable open choices as mandatory author input. Preserve exact descendants and genuinely required control/execution inputs.

• Apply Separate scoped observation and reporting demand from realization detail #1212 demand policy and runtime: reject backends whose capture manifests do not satisfy scenario requirements #1112 required-capture admission: exact environment detail must not automatically create experimental capture, retention or export obligations.

• Known backend selections may be reported as choices when requested; independent corroboration and augmentation disclosures remain required only under their actual selected/applicable contracts, with honest strength labels.

• Additional portable resources are admitted or rejected according to explicit structural and collection closure; exact authored membership remains binding without treating all backend-internal choices as authored resources.

• A successful backend result cannot rewrite plan-owned resource identity or runtime-domain ownership.

• Changed-address accounting covers actual CREATE, UPDATE, DELETE and UNCHANGED transitions without omissions or false change claims.

• The four admitted Characterize RuntimeManager result integrity at the backend boundary #158 perturbations become passing regression cases that assert the exact diagnostic and preservation of the predecessor snapshot.

Dependencies and ownership

Native GitHub blockers: #1200, #1212, #1112. Earlier dependencies are enforced transitively; the plan's immediate dependency table is the scheduling reference.

Also depends on #1212 (L13 scoped-demand contract/carriage); it precedes integrated enforcement/projection and does not depend on this implementation. Reuse #1112 for actual capture admission.

Depends on #1200 (L1), #1202 (L3), #1203 (L4). Preliminary design discussion may proceed before dependencies close; begin the dependent implementation only after its native blockers are cleared.

ADR-105 is the decision record for the recursive semantics and runtime-admission consequences owned here. This issue owns the amendments and ratification needed for production adoption; #1210 owns the resulting version and migration mechanics. Issue #158 and PR #1150 remain completed characterization only. PR #1158 is superseded and carries no remaining work.

Starting points

• implementations/python/packages/raes_processor/compiler/realization_requirements.py
• implementations/python/packages/raes_processor/semantics/realization_runtime_concern_profiles.py
• implementations/python/packages/raes_processor/semantics/realization_runtime_evaluation.py
• implementations/python/packages/raes_runtime/backend_calls.py
• implementations/python/tests/test_issue_158_runtime_result_integrity.py
• docs/requirements/ASR-532/requirement.md
• ADR-105

No runtime or schema change is delivered by opening this issue. #1198 is the completed audit/planning deliverable and can close when its documentation PR is merged; this issue and milestone 70 retain the implementation and verification work.

Requirements

• ASR-532 — Runtime Backend Result Integrity
• SEM-218 — Explicitness And Realization Semantics
• SEM-219 — Participant Tool And Affordance Semantics

[Brad-Edwards]

🛠️ Picked up by /implement - driver codex, branch 1204-granular-realization-constraints, 2026-09-11T03:41:18.501Z.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1204). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1204). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1204). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.