Subjects & Events

The record changes by events, and every changeable thing is a subject with a stable id. Read a subject's current state from its snapshot; follow its changes over the event rail.

The universal snapshot

Every subject — a deal, a party, a document, a connection, a Mandate — resolves through one primitive:

curl 'https://apis.vin/deal_7Qm2xK…'

The snapshot is the subject's composed current state, negotiated by content type like the record, and it names its own kind. Ids are typed by prefix, so you know what a subject is before you dereference it.

Events

Every capability that changes the record emits a past-tense, versioned event on success: Subject.pastTenseVerb@version — Deal.opened@1, Payment.settled@1, Title.verified@1. The name is closed-vocabulary; the payload carries pointers and receipts, never PII or artifact bodies. The catalog declares each capability's emits[], and the event registry is the generated union of all of them — 307 event types today.

Following the record

Two rails, same events:

The webhook rail is durable:

• Signed deliveries — an HMAC signature over timestamp.body, with a replay window, so a receiver can prove a delivery is genuine and fresh.
• An echo inbox — every delivery is recorded and queryable, so you can audit what was sent.
• Ordered resend — replay by id or by window, delivered one at a time, so a receiver that was down can catch up without gaps or reordering.
• A retry ladder — redelivery backs off on failure rather than dropping.

Replay

Because the record is event-sourced, a subject's history is not a log to trust — it is the source. Replay a subject from its events to reconstruct any past state, or subscribe from a cursor to stream only what you have not seen. An act-minted fact on the record points back at the event that minted it, so any claim walks back to its cause.

Next

• The event registry — every event, and what emits it.
• The act — the gate an emitting write passes first.
• The catalog — each capability's declared emits[].