Fiscal receipts.
A deployed agent issuing fiscal donation receipts for a non-profit operator surface, choosing per request whether it may act and refusing when the grant is absent.
Deployed agent — this configuration is running in production. Client identities are withheld.
Classified as an agent: it holds a defined responsibility and chooses, recommends or routes a permitted action from context.
No model anywhere in this entry. It is deterministic end to end — the behaviour comes from rules, arithmetic and explicit boundaries.
Objective
Let an operator import donations and issue, find, send, cancel and report fiscal receipts, while making every write grant-gated, tenant-scoped and replay-safe.
Runtime
01
Authenticate
Resolves a server-authoritative context from the operator session — never from the request body.
02
Validate
Checks the payload against the capability's own typed request model.
03
Authorise
Tests the resolved grants before any side effect runs.
04
Claim
Takes an idempotency claim in a durable ledger ahead of the first write.
05
Execute
Performs the fiscal write atomically and records the audit row.
Agent anatomy
Context
- Donation records
- Donor identity and history
- Receipt numbering state
- Delivery and reissue audit history
- Resolved integration credentials
Capabilities
- donations.import
- receipts.generate
- receipts.find
- receipts.send
- receipts.cancel
- receipts.report
- receipts.pdf
Activation
- Operator action in the surface
- In-process agent dispatch
Authority
What can it change?
- Autonomy
- Bounded
- Horizon
- Operator-invoked
Read
- Donations
- Donor records
- Issued receipts
- Delivery audit history
Write
- Receipt records
- Receipt artifacts
- Delivery and reissue audit rows
Conditional
- Issue a receipt when the exact capability grant is held
- Cancel and reissue with a recorded audit trail
Prohibited
- Read tenant scope from a request body
- Repeat a side effect on a replayed idempotency key
- Resolve credentials from caller-supplied identifiers
Escalate
- Missing grant
- Reused key with a different body
- Ambiguous upstream failure — fails closed to a runbook
Composition and verification
Made from explicit parts.
Composition
- Shared capability runtime
- Durable idempotency ledger
- Server-resolved authority context
- Fiscal renderer and storage
- Email delivery integration
Verification
- 230 passing contract and capability tests
- Structural tenant-isolation test over every request model
- Fail-closed production readiness gate
- Per-capability grant enforcement
- Idempotent replay returns the original result
No evidence is published for this entry. The items above are our own account of its source, read before publishing — not something you can check without taking our word for it.
Next step
What you can do with this.
This configuration runs in production, client identity withheld. To discuss the same for your operation, start with the problem rather than the system: a first call is thirty minutes and costs nothing.
Related entries