net-kingdom/tools/execution-attribution-receipt/README.md

37 lines
2.2 KiB
Markdown
Raw Normal View History

# Execution Attribution Receipt validator (NK-WP-0056-T15)
Schema `canon/schemas/execution-attribution-receipt_v0.1.schema.json` covers the bounded-executor profile of the
Playbook Capability Contract v0.2 receipt: the two events one executor run emits to audit-core, in audit-core's ingest
envelope.
- `execution.run.started` is sent after consume, before the first step. It carries `data.window.not_after`, so
audit-core holds the run to its own admission window (AUDIT-WP-0018-T03).
- `execution.attribution.receipt` is one per run, with every step, check result, revert and the budget used.
```bash
python3 tools/execution-attribution-receipt/validate.py validate EVENT.json... # EAR-1..EAR-9 per event
python3 tools/execution-attribution-receipt/validate.py pair STARTED.json RECEIPT.json # plus EAR-10 across the pair
python3 tools/execution-attribution-receipt/generate_fixtures.py [--check] # fixtures from the real executor
make execution-attribution-receipt-test
```
The rules are listed in `validate.py`. Findings name a rule and a location, never a value. The schema closes every
object (`additionalProperties: false`), so no field can carry a value an operation handled. Steps record identifiers,
outcomes, check results and an error *type* only.
`fixtures/valid/` holds three scenarios: `completed`, `reverted` and `completed-on-retry`. They are generated by
running `executor.Run` on in-memory fakes, and a test fails when they drift from what the executor emits. audit-core
can use them for AUDIT-WP-0014-T02 (canonical receipt validation).
Profile decisions (audit-core's open points in `docs/bounded-executor-receipts.md`):
- `target` is `admission:<id>` and `action` is `bounded-execution` at receipt level. Per-step targets stay in
`steps[]`.
- `decision_refs` are exactly `admission`, `admission_digest` and `approval`, as `{label, ref}`.
- `initiator.iss` is the approvers' issuer when configured, else the explicit `unknown`.
- `delegation` is absent: the pilot has no delegated initiator.
- `tenant` is the audit-core tenant (`platform`) and must equal the envelope tenant.
- `pdp` is `not-evaluated` in the pilot.
Not covered: the railiance-infra S1 runner profile (NK-WP-0040-T02), which waits on its own emitter decision.