# 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`.