Add participant activity resource budgets and shared-service fairness contracts

[Brad-Edwards]

Need

Autonomous participant activity can contend with evaluated participants and shared inference infrastructure. Current participant budgets do not fully express or enforce the operational envelope needed across participant, range, and fleet scopes.

Required capability

• Governed rate, concurrency, storage-growth, inference-token, image-generation, and accelerator budgets.
• Participant-, range/tenant-, shared-service-, and fleet-scoped limits with explicit ownership and aggregation.
• Admission against backend/shared-pool capacity and tenant-isolation capabilities.
• Fairness/priority obligations that protect evaluated-participant latency and challenge reliability.
• Runtime measurements, throttling/deviation evidence, reset reconciliation, and cross-range isolation tests.
• Backend manifests must distinguish declared support, configured capacity, and measured realization.

Consumer

Required by autarchy-ai/penumbra-scenarios#556. The model is general to participants and shared services; no provider, product, or KeplerOps-specific fields.

Architecture and governance requirements

Before implementation, reconcile this need against existing requirements, issues, ADRs, architecture, semantic owners, and already-provided capability; extend an incumbent concept rather than creating a parallel surface. Record relevant external and internal precedent and fully update the RAES lineage material. Add or amend ADRs when the design changes architecture or authority. Update normative specification, schemas/contracts, compiler, validator, runtime, backend manifests and admission, conformance guards, documentation, tests, release notes, and migration guidance wherever the chosen design applies. Establish and verify bidirectional requirement, issue, implementation, test, and release traceability. The issue is not complete until the released package exposes and guards the capability end to end.

[Brad-Edwards]

🛠️ Picked up by /implement - driver codex, branch 899-participant-resource-budgets, 2026-07-27T01:02:36.574Z.

[Brad-Edwards]

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

Design

Implement ADR-097 as a versioned participant-autonomous-execution/v3 extension over the existing v2 activity policy. Add one closed participant-resource-budget family with typed owner scopes, six governed resource kinds, compatible units/meters, finite parent aggregation, reset ownership, and explicit fairness requirements. Preserve v1/v2 semantics and compile their existing attempt/in-flight maxima into the same internal demand representation with legacy provenance.

Keep the four authorities separate throughout: authored demand; manifest-declared support; configuration-bound pool capacity; runtime state/evidence. Reuse the existing participant scheduler, execution bindings/service state, backend capabilities.participant_runtime root, deployment-tenant/shared-service identities, RuntimeSnapshot, ControlPlaneStore, Diagnostic, schema bundle/publication tooling, and conformance path. Do not add a quota service, generic numeric map, provider/model/device field, exception hierarchy, store, endpoint, or telemetry authority.

TDD and implementation

1. Add focused issue-899 tests first and confirm red behavior for: closed v3 SDL shape; all six resource dimensions; unit/meter compatibility; acyclic single-parent aggregation; tenant/shared-service/fleet ownership; reset restrictions; compiler canonicalization and v1/v2 legacy projection; exact manifest round-trip; atomic full-vector capacity admission; unsupported dimension/meter/fairness/isolation rejection; evaluated-capacity protection independent of participant role; generation-fenced reserve/commit/release/throttle/reconcile transitions; episode reset preserving independently owned usage; execution-service concurrency equality; and cross-range isolation.
2. Add authored models and semantic validation under the incumbent participant behavior/autonomous-execution surfaces, then compile canonical owner, demand, aggregation, fairness, pool, and digest identities into ParticipantAutonomousExecutionRuntime.
3. Add closed contract carriers for policy/demand, configured pool capacity, runtime state, and append-only events. Extend ParticipantRuntimeCapabilitiesModel/ParticipantRuntimeCapabilities and their manifest adapters without adding primary supports_*/max_* fields. Extend backend admission to aggregate the complete vector atomically against configured capacity, isolation, fairness, exact meters, and existing action-to-target bindings.
4. Add a pure budget accounting transition module used by the existing scheduler. Initialize typed budget state from admitted v3 demand and configured pools; reserve before native work; commit measured/declared governed quantities or release exactly once; throttle/reject without partial mutation; fence on execution generation; and reconcile before reset. Project authoritative concurrent-action state into ParticipantExecutionServiceStateModel.budget_state_refs and validate equality instead of maintaining an independent counter.
5. Persist first-class budget state/events through RuntimeSnapshot, snapshot envelopes, control-plane store/API projection, and conformance validation. Add negative/race/reset/cross-range probes with bounded safe diagnostics and evidence references.

Security, reliability, and repository-wide boundaries

• Validate at closed SDL/Pydantic shape, semantic reference/unit/meter/graph checks, canonical compiler output, planner admission, runtime transition, snapshot persistence, and conformance boundaries. Reuse existing parser limits and redacted error paths.
• Capacity configuration is typed and digest-bound in the manifest; no unchecked **config, environment-only capacity, argv/device paths, free-form constraints, or backend payloads. Portable records contain logical refs, counts, digests, dispositions, limitations, and evidence only—never credentials, prompts, completions, images, hidden truth, or backend-native identifiers.
• Reservations are atomic across every owner ancestor and resource dimension, idempotent by operation/action identity, serialized in the existing snapshot owner, and released/reconciled on failure, cancellation, stale generation, teardown, or reset. Logs/audit/OTel may mirror bounded identifiers but are not accounting or evidence state.
• The extension seam is the governed resource-kind plus unit/meter/accounting profile catalog. A future CPU, memory, network, or accelerator class adds a typed catalog entry and conformance case rather than another field/root. Multi-resource fairness stays vector-valued; no scalar cost collapse.

Publication and verification

Update ADR-097 to accepted when the implementation lands; amend ADR-092; update the formal autonomous-execution and deployment-tenancy specifications, backend/runtime reference docs, migration guidance, ADR indexes, SDL lineage ledger/source audit, examples/agent guidance where applicable, contract fixtures, schema bundle routing, authority lists, generated normative schemas, and every affected schema-publication last_change hash. Do not edit CHANGELOG.md or _version.py; use a consumer-visible feat: PR title.

During development run only the new issue-899 test module plus directly affected participant manifest/scheduler/snapshot tests, batched after red-green slices. At the final tree run the mandatory repository policy, requirement-governance, verify_all.py, configured completion, and Ground Control review gates once; reuse unchanged evidence rather than repeating broad suites.

[Brad-Edwards]

gc_codex_review — cycle 1 of 1 (pre-push) on issue #899 (branch 899-participant-resource-budgets)
Diff mode: manifest — the complete diff exceeded one prompt and was reviewed as 2/2 inline slice(s) (file-slices) covering 83/83 file(s)

Core review

Verdict: don't-ship

Slice 1/2: The change is broadly shaped around the correct seams: v3 is an explicit policy version, authored demand, configured capacity, and runtime evidence remain separate carriers, compilation produces canonical resource models, and admission extends the incumbent manifest and snapshot boundaries. However, two load-bearing invariants are absent across those seams: runtime state identity cannot represent multiple policies using the same local dimension names, and capacity admission never aggregates sibling demands sharing a pool. Those defects foreclose the ordinary multi-participant/shared-pool case that motivates the design, so the architecture is not yet production-ready.

Slice 2/2: The change introduces sensible seams—a dedicated budget ledger, scheduler integration, durable snapshot projection, and typed contracts—but the runtime authority is shaped as independent per-budget counters rather than scoped budgets backed by shared pool accounting. Consequently, the declared fairness and shared-capacity model is not actually enforced, and even a second v3 policy using ordinary local dimension names cannot coexist. The settlement boundary also commits estimates without consuming validated native measurements. These are structural gaps in the central v3 contract, not polish; the obvious next variation of multiple participants sharing a service is already foreclosed.

Blocking findings (6):

1. [class] Architecture-fit: Runtime budget state is keyed by a policy-local identifier — implementations/python/packages/raes_contracts/contracts/realization_plans.py:204
budget_id is unique only within one resource-budget policy, as shown by the policy model and the accompanying policy_address on runtime state. Requiring the top-level snapshot key to equal state.budget_id means two valid policies cannot both expose a conventional dimension such as concurrency or tokens: one state must overwrite the other or the snapshot becomes unrepresentable. Introduce a globally stable state identity—such as a canonical policy-address/budget-id composite—and use it consistently for snapshot keys, execution-service references, events, and lookups.
2. [class] Architecture-fit: Pool admission ignores aggregate demand — implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:113
   Admission compares each demand's limit with pool capacity independently. Multiple sibling dimensions may target the same configured pool, and both policy representations only require each child limit to be no greater than its parent; neither verifies that sibling demand aggregates fit the parent or pool. Consequently, two 80-unit demands can both pass against a 100-unit pool even though the declared vector requires 160 units. Canonicalize and aggregate demands by pool and comparable resource/meter identity before performing the capacity decision, including parent-graph accounting without double counting.
3. [one-off] Code-quality: Budget events accept contradictory transitions and dispositions — contracts/schemas/participant-runtime/participant-resource-budget-event-v1.json:118
transition and disposition are independent enums, while the Pydantic validator only checks that commit events have a measurement. Invalid evidence such as transition: reserve with disposition: reconciled therefore passes the published contract and snapshot validation. Enforce the legal transition/disposition mapping so the append-only event stream cannot encode contradictory state transitions.
4. [class] Architecture-fit: Shared pool capacity is enforced independently per budget — implementations/python/packages/raes_runtime/participant_resource_budgets.py:226
   Each budget state receives the pool's full configured capacity, and reservation compares usage only against that individual state. Two policies bound to the same configured pool can therefore each consume the full pool capacity; no aggregate pool reservation, weighted-fair allocation, protected capacity, queue bound, borrowing, reclaim, or starvation bound participates in the decision. Admission of fairness metadata is not runtime enforcement. Introduce a pool-scoped allocation authority and make the complete-vector reservation atomically acquire both budget/ancestor limits and aggregate pool capacity; pin this with competing-policy tests against one shared pool.
5. [class] Architecture-fit: Runtime budget identity drops the policy scope — implementations/python/packages/raes_runtime/participant_resource_budgets.py:113
   The state map is keyed directly by the authored dimension-level budget_id. The fixtures and tests demonstrate local identifiers such as tokens, so two v3 policies using the same conventional dimension name conflict during initialization even when their policy addresses and owners differ. Subsequent reserve, commit, reconciliation, and execution-service references all inherit the same collision. Use a canonical policy-scoped budget-state address as the map key and reference identity while retaining budget_id as local contract data; test two policies with overlapping dimension names.
6. [one-off] Code-quality: Scheduler settles reservations without a validated measurement — implementations/python/packages/raes_runtime/participant_scheduler_operations.py:338
   The scheduler calls resource commit unconditionally after recording the protocol result, including when that result is a protocol failure, and the integration passes neither measured quantities nor backend evidence. The commit API consequently substitutes every reservation quantity as measured usage and emits a synthetic evidence reference. That is incorrect for tokens, storage, images, and accelerator usage and contradicts the documented ordering that settlement follows native-result validation. Gate settlement on the defined result disposition, extract authoritative measurements/evidence from the validated result, and explicitly release or reconcile reservations when settlement cannot be trusted.

Security review

Verdict: don't-ship

Slice 1/2: This slice introduces resource governance at the appropriate authored-policy, compiler, manifest-admission, and runtime-contract seams. The shape is broadly coherent, but the new security boundary is not closed end to end: resource identities are validated independently from the participant, tenant, and native execution binding they are intended to govern, and configured capacity is evaluated per demand rather than across the admitted pool vector. Those gaps permit policy authors to obtain admission without actually constraining the resources their actions consume.

Slice 2/2: The change places v3 accounting behind a dedicated runtime ledger and scheduler reserve/commit hooks, then consistently projects it through snapshot persistence and control-plane state; that is the right design seam. However, configured pools are represented as copies inside policy-local budgets, and settlement is disconnected from backend meter evidence. Those omissions cross the security boundary this feature is intended to enforce and fail the obvious next variation—multiple policies or tenants sharing one finite pool—so this is not yet safe to ship.

Blocking findings (4):

1. [class] Resource admission is not bound to the authorized execution target or tenant — implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:96
   Attacker model: an SDL author who may define autonomous behavior but is supposed to remain within its participant, deployment-tenant, and shared-service resource scope. The semantic validator only establishes that a tenant or shared-service reference exists, the compiler resolves that reference independently, and admission then matches the resulting demand against a configured pool. Nothing proves that the shared-service owner/pool is the service reached by the action's execution binding, or that the deployment-tenant owner is the participant's tenant and has the required uses_shared_service relationship. An author can therefore bind native work to constrained service B while assigning token/image/accelerator demands to an available service or pool A; admission succeeds against A while execution consumes B, bypassing B's quota and tenant-isolation policy. Resolve these relationships from the participant tenancy and exact action-to-target bindings, require the authorized shared-service edge, and derive cross-range isolation requirements from that resolved topology rather than from independently supplied references.
2. [one-off] Per-demand capacity checks allow aggregate pool oversubscription — implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:118
   Attacker model: a scenario author constrained by a configured shared-service capacity. Policies may contain multiple dimensions with the same canonical owner, pool, resource kind, accounting mode, unit, and meter, and multiple governed policies can target that same pool. Admission compares each demand.limit independently with pool.capacity, without aggregating those demands or rejecting aliases. An author can split a requested token or accelerator allowance into two dimensions whose individual limits each fit the pool while their combined limit exceeds it; every check passes and the plan is admitted beyond configured capacity, allowing the author to consume capacity reserved for other tenants or protected participants. Canonicalize demands by pool identity, detect duplicate aliases/double counting, and admit the complete aggregated vector atomically, including parent-scope totals.
3. [class] Shared pool capacity can be multiplied through distinct budget IDs — implementations/python/packages/raes_runtime/participant_resource_budgets.py:143
   Attacker model: a tenant or scenario author permitted to define v3 policies against an admitted shared-service pool. Initialization copies the pool's complete configured capacity into each state keyed by budget_id, while reservation enforcement checks only that budget-local copy. An attacker can therefore create multiple policies or demands with distinct budget IDs referencing the same canonical pool; every demand independently receives the full pool capacity and passes admission, allowing aggregate consumption of N times the configured entitlement. This bypasses shared-resource authorization and can consume capacity or billable inference resources reserved for other tenants. Enforce capacity through one authoritative ledger keyed by the canonical pool identity, and atomically reserve both policy budgets and their shared pool/tenant partition rather than duplicating pool capacity per demand.
4. [class] Runtime settlement charges declared reservations instead of measured consumption — implementations/python/packages/raes_runtime/participant_scheduler_resources.py:53
   Attacker model: participant-controlled work whose native action can consume more tokens, storage, images, or accelerator time than its declared reservation. After native execution, the scheduler supplies no measured quantities and fabricates a local evidence reference; the ledger consequently defaults every measured value to the reservation. A participant can repeatedly consume substantially more backend resources than are recorded, keeping the authoritative budget below its limit and bypassing the intended quota and cost boundary. Require trusted, per-budget meter results from the native action, validate their binding to the operation and generation, and fail closed when required measurement evidence is absent.

[Brad-Edwards]

gc_codex_review pre-push cycle 1 of 1 complete for issue #899 on branch '899-participant-resource-budgets'. 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.

[Brad-Edwards]

Review decision record — codex cycle 1 (issue #899)

Reviewer: codex
Cycle: 1

Architectural read:

Core reviewer: Slice 1/2: The change is broadly shaped around the correct seams: v3 is an explicit policy version, authored demand, configured capacity, and runtime evidence remain separate carriers, compilation produces canonical resource models, and admission extends the incumbent manifest and snapshot boundaries. However, two load-bearing invariants are absent across those seams: runtime state identity cannot represent multiple policies using the same local dimension names, and capacity admission never aggregates sibling demands sharing a pool. Those defects foreclose the ordinary multi-participant/shared-pool case that motivates the design, so the architecture is not yet production-ready.

Slice 2/2: The change introduces sensible seams—a dedicated budget ledger, scheduler integration, durable snapshot projection, and typed contracts—but the runtime authority is shaped as independent per-budget counters rather than scoped budgets backed by shared pool accounting. Consequently, the declared fairness and shared-capacity model is not actually enforced, and even a second v3 policy using ordinary local dimension names cannot coexist. The settlement boundary also commits estimates without consuming validated native measurements. These are structural gaps in the central v3 contract, not polish; the obvious next variation of multiple participants sharing a service is already foreclosed.

Security reviewer: Slice 1/2: This slice introduces resource governance at the appropriate authored-policy, compiler, manifest-admission, and runtime-contract seams. The shape is broadly coherent, but the new security boundary is not closed end to end: resource identities are validated independently from the participant, tenant, and native execution binding they are intended to govern, and configured capacity is evaluated per demand rather than across the admitted pool vector. Those gaps permit policy authors to obtain admission without actually constraining the resources their actions consume.

Slice 2/2: The change places v3 accounting behind a dedicated runtime ledger and scheduler reserve/commit hooks, then consistently projects it through snapshot persistence and control-plane state; that is the right design seam. However, configured pools are represented as copies inside policy-local budgets, and settlement is disconnected from backend meter evidence. Those omissions cross the security boundary this feature is intended to enforce and fail the obvious next variation—multiple policies or tenants sharing one finite pool—so this is not yet safe to ship.

Blocking findings: 10

Finding 1 — class (4 instances)

• ID: F1
• Title: [core] Architecture-fit: Runtime budget state is keyed by a policy-local identifier
• Location: implementations/python/packages/raes_contracts/contracts/realization_plans.py:204
• Decision: fix
• Rationale: budget_id is unique only within one resource-budget policy, as shown by the policy model and the accompanying policy_address on runtime state. Requiring the top-level snapshot key to equal state.budget_id means two valid policies can…
• Instances:
  • implementations/python/packages/raes_contracts/contracts/realization_plans.py:179
  • implementations/python/packages/raes_contracts/contracts/realization_plans.py:204
  • implementations/python/packages/raes_contracts/runtime_state.py:90
  • implementations/python/packages/raes_contracts/runtime_state.py:259

Finding 2 — class (3 instances)

• ID: F2
• Title: [core] Architecture-fit: Pool admission ignores aggregate demand
• Location: implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:113
• Decision: fix
• Rationale: Admission compares each demand's limit with pool capacity independently. Multiple sibling dimensions may target the same configured pool, and both policy representations only require each child limit to be no greater than its parent; neith…
• Instances:
  • implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:113
  • implementations/python/packages/raes/participant_resource_budgets.py:187
  • implementations/python/packages/raes_contracts/contracts/participant_resource_budgets.py:185

Finding 3 — one-off

• ID: F3
• Title: [core] Code-quality: Budget events accept contradictory transitions and dispositions
• Location: contracts/schemas/participant-runtime/participant-resource-budget-event-v1.json:118
• Decision: fix
• Rationale: transition and disposition are independent enums, while the Pydantic validator only checks that commit events have a measurement. Invalid evidence such as transition: reserve with disposition: reconciled therefore passes the publis…

Finding 4 — class (2 instances)

• ID: F4
• Title: [core] Architecture-fit: Shared pool capacity is enforced independently per budget
• Location: implementations/python/packages/raes_runtime/participant_resource_budgets.py:226
• Decision: fix
• Rationale: Each budget state receives the pool's full configured capacity, and reservation compares usage only against that individual state. Two policies bound to the same configured pool can therefore each consume the full pool capacity; no aggrega…
• Instances:
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:143
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:226

Finding 5 — class (9 instances)

• ID: F5
• Title: [core] Architecture-fit: Runtime budget identity drops the policy scope
• Location: implementations/python/packages/raes_runtime/participant_resource_budgets.py:113
• Decision: fix
• Rationale: The state map is keyed directly by the authored dimension-level budget_id. The fixtures and tests demonstrate local identifiers such as tokens, so two v3 policies using the same conventional dimension name conflict during initialization …
• Instances:
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:113
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:129
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:190
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:251
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:290
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:351
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:397
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:425
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:477

Finding 6 — one-off

• ID: F6
• Title: [core] Code-quality: Scheduler settles reservations without a validated measurement
• Location: implementations/python/packages/raes_runtime/participant_scheduler_operations.py:338
• Decision: fix
• Rationale: The scheduler calls resource commit unconditionally after recording the protocol result, including when that result is a protocol failure, and the integration passes neither measured quantities nor backend evidence. The commit API conseque…

Finding 7 — class (3 instances)

• ID: F7
• Title: [security] Resource admission is not bound to the authorized execution target or tenant
• Location: implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:96
• Decision: fix
• Rationale: Attacker model: an SDL author who may define autonomous behavior but is supposed to remain within its participant, deployment-tenant, and shared-service resource scope. The semantic validator only establishes that a tenant or shared-servic…
• Instances:
  • implementations/python/packages/raes/validator/_participant_resource_budget_owners.py:30
  • implementations/python/packages/raes_processor/compiler/participant_autonomous_execution.py:42
  • implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:96

Finding 8 — one-off

• ID: F8
• Title: [security] Per-demand capacity checks allow aggregate pool oversubscription
• Location: implementations/python/packages/raes_backend_protocols/participant_resource_admission.py:118
• Decision: fix
• Rationale: Attacker model: a scenario author constrained by a configured shared-service capacity. Policies may contain multiple dimensions with the same canonical owner, pool, resource kind, accounting mode, unit, and meter, and multiple governed pol…

Finding 9 — class (2 instances)

• ID: F9
• Title: [security] Shared pool capacity can be multiplied through distinct budget IDs
• Location: implementations/python/packages/raes_runtime/participant_resource_budgets.py:143
• Decision: fix
• Rationale: Attacker model: a tenant or scenario author permitted to define v3 policies against an admitted shared-service pool. Initialization copies the pool's complete configured capacity into each state keyed by budget_id, while reservation enfo…
• Instances:
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:143
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:226

Finding 10 — class (2 instances)

• ID: F10
• Title: [security] Runtime settlement charges declared reservations instead of measured consumption
• Location: implementations/python/packages/raes_runtime/participant_scheduler_resources.py:53
• Decision: fix
• Rationale: Attacker model: participant-controlled work whose native action can consume more tokens, storage, images, or accelerator time than its declared reservation. After native execution, the scheduler supplies no measured quantities and fabricat…
• Instances:
  • implementations/python/packages/raes_runtime/participant_scheduler_resources.py:53
  • implementations/python/packages/raes_runtime/participant_resource_budgets.py:360

[Brad-Edwards]

Pre-PR base synchronization

• Source: refs/remotes/origin/dev at d8937cbf7e92356ca8678bb6a01ff88baa050531
• Outcome: already_current
• Published feature head: b488c67d59c2f9ab8b0be5ef4e92100014d54016
• Verified tree: 44c96a61cb4034fb9cce6f0b2e67414677f4ab9a

[Brad-Edwards]

Ready for review — issue #899

PR: #929
Plan: #899 (comment)

Outcome

Participant autonomous execution policies can now declare complete resource budgets across participant, tenant, shared-service, and fleet scopes. Admission and runtime accounting enforce physical-pool capacity, fairness, generation fencing, and trusted native measurement evidence.

Implemented scoped participant resource budgets and shared-service fairness. Narrow issue tests passed (18/18); canonical CI, Docs, CodeQL, security, fuzz, integration, and Sonar all passed.

Files changed

Added:

• contracts/fixtures/participant-runtime/participant-resource-budget-event-v1/valid/token-commit-event.json
• contracts/fixtures/participant-runtime/participant-resource-budget-policy-v1/valid/complete-resource-vector.json
• contracts/fixtures/participant-runtime/participant-resource-budget-state-v1/valid/token-budget-state.json
• contracts/fixtures/participant-runtime/participant-resource-pool-capacity-v1/valid/configured-inference-pool.json
• contracts/schema-publication/entries/participant-resource-budget-event-v1.json
• contracts/schema-publication/entries/participant-resource-budget-policy-v1.json
• contracts/schema-publication/entries/participant-resource-budget-state-v1.json
• contracts/schema-publication/entries/participant-resource-pool-capacity-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-event-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-policy-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-state-v1.json
• contracts/schemas/participant-runtime/participant-resource-pool-capacity-v1.json
• docs/decisions/adrs/adr-097-scoped-participant-resource-budgets-and-shared-service-fairness.md
• docs/migration/autonomous-execution-v3.md
• implementations/python/packages/raes/participant_resource_budgets.py
• implementations/python/packages/raes/validator/_participant_resource_budget_owners.py
• implementations/python/packages/raes_backend_protocols/participant_resource_admission.py
• implementations/python/packages/raes_backend_protocols/participant_resource_budgets.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_budgets.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_types.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_validation.py
• implementations/python/packages/raes_processor/models/participant_resources.py
• implementations/python/packages/raes_runtime/participant_resource_accounting.py
• implementations/python/packages/raes_runtime/participant_resource_budgets.py
• implementations/python/packages/raes_runtime/participant_resource_pool_ledger.py
• implementations/python/packages/raes_runtime/participant_resource_reservation.py
• implementations/python/packages/raes_runtime/participant_scheduler_lifecycle.py
• implementations/python/packages/raes_runtime/participant_scheduler_resources.py
• implementations/python/tests/test_issue_899_participant_resource_budgets.py

Modified:

• contracts/fixtures/backend-manifest/backend-manifest-v2/valid/stub.json
• contracts/provenance/sdl-lineage-ledger-v1.json
• contracts/schema-publication/entries/backend-manifest-v2.json
• contracts/schema-publication/entries/backend-profile-v1.json
• contracts/schema-publication/entries/instantiated-scenario-snapshot-v1.json
• contracts/schema-publication/entries/instantiated-scenario-v1.json
• contracts/schema-publication/entries/participant-behavior-history-event-stream-v1.json
• contracts/schema-publication/entries/participant-execution-service-state-v1.json
• contracts/schema-publication/entries/participant-history-view-v1.json
• contracts/schema-publication/entries/processor-manifest-v2.json
• contracts/schema-publication/entries/runtime-snapshot-v1.json
• contracts/schema-publication/entries/scenario-satisfiability-evidence-v1.json
• contracts/schema-publication/entries/sdl-authoring-input-v1.json
• contracts/schemas/backend-manifest/backend-manifest-v2.json
• contracts/schemas/control-plane/participant-behavior-history-event-stream-v1.json
• contracts/schemas/control-plane/participant-history-view-v1.json
• contracts/schemas/participant-runtime/participant-execution-service-state-v1.json
• contracts/schemas/processor-manifest/processor-manifest-v2.json
• contracts/schemas/profiles/backend-profile-v1.json
• contracts/schemas/satisfiability/scenario-satisfiability-evidence-v1.json
• contracts/schemas/sdl/instantiated-scenario-snapshot-v1.json
• contracts/schemas/sdl/instantiated-scenario-v1.json
• contracts/schemas/sdl/sdl-authoring-input-v1.json
• contracts/schemas/snapshots/runtime-snapshot-v1.json
• docs/decisions/adrs/README.md
• docs/explain/reference/backend-conformance.md
• docs/index.md
• docs/migration/README.md
• docs/research/lineage/source-audit-2026-07-12.md
• implementations/python/packages/raes/_mapping_scopes.py
• implementations/python/packages/raes/composition.py
• implementations/python/packages/raes/participant_execution.py
• implementations/python/packages/raes/semantics/participant_behavior.py
• implementations/python/packages/raes/validator/_content_objectives.py
• implementations/python/packages/raes_backend_protocols/capability_admission.py
• implementations/python/packages/raes_backend_protocols/participant_capabilities.py
• implementations/python/packages/raes_backend_protocols/participant_execution_manifest.py
• implementations/python/packages/raes_conformance/conformance/snapshot_semantics.py
• implementations/python/packages/raes_contracts/contracts/bundle.py
• implementations/python/packages/raes_contracts/contracts/manifests.py
• implementations/python/packages/raes_contracts/contracts/participant_execution.py
• implementations/python/packages/raes_contracts/contracts/participant_runtime.py
• implementations/python/packages/raes_contracts/contracts/realization_plans.py
• implementations/python/packages/raes_contracts/manifest_authority.py
• implementations/python/packages/raes_contracts/participant_binding.py
• implementations/python/packages/raes_contracts/participant_binding_validation.py
• implementations/python/packages/raes_contracts/runtime_state.py
• implementations/python/packages/raes_processor/compiler/participant_autonomous_execution.py
• implementations/python/packages/raes_processor/models/__init__.py
• implementations/python/packages/raes_processor/models/behavior_resources.py
• implementations/python/packages/raes_runtime/control_plane_api_models.py
• implementations/python/packages/raes_runtime/control_plane_store.py
• implementations/python/packages/raes_runtime/participant_activity_support.py
• implementations/python/packages/raes_runtime/participant_execution_control.py
• implementations/python/packages/raes_runtime/participant_execution_scheduler_state.py
• implementations/python/packages/raes_runtime/participant_scheduler.py
• implementations/python/packages/raes_runtime/participant_scheduler_concurrency.py
• implementations/python/packages/raes_runtime/participant_scheduler_operations.py
• implementations/python/packages/raes_runtime/participant_scheduler_policy.py
• implementations/python/packages/raes_runtime/participant_scheduler_time.py
• implementations/python/tests/test_dsl_437_benign_participant_execution.py
• specs/formal/participant-semantics/autonomous-execution.md
• tools/generate_contract_schemas.py
• tools/policy/historical_identity_records.json

Reviews

• codex: One bounded pre-push review cycle completed and all actionable findings were resolved; no over-cap review cycles were run.

Traceability reconciliation

• Pending — requirement status transition and IMPLEMENTS/TESTS reconciliation run in Phase E once the PR merges.

Status

• CI: ✅ green
• SonarCloud: ✅ passed
• PR ready for user review and merge. Ground Control reconciliation (requirement status + traceability) runs on merge (Phase E).

[Brad-Edwards]

gc workflow phase recorded: traceability_reconciled (issue #899). 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.

no in-scope requirements; touched-files audit clean.

[Brad-Edwards]

gc workflow phase recorded: traceability_reconciled (issue #899). 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.

no in-scope requirements; touched-files audit clean.

[Brad-Edwards]

Final report — issue #899 complete

PR: #929
Plan: #899 (comment)

Outcome

Participant autonomous execution policies can now declare complete resource budgets across participant, tenant, shared-service, and fleet scopes. Admission and runtime accounting enforce physical-pool capacity, fairness, generation fencing, and trusted native measurement evidence.

Implemented scoped participant resource budgets and shared-service fairness. Narrow issue tests passed (18/18); canonical CI, documentation, CodeQL, security, fuzz, integration, and Sonar gates passed.

Files changed

Added:

• contracts/fixtures/participant-runtime/participant-resource-budget-event-v1/valid/token-commit-event.json
• contracts/fixtures/participant-runtime/participant-resource-budget-policy-v1/valid/complete-resource-vector.json
• contracts/fixtures/participant-runtime/participant-resource-budget-state-v1/valid/token-budget-state.json
• contracts/fixtures/participant-runtime/participant-resource-pool-capacity-v1/valid/configured-inference-pool.json
• contracts/schema-publication/entries/participant-resource-budget-event-v1.json
• contracts/schema-publication/entries/participant-resource-budget-policy-v1.json
• contracts/schema-publication/entries/participant-resource-budget-state-v1.json
• contracts/schema-publication/entries/participant-resource-pool-capacity-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-event-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-policy-v1.json
• contracts/schemas/participant-runtime/participant-resource-budget-state-v1.json
• contracts/schemas/participant-runtime/participant-resource-pool-capacity-v1.json
• docs/decisions/adrs/adr-097-scoped-participant-resource-budgets-and-shared-service-fairness.md
• docs/migration/autonomous-execution-v3.md
• implementations/python/packages/raes/participant_resource_budgets.py
• implementations/python/packages/raes/validator/_participant_resource_budget_owners.py
• implementations/python/packages/raes_backend_protocols/participant_resource_admission.py
• implementations/python/packages/raes_backend_protocols/participant_resource_budgets.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_budgets.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_types.py
• implementations/python/packages/raes_contracts/contracts/participant_resource_validation.py
• implementations/python/packages/raes_processor/models/participant_resources.py
• implementations/python/packages/raes_runtime/participant_resource_accounting.py
• implementations/python/packages/raes_runtime/participant_resource_budgets.py
• implementations/python/packages/raes_runtime/participant_resource_pool_ledger.py
• implementations/python/packages/raes_runtime/participant_resource_reservation.py
• implementations/python/packages/raes_runtime/participant_scheduler_lifecycle.py
• implementations/python/packages/raes_runtime/participant_scheduler_resources.py
• implementations/python/tests/test_issue_899_participant_resource_budgets.py

Modified:

• contracts/fixtures/backend-manifest/backend-manifest-v2/valid/stub.json
• contracts/provenance/sdl-lineage-ledger-v1.json
• contracts/schema-publication/entries/backend-manifest-v2.json
• contracts/schema-publication/entries/backend-profile-v1.json
• contracts/schema-publication/entries/instantiated-scenario-snapshot-v1.json
• contracts/schema-publication/entries/instantiated-scenario-v1.json
• contracts/schema-publication/entries/participant-behavior-history-event-stream-v1.json
• contracts/schema-publication/entries/participant-execution-service-state-v1.json
• contracts/schema-publication/entries/participant-history-view-v1.json
• contracts/schema-publication/entries/processor-manifest-v2.json
• contracts/schema-publication/entries/runtime-snapshot-v1.json
• contracts/schema-publication/entries/scenario-satisfiability-evidence-v1.json
• contracts/schema-publication/entries/sdl-authoring-input-v1.json
• contracts/schemas/backend-manifest/backend-manifest-v2.json
• contracts/schemas/control-plane/participant-behavior-history-event-stream-v1.json
• contracts/schemas/control-plane/participant-history-view-v1.json
• contracts/schemas/participant-runtime/participant-execution-service-state-v1.json
• contracts/schemas/processor-manifest/processor-manifest-v2.json
• contracts/schemas/profiles/backend-profile-v1.json
• contracts/schemas/satisfiability/scenario-satisfiability-evidence-v1.json
• contracts/schemas/sdl/instantiated-scenario-snapshot-v1.json
• contracts/schemas/sdl/instantiated-scenario-v1.json
• contracts/schemas/sdl/sdl-authoring-input-v1.json
• contracts/schemas/snapshots/runtime-snapshot-v1.json
• docs/decisions/adrs/README.md
• docs/explain/reference/backend-conformance.md
• docs/migration/README.md
• docs/research/lineage/source-audit-2026-07-12.md
• implementations/python/packages/raes/_mapping_scopes.py
• implementations/python/packages/raes/composition.py
• implementations/python/packages/raes/participant_execution.py
• implementations/python/packages/raes/semantics/participant_behavior.py
• implementations/python/packages/raes/validator/_content_objectives.py
• implementations/python/packages/raes_backend_protocols/capability_admission.py
• implementations/python/packages/raes_backend_protocols/participant_capabilities.py
• implementations/python/packages/raes_backend_protocols/participant_execution_manifest.py
• implementations/python/packages/raes_conformance/conformance/snapshot_semantics.py
• implementations/python/packages/raes_contracts/contracts/bundle.py
• implementations/python/packages/raes_contracts/contracts/manifests.py
• implementations/python/packages/raes_contracts/contracts/participant_execution.py
• implementations/python/packages/raes_contracts/contracts/participant_runtime.py
• implementations/python/packages/raes_contracts/contracts/realization_plans.py
• implementations/python/packages/raes_contracts/manifest_authority.py
• implementations/python/packages/raes_contracts/participant_binding.py
• implementations/python/packages/raes_contracts/participant_binding_validation.py
• implementations/python/packages/raes_contracts/runtime_state.py
• implementations/python/packages/raes_processor/compiler/participant_autonomous_execution.py
• implementations/python/packages/raes_processor/models/__init__.py
• implementations/python/packages/raes_processor/models/behavior_resources.py
• implementations/python/packages/raes_runtime/control_plane_api_models.py
• implementations/python/packages/raes_runtime/control_plane_store.py
• implementations/python/packages/raes_runtime/participant_activity_support.py
• implementations/python/packages/raes_runtime/participant_execution_control.py
• implementations/python/packages/raes_runtime/participant_execution_scheduler_state.py
• implementations/python/packages/raes_runtime/participant_scheduler.py
• implementations/python/packages/raes_runtime/participant_scheduler_concurrency.py
• implementations/python/packages/raes_runtime/participant_scheduler_operations.py
• implementations/python/packages/raes_runtime/participant_scheduler_policy.py
• implementations/python/packages/raes_runtime/participant_scheduler_time.py
• implementations/python/tests/test_dsl_437_benign_participant_execution.py
• specs/formal/participant-semantics/autonomous-execution.md
• tools/generate_contract_schemas.py
• tools/policy/historical_identity_records.json

Reviews

• codex: One bounded pre-push review cycle completed and all actionable findings were resolved; no over-cap review cycles were run.

Traceability reconciliation

• IMPLEMENTS / TESTS / DOCUMENTS added: 0
• Links updated: 0
• Stale links removed: 0

Requirement-free issue; reconciled all 92 shipped artifacts and found no Ground Control requirement-link changes needed.

Status

• CI: ✅ green
• SonarCloud: ✅ passed
• PR ready for user review and merge.