# Curbi ontology

Version 4 · 9 November 2026. This is the current product contract. The mission is to make agent actions independently provable without relying on the agent’s own account.

**Curbi turns agent claims into checkable evidence.**

**Rules for what AI says. Evidence for what it does.**

Curbi is deterministic AI policy infrastructure. The enforcement design puts the gate at the state-change boundary in a covered harness. Plan → Admit → Budget → Act → Review separates the proposal, authority, execution and evidence. The checker runs without model inference and is MIT-licensed.

Agents can propose actions and announce success. Businesses need to establish what was authorized, what actually happened and what evidence supports the answer. A fluent reply is not a provider record. A well-formed payload is not authorization. A valid signature is not proof that every statement inside it is true.

## The shared chain

Principal → grant → proposed action → enforced decision → provider outcome → signed statement → independent verification → regression.

| Entity | Meaning and boundary |
| --- | --- |
| Principal | Authenticated human or agent identity in a tenant/account context. A role label, prompt or model name does not create authority. |
| Grant | Authority issued by a trusted principal for specified operations, resources, amounts, currencies, expiry and policy version. The caller cannot widen it by supplying different policy text. |
| Proposed action | The exact operation and arguments the agent wants executed, bound to tenant, account, resource, subject and operation identity. |
| Enforced decision | An executor's admission or refusal of that exact proposal against a pinned grant and policy. Protection requires that the agent cannot bypass the enforcing executor. |
| Provider outcome | Evidence obtained through an authenticated provider adapter. Timeout, incomplete readback or ambiguous state is UNKNOWN, not success or safe-to-retry failure. |
| Signed statement | An identified issuer's signature over a precisely scoped statement and bindings. It establishes integrity and issuer attribution under the verifier's trust policy; it does not make unsupported facts true. |
| Independent verification | A verifier checking the statement against caller-selected trusted keys, validity/revocation rules, bindings and applicable log proofs. Embedded metadata does not mint trust. Verification is independent computation, not an independent observation of the provider. |
| Regression | A retained failure with explicit inputs and expected results that can be replayed in CI. A test pins covered behavior, not universal correctness. |

## Three questions, three mechanisms

1. **Does this claim violate configured rules?** The deterministic checker evaluates supported prices, phrases and action claims against supplied policy and records. It makes no model calls. A pass means no configured rule fired. Caller-supplied records remain unverified unless explicitly accepted through a supported verification path.
2. **Was this exact action authorized?** Grant verification plus enforcement at the executor answers this. A checker result, schema validation or signature alone does not authorize execution.
3. **What actually happened?** Authenticated provider reconciliation supports an outcome statement. A valid receipt signature by itself cannot establish provider truth independently of its issuer and adapter.

The public checker's pass result grants no execution authority. Its default replay scope is within the request, not a global exactly-once promise. Receipt verification and text checking are distinct operations, even where an API composes them.

## What is available

| Surface | Availability | What Curbi checks |
| --- | --- | --- |
| Browser | Chrome Web Store v0.2.2 | Selected or pasted replies, locally and when requested. Always-on connection and hosted covered-tool dispatch are separate release work. |
| Terminal | Curbi CLI in development | The public API can be called from a terminal today. No CLI installation is offered. |
| Desktop | Early desktop app | Separate release surface. Availability here does not imply action interception. |
| MCP and API | Public Check API v1 and six read-only MCP tools | Configured reply checks, lint, regression export, offline bundle verification and documentation retrieval. Managed API access adds metering, usage counters, lowerable limits and available record export. |

The public decision adapter is available as source. It validates supported typed inputs and outputs against explicit rules. A model score or confidence value is not evidence of authorization or calibrated accuracy. Package availability and channel support are tracked separately.

Proof of Action Protocol (PAP) specifies the evidence contract for action receipts. Test-key examples and hosted TEST qualification use explicit test trust. Production signing is off. Provider reconciliation in TEST establishes only the scoped test outcome. The input gate is a tested library pending durable host integration. Deterministic input checks cover provenance, state consistency and scope authorization. The host must bind the checked context to the exact dispatch. Raw model calls and unrelated tools are outside a covered harness.

Local tools, the offline verifier, templates and rate-limited public checks are free. A free TEST key allows 20 replies. Managed checks cost $1 per 1,000 completed replies, or $0.001 per reply. Current-key and shared-customer ceilings both apply. Paginated export includes available unsigned check metadata. It excludes raw replies and policies. History search, shared workspaces, scheduled checks and retention guarantees are outside the current paid offer.

[Chrome and setup](https://curbi.io/connect/#install-free) · [Check API](https://curbi.io/api/) · [MCP workbench](https://curbi.io/mcp/) · [Support matrix](https://curbi.io/connect/#client-support) · [Pricing](https://curbi.io/pricing/)

Release-specific evidence belongs to an exact source SHA, deployed status and qualification report. A build pass does not establish provider completion.

## Failure and recovery invariants

- Missing or invalid authority refuses execution. Validation does not silently widen a grant.
- The exact operation identity binds the request and retry history. A different amount, currency, account, tenant or resource is a different binding, not an innocent retry.
- Dispatch is durably recorded before provider I/O. Ambiguous dispatch remains UNKNOWN and consumes its reserved allowance.
- Reconciliation reads provider state; it does not issue a second create because the first response was lost.
- No completion receipt is issued for UNKNOWN. Provider confirmation, receipt signing and ledger commitment remain separate states so recovery cannot invent completion.
- Historical evidence and trust metadata must remain exportable and independently checkable under explicitly documented access and key-lifecycle rules.

## Distribution and economics

The browser extension is the first-use path for browser users. The planned CLI serves that role on the terminal. The local checker, GitHub Action and framework packages give developers more ways to try and keep a check. Durable differentiation comes from provider-confirmed reconciliation, a durable ledger, consented real failure examples and independent trust. These are distinct from the distribution surfaces and their current release states.

Do not claim that all guardrails are formatting checks, that all semantic checks are useless, or that another model necessarily doubles a customer's bill. Semantic evaluation and deterministic enforcement solve different problems. Do not publish universal microsecond latency, savings, gross margins, adoption totals or exclusivity claims without measurements and methods. A workload multiplied by a price is a scenario, not revenue evidence.

WebMCP is one harness type. The integration map groups Frameworks, Harness, Model, Sandbox, Tools and Knowledge. Model, wire and client availability are separate. MCP exposes callable tools. Provider outcome and executor authority each require their own evidence. Curbi does not route model requests, replace model safeguards, supply general cybersecurity controls or offer insurance.

## The decisive demonstration

A grant permits a $50 sandbox refund. An over-limit request is refused. An allowed request loses its response. A retry after restart reconciles the original operation without a second refund. Only authenticated confirmation permits a bound statement and offline-verifiable bundle. Altered amount, account, policy version or evidence fails. UNKNOWN produces no completion receipt. Every observed failure becomes a regression.

A real Stripe test-mode qualification now demonstrates this recovery boundary locally with a 50-cent refund, persistent SQLite, one refund POST and offline-verifiable evidence. See [the qualification report](https://curbi.io/docs/provider-confirmation.md). Hosted qualification, live-money execution and production signing remain separate gates; the local run does not satisfy them.

## Try a configured check

This public example checks a reply against a configured price; it does not authorize an action or establish a provider outcome.

```sh
curl -sS https://api.curbi.io/v1/check \
  -H 'Content-Type: application/json' \
  -d '{"policy":{"prices":[{"item":"Starter","amount":49}]},"reply":"Starter is $99."}'
```

Expect `pass: false` with `price:mismatch`.

Next: [install a framework adapter](https://curbi.io/connect/) or [start with a working policy](https://curbi.io/policies/).