# How Cairva works

> Requests, quotes, agreements and allocations: the four objects every deal moves through, and who can see each one.

Source: https://cairva.xyz/docs/how-cairva-works

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](https://cairva.xyz/docs/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](https://cairva.xyz/docs/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](https://cairva.xyz/docs/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](https://cairva.xyz/docs/chat-completions). 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](https://cairva.xyz/docs/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.