Goal
Add a provider-neutral export profile for ProofPath authorization decisions so downstream runtimes can join them to execution observations and response-integrity records without weakening ProofPath's pre-execution boundary.
Canonical profile: safal207/Liminal#108
Why
ProofPath already verifies intent, policy, expiry, nonce/replay state, recipient/scope constraints, and human approval before forwarding protected actions. The ecosystem now needs a stable authorization_record that other modules can consume without parsing ProofPath-specific audit internals.
Deliverables
- Define an exportable
authorization_record containing at least:
- transition/action identity;
- canonical arguments or arguments digest;
- policy/capability basis;
- decision and reason codes;
- decision time;
- expiry/freshness bound;
- replay/consumption state;
- continuation state where applicable;
- ProofPath audit/evidence references.
- Bind the record into the existing hash-chained audit and evidence bundle.
- Add a handoff contract for downstream
observation_record producers.
- Allow evidence bundles to carry externally produced
response_integrity_record files as optional referenced artifacts.
- Verify imported artifacts by digest and declared schema/profile without claiming ProofPath authored their verdicts.
Required fixtures
- ACCEPT with a valid unconsumed signed intent;
- HOLD for pending approval;
- BLOCK for expired intent;
- BLOCK for replayed/consumed nonce;
- ACCEPT followed by matching external observation;
- ACCEPT followed by contradicted external response-integrity verdict;
- valid response report paired with stale authorization.
Boundary
- ProofPath remains the authority producer and evidence packager.
- ProofPath does not become the post-response claim verifier.
- An imported integrity receipt must retain its original issuer/verifier identity and claim boundary.
Acceptance criteria
Goal
Add a provider-neutral export profile for ProofPath authorization decisions so downstream runtimes can join them to execution observations and response-integrity records without weakening ProofPath's pre-execution boundary.
Canonical profile: safal207/Liminal#108
Why
ProofPath already verifies intent, policy, expiry, nonce/replay state, recipient/scope constraints, and human approval before forwarding protected actions. The ecosystem now needs a stable
authorization_recordthat other modules can consume without parsing ProofPath-specific audit internals.Deliverables
authorization_recordcontaining at least:observation_recordproducers.response_integrity_recordfiles as optional referenced artifacts.Required fixtures
Boundary
Acceptance criteria