Declare adversarial-control apparatus and backend capabilities

[Brad-Edwards]

Parent: #812

Bounded outcome

Extend existing participant implementation, experiment apparatus, and API-407 capability surfaces to declare bounded quarantine, trusted/untrusted processing roles, label/derivation support, final-sink mediation, monitor topology, and fail-closed downgrade behavior. Keep apparatus-specific prompt separation, model roles, MCP gateways, and tool scopes outside portable participant semantics.

Negative cases

• Backend or apparatus declarations treated as proof of realization.
• A prompt sanitizer, gateway, model wrapper, or heuristic monitor declared as the sole enforcement point.
• Different model/process ids treated as independence or non-collusion evidence.
• Secrets, prompts, credentials, policies, or hidden objectives embedded in public manifests, argv, environment, logs, or evidence.
• Unsupported label propagation or quarantine silently downgraded to supported.

Evidence required

• Closed capability/manifests and declared-versus-effective support resolution.
• Honest, unsupported, weakened, overclaiming, and colluding/correlated fixtures.
• Backend realization and bounded conformance probes tied to the exact SEM-233 profile.
• Apparatus capability and least-authority/tool-scope evidence.
• Safe provenance and limitation records.

Explicit nonclaims

• No automatic trust in a model, human, monitor, gateway, or backend.
• No runtime realization without implementation and conformance evidence.
• No portable prompt, chain-of-thought, private-state, credential, or LLM-message semantics.

Dependencies

• Blocked by Publish adversarial participant flow-control contracts #1002.
• Parent design: Adopt adversarial AI-agent control and boundary-IFC threat models for participants #812.

Requirements

• SEM-233
• ASR-536
• API-407
• ACT-617

[Brad-Edwards]

🛠️ Picked up by /implement - driver claude-code, branch 1004-adversarial-control-capabilities, 2026-08-02T20:34:03.550Z.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1004). 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 #1004). 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 #1004). 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 #1004). 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: plan (issue #1004). 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.

Implementation plan — declare adversarial-control apparatus & backend capabilities

Scope is declaration only (all four architecture preflights agree). No new runtime engine, policy resolver, manifest block, exception hierarchy, store, or conformance runner. #1003/RUN-319 keeps final-sink enforcement; SEM-233 keeps the portable flow contracts; ASR-536 stays design-authority + evaluation-profile + fixtures. This issue extends the existing API-407 capabilities.participant_runtime.feature_support surface with governed terms and their conformance evidence.

Design: five new governed participant-runtime-behavior-features terms

Each term is added once to the behavior-feature vocabulary and once to PARTICIPANT_RUNTIME_CAPABILITY_REQUIRED_CONTRACTS, mapped to its actual backend-facing, already-published contract (no new entries in BACKEND_SUPPORTED_CONTRACT_IDS — the SEM-233 relation/profile are authoring/SDL ids and must not be smuggled into backend support):

Term	Meaning	Required contract(s) (all already backend-facing)
participant_boundary_flow_resolution	SEM-233 two-coordinate label resolution + conservative provenance-preserving propagation	participant-crossing-occurrence-v1
participant_final_sink_mediation	RUN-319 fail-closed exact-cut permit immediately before an ACES-controlled external effect	participant-crossing-occurrence-v1
participant_quarantined_processing	bounded quarantine of unknown/untrusted source material	participant-crossing-occurrence-v1
participant_processing_role_trust	trusted/untrusted processing-role declaration bound to controller/authority state	participant-control-occurrence-v1, participant-crossing-occurrence-v1
participant_monitor_topology	declared monitor topology (trusted/untrusted/composed) as bounded apparatus evidence	experiment-evidence-record-v1

All five join PARTICIPANT_RUNTIME_EVIDENCE_REQUIRED_FEATURES so a positive claim needs evidence_refs, below-exact needs disclosure_refs + limitation_refs, and bounded needs constraint_refs; the three policy-bearing ones (*_flow_resolution, *_final_sink_mediation, *_quarantined_processing) also join PARTICIPANT_RUNTIME_POLICY_FEATURES so declaring them in supported_behavior_features forces an explicit feature_support entry. Missing/contradictory/evidence-free = unsupported (deny-equivalent). A downgrade is authorized only through the existing resolve_participant_feature_support() / _validate_downgrade_authorization() path and never retains the stronger effective claim. A term is a declaration, not proof of isolation, monitor independence, non-collusion, flow propagation, or sink enforcement — those remain the owning validators' / runtime's job.

Files to change

Authority + vocabulary

• implementations/python/packages/raes_contracts/manifest_authority.py — add the five terms to PARTICIPANT_RUNTIME_CAPABILITY_REQUIRED_CONTRACTS[…behavior_feature_scope], PARTICIPANT_RUNTIME_EVIDENCE_REQUIRED_FEATURES, and (three of them) PARTICIPANT_RUNTIME_POLICY_FEATURES.
• implementations/python/packages/raes_backend_protocols/capabilities.py — keep its mirror PARTICIPANT_RUNTIME_CAPABILITY_REQUIRED_CONTRACTS / evidence-required tuple in sync.
• contracts/concept-authority/controlled-vocabularies-v1.json — add the five governed terms to participant-runtime-behavior-features (+ its valid fixture contracts/fixtures/concept-authority/controlled-vocabularies-v1/valid/reference.json).

Published schema (parity + publication + digest chain)

• contracts/schemas/backend-manifest/backend-manifest-v2.json — add the five terms to the supported_behavior_features enum and the feature enum in the feature_support block (~lines 985/1023/1057/1658).
• Keep schema_bundle() output identical so tools/check_generated_schemas.py passes; update contracts/schema-publication/entries/backend-manifest-v2.json + contracts/schema-publication-manifest.json last_change (summary + content hash) per plan-rules.
• Re-pin any check_identity_cutover digest that covers controlled-vocabularies-v1.json / the schema (operational-binding content_sha256 in historical_identity_records.json) if the policy check flags it.

Conformance evidence (ASR-536 fixture matrix)

• Add honest, unsupported, weakened/downgraded, overclaiming, and colluding/correlated backend-manifest + apparatus fixtures under contracts/fixtures/backend-manifest/backend-manifest-v2/{valid,invalid}/ and the participant-runtime fixtures dir, each binding the exact sem-233/rev1 profile revision/digest, declared-vs-effective level, safe evidence, constraints, limitations, and nonclaims. No secrets/prompts/policy bodies in any fixture, argv, env, or evidence.
• Extend the control_evaluation_profile monitor-topology / trusted-untrusted declaration in docs/research/adversarial-participant-control/implementation-program.json to reference the new governed terms (ASR-536 design authority).

Specs / docs

• specs/formal/runtime-contracts/participant-backend-contracts.md — document the five feature terms, their contract mappings, evidence rules, and the declaration≠realization boundary.
• specs/formal/participant-semantics/adversarial-flow-control.md — note the apparatus/backend declaration surface for SEM-233/ASR-536 (cross-reference, not a fork of the semantics).
• Update assurance-fulfillment.yaml entry if the coverage row needs it. Preflight doc docs/decisions/issue-1004-adversarial-control-apparatus-backend-preflight.md already added (guidance only).

Tests (TDD — write first, watch fail, implement)

• implementations/python/tests/test_controlled_vocabularies.py — assert the five new governed terms + extension-pattern parity.
• implementations/python/tests/test_backend_manifest.py — positive claim requires evidence; below-exact requires disclosure(+limitation); bounded requires constraints; unsupported cannot co-appear with the feature in supported_behavior_features; declared-but-absent-from-supported rejected; downgrade authorization; each term's required-contract gate against supported_contract_versions.
• New implementations/python/tests/test_issue_1004_apparatus_backend_capabilities.py — end-to-end declared-vs-effective resolution over the honest/unsupported/weakened/overclaiming/colluding fixtures via resolve_participant_feature_support() + run_target_conformance(); assert overclaiming and collusion fixtures resolve deny-equivalent and never widen access; assert monitor/role declarations do not imply independence/non-collusion.
• Backend-manifest schema-fixture roundtrip / publication parity tests already exercised by the suite.

Security / maintainability / extensibility / whole-repo

• Security: every below-exact posture carries disclosure+limitation; positive claims carry evidence; contradictions and evidence-free claims fail closed (deny-equivalent) at ParticipantFeatureSupportModel + _validate_supported_feature_levels() + resolve_participant_feature_support(). Manifest ingress stays on the existing 1 MiB UTF-8 + closed-model path; fixtures/evidence carry only safe ids/digests/refs/counts — no prompts, credentials, policy bodies, thresholds, or hidden objectives (redacted Diagnostic/error envelopes reused).
• Maintainability: reuse ParticipantFeatureSupport(Model), resolve_participant_feature_support(), participant_feature_support_gaps(), BackendManifestV2Model round-trip, controlled-vocabulary catalog, run_target_conformance() / BackendConformanceReport — no parallel lattice, resolver, or taxonomy.
• Extensibility: the one seam is a governed feature entry parameterized by profile/contract revision, strength, constraints, limitations, disclosures, evidence. Future backend/monitor/quarantine mechanisms add a governed term or apparatus binding — never a backend-name branch, trusted scalar, or open metadata bag.
• Whole-repo: touches concept-authority vocab, published schema + generator parity + publication ledger + identity-cutover digest chain, backend-protocol mirror constant, conformance harness, formal specs. All exercised by make policy + verify-completion.

Traceability / governance

• Changed packages/*.py (manifest_authority.py, capabilities.py) are already IMPLEMENTS-linked to API-407 (ACTIVE); add IMPLEMENTS/DOCUMENTS/TESTS links for the new schema/vocab/spec/fixture/test artifacts to the relevant in-scope requirement (SEM-233, API-407, ACT-617 ACTIVE now; ASR-536 gets TESTS+DOCUMENTS which are valid on DRAFT). Transition ASR-536 DRAFT→ACTIVE in Phase E (Step 15) once its fixture/profile evidence lands.
• No CHANGELOG.md / version edits (release-please owns them). PR title will be feat(runtime): declare adversarial-control apparatus and backend capabilities (API-407) — valid Conventional Commit + title-guard.

Verification (before completion)

check_repo_policy.py, check_requirement_governance.py, verify_all.py, check_generated_schemas.py, and the full nox -s verify / make policy on the final tree, with RAES_REQUIREMENT_UID set (branch carries no UID).

[Brad-Edwards]

gc_codex_review — cycle 1 of 1 (pre-push) on issue #1004 (branch 1004-adversarial-control-capabilities)
Diff mode: inline — the complete diff was supplied in one prompt

Core review

Verdict: ship-with-fixes

The change correctly extends the existing API-407 feature-support seam rather than introducing a parallel apparatus manifest or resolver, and its unsupported stub coverage preserves the closed default. However, the required-contract map is the design boundary for positive claims, and the new mappings reduce distinct SEM-233 and RUN-319 realization claims to generic crossing-occurrence support. That forecloses the intended evidence binding: an exact declaration can resolve without the owning profile or runtime contract being supported.

Blocking findings (1):

1. [class] Bind each new capability to its owning contract surface — implementations/python/packages/raes_contracts/manifest_authority.py:205
   These mappings allow positive exact support to resolve using only generic occurrence/evidence contracts. In particular, boundary-flow resolution does not require the SEM-233 profile/relation surface, and final-sink mediation does not require the RUN-319 realization surface, despite both the feature descriptions and the preflight defining those as the owning semantics. A manifest that supports participant-crossing-occurrence-v1 can therefore make an effective exact final-sink or flow-resolution claim without supporting the contract that defines that realization. Add the genuinely backend-facing owning contract/profile IDs to the supported-contract allowlist and required-contract mappings, then update the fixture/tests to require them for positive claims.

Security review

Verdict: ship

This is a declaration-surface extension: it adds five closed, evidence-required participant-runtime feature terms to the existing manifest vocabulary and resolver discipline, while explicitly preserving the separate runtime final-sink enforcement boundary. The change touches contract publication, schema validation, fixture coverage, and required-contract mappings, but introduces no request handler, effect path, credential handling, dynamic execution, or authorization route. The design seam remains the existing feature_support mechanism and does not create a new path by which an untrusted manifest can itself authorize an external effect.

No blocking findings.

[Brad-Edwards]

gc_codex_review pre-push cycle 1 of 1 complete for issue #1004 on branch '1004-adversarial-control-capabilities'. Posted by the MCP server to enforce the pre-push hard-cap-1 contract (issues #796, #804, #906). Do not edit or delete — used by the next gc_codex_review (uncommitted) invocation to count cycles.