Start here
How Cairva works
Requests, quotes, agreements and allocations: the four objects every deal moves through, and who can see each one.
Every deal on Cairva moves through four objects. Each one has a short reference you'll see across the workspace, its own states, and a clear owner.
| Object | Reference | Created when | Owned by |
|---|---|---|---|
| Request | RFQ-… | A buyer drafts what they need | Buyer |
| Deal and quote versions | DEAL-… | A supplier opens a deal room on a request | Both parties |
| Agreement | AGR-… | The buyer accepts one supplier-issued version | Both parties |
| Allocation | ALC-… | The agreement is created, then activated | Buyer uses it, supplier delivers it |
Request
The buyer describes the model, input and output tokens, delivery window, capacity class, rate limits, region and anything else that matters, such as latency class, privacy requirements or a budget. They send it to the verified suppliers they pick. A request created from a market lot automatically includes that lot's supplier.
A request is visible to the buyer, the invited suppliers and Cairva operations, and nobody else. Drafts stay private to the buyer until they're sent. Details: Requests and quotes.
Quote and negotiation
An invited supplier opens a private deal room on the request. They can message the buyer, then issue a firm quote built from one of their active inventory lots. Cairva checks the terms fit inside that lot: same model and capacity class, window inside the lot's window, limits the lot can enforce, region and enough unreserved capacity.
Either side can counter. Every proposal is a new, immutable, numbered version with the complete terms and a SHA-256 hash of them. Details: Negotiation.
Agreement
The buyer accepts one specific supplier-issued version by echoing its number and terms hash. In the same transaction Cairva reserves the capacity on the lot, creates the agreement, and creates an allocation in the reserved state. Other open quotes on the request close.
The supplier countersigns. A live agreement then waits for payment against an invoice, confirmed by Cairva operations. A sandbox agreement skips payment. Activation checks run, and when they all pass the agreement becomes active. Details: Agreements.
Allocation
The allocation is the agreement in its runnable form: the contracted input and output tokens, the delivery window and three rate limits. The buyer creates API keys against it and calls the gateway. Every request is metered against it, and the buyer and supplier see the same usage events.
It ends when the allowance is used up (depleted), the window closes (expired), or it's terminated. Details: Allocations.
What's recorded
Every state change on a request, quote, agreement, allocation, key, lot or supplier writes an audit event with who made it and when. The agreement page shows its own history to both parties.
Who Cairva is in the deal
Cairva runs the marketplace and the gateway. It verifies suppliers, reviews inventory lots, confirms payments, reconciles usage that a provider didn't report inline, and handles disputes. The first-party supplier you'll see today, Cairva Supply Desk, is Cairva's own supply operation and serves the sandbox route.