Context
The latest Catena writing frames real-money agents around two layers:
- an intelligence/trust layer that decides whether a payment should be attempted, and
- an enforcement layer that refuses to sign or execute unless policy conditions are satisfied.
ACK-Pay currently demonstrates payment request, execution, and receipt verification well. A small demo showing policy-before-signing would make the safety model more concrete without adding a full policy engine to ACK.
Proposal
Add a minimal demo or test fixture where a payment service/signer refuses to execute unless a deterministic policy check passes.
Example policy inputs:
paymentOption.amount below a threshold
- recipient DID or account on an allowlist
- optional human approval marker for external recipients
- payment request issuer matches expected server DID
Example outcomes:
- below-threshold known recipient: signs/executes automatically
- external recipient: returns approval required
- blocked recipient or amount above limit: fails before signing
Why this helps
This would demonstrate an important ACK principle: application code can propose a payment, but the signing/payment service should enforce policy before money moves.
It also gives ACK a neutral bridge to systems such as Sardis/FIDES/OAPS without importing their semantics into the core protocol.
Small first slice
- Keep it in
demos/e2e or demos/payments.
- Use a tiny local policy function, not a new dependency.
- Add one happy-path and one denied-path test or scripted demo step.
- Document that this is an example pattern, not a normative ACK policy engine.
Context
The latest Catena writing frames real-money agents around two layers:
ACK-Pay currently demonstrates payment request, execution, and receipt verification well. A small demo showing policy-before-signing would make the safety model more concrete without adding a full policy engine to ACK.
Proposal
Add a minimal demo or test fixture where a payment service/signer refuses to execute unless a deterministic policy check passes.
Example policy inputs:
paymentOption.amountbelow a thresholdExample outcomes:
Why this helps
This would demonstrate an important ACK principle: application code can propose a payment, but the signing/payment service should enforce policy before money moves.
It also gives ACK a neutral bridge to systems such as Sardis/FIDES/OAPS without importing their semantics into the core protocol.
Small first slice
demos/e2eordemos/payments.