Object model
Quitanza's object model has seven objects, and exactly one of them carries a brand name: the quitanza, the terminal settlement proof. Everything else is plain English.
| Object | Meaning |
|---|---|
| Mandate | Signed authorization from the principal: a spending ceiling, an asset, an expiry |
| Escrow | Funds locked against machine-readable Terms |
| Terms | Acceptance criteria the deliverable is judged against |
| Delivery | Provider's submitted result, content-addressed and signed |
| Verdict | Output of verification: pass or fail, with per-check detail |
| Dispute | Structured challenge inside the opted-in funnel |
| Quitanza | Terminal, signed, hash-chained settlement proof |
Escrow lifecycle
An escrow moves through a fixed state machine. Invalid transitions are rejected.
created → funded → delivered → settled (verdict passed)
│
├→ disputed → resolved (ruling applied)
└→ refunded (failed verdict, payer refund)
funded → refunded (payer cancels before delivery)
Every terminal state issues a quitanza: settled, resolved, or refunded. The proof records how the matter closed, not only that it closed in the payee's favor. A refund ends in proof too.
The evidence trail
Each escrow owns an append-only evidence trail. Every event is hashed and chained to its predecessor: creation, funding, delivery, verdict, dispute activity, issuance. Any retroactive edit changes every subsequent hash and is self-evident. The quitanza commits to the trail head at the moment of issuance.
Events
State changes emit webhook events: escrow.created, escrow.funded, delivery.submitted, verdict.passed, verdict.failed, dispute.opened, dispute.evidence, dispute.resolved, escrow.refunded, and the flagship event, quitanza.issued.