Characterize RuntimeManager result integrity at the backend boundary

[Brad-Edwards]

Purpose

Characterize whether RuntimeManager.apply preserves RAE-owned plan, result, and live-state invariants when a backend returns an inconsistent portable result.

RAE owns the published contracts and validation of data admitted into RAE runtime state. Backend implementation correctness, capability certification, infrastructure realization, and operational testing remain the backend implementer or operator's responsibility.

Scope

Use one valid target and manifest, then perturb only the ApplyResult returned through the public runtime boundary. Record the current handling of:

• returning the predecessor snapshot while reporting successful changes;
• adding an unplanned portable snapshot address;
• changing a plan-owned resource type;
• omitting changed-address accounting for a snapshot transition; and
• returning provisioning entries under another runtime domain.

The unplanned-address case is characterization only until the contracts define whether backend-derived portable resources are prohibited or require an explicit namespace and provenance.

Out of scope

• certifying third-party backend implementations;
• proving that backend manifests are truthful beyond RAE-owned schema and internal-consistency checks;
• verifying physical infrastructure or backend-native side effects;
• containing a malicious backend;
• providing a comprehensive backend acceptance suite; and
• changing the public conformance runner.

Acceptance criteria

• Exercise the behavior through RuntimeManager.apply.
• Include an unmodified reference-backend control using the same scenario and target construction.
• Attribute an existing rejection to a specific diagnostic address and message, not only a shared diagnostic code.
• Record admitted inconsistencies as strict expected failures limited to assertion failures so unrelated exceptions remain visible.
• Describe results as runtime-boundary behavior, not backend honesty or conformance certification.
• Leave enforcement changes and contract decisions to separately scoped implementation work.

Architecture boundary

• ADR-004 assigns planning against declared capabilities and structured handling of invalid backend results to the RAE runtime.
• ADR-036 assigns backend invocation and result validation at the execution boundary to raes_runtime.
• ADR-009 keeps published contracts, fixtures, and profiles authoritative while backend implementations remain non-normative.
• ADR-063 keeps the repository-owned reference backend non-normative and separate from conformance authority.

Evidence status

This issue produces bounded runtime-boundary characterization. It does not demonstrate backend implementation correctness, manifest truthfulness, or substrate realization.

[Brad-Edwards]

Prerequisite implementation issue checklist

• Normative machine-readable schemas: publication & verification tooling on the current contracts tree (ASR-501) #65 — Normative machine-readable schemas on the current contracts tree
• Backend conformance suite & fixture corpus: runner/CLI on the current contracts/fixtures tree (ASR-502) #66 — Backend conformance runner/CLI on the current contracts and fixtures tree
• Explicitness & realization semantics: binding declarations vs processor/backend realization (SEM-218) #72 — Explicitness and realization semantics
• ASR-502: Backend Conformance Suite And Fixture Corpus #6 — Backend conformance suite and fixture corpus
• Participant assurance: semantic artifacts, conformance corpus, validation scenario corpus, conformance/support reporting (ASR-506, ASR-507, ASR-508, ASR-526) #82 — Participant assurance conformance/support reporting
• 01: Publish configuration-specific libvirt realization envelopes (ASR-519) #100 — Realization honesty and disclosure conformance
• Time model contracts, conformance & provenance (API-421, ASR-528, EXP-734) #118 — Time model contracts, conformance, and provenance
• Participant episode/reset & budget contracts, runtime accounting & conformance (API-417, API-418, RUN-312, ASR-523, EXP-728) #123 — Participant episode/reset/budget contracts, runtime accounting, and conformance
• Operational apparatus observability; observation-augmentation disclosure contracts; observability-plane/augmentation conformance; evidence-requirement refinement & realized-evidence provenance (RUN-316, API-419, ASR-525, EXP-731, EXP-732) #128 — Observability-plane/augmentation conformance and realized-evidence provenance

[Brad-Edwards]

• undefined #183 — Adversarial backend conformance targets