# How SITEBORNE Works

SITEBORNE separates what must be true from how work is performed.

## Simple mode

1. **Contract** — define the outcome once.
2. **Authority + policy** — decide whether the requested work is allowed under the governed contract.
3. **Execution** — run through an eligible path.
4. **Assurance** — verify the result against the original contract.
5. **PCC** — preserve proof/evidence of what happened.
6. **Result authorization** — for sensitive candidate services, decide whether the caller is authorized to receive the result.
7. **Settlement authority** — complete the economic decision separately from execution, proof, and result access.

A successful workflow is not automatically an accepted result. A payment receipt is not identity. PCC is not permission.

## Technical mode

Release 3 uses the canonical thin-waist model:

`VCM Capability Contract`
→ `Policy + Authority Decision`
→ `Causal Execution State`
→ `Assurance Decision`
→ `PCC two-proof envelope`
→ `Settlement Authority`

Where a service contract requires controlled result disclosure, Release 3 candidate semantics insert governed result authorization between proof production and result release/settlement handling.

**VCM defines what must be true. AVUF determines how to fulfill it. PCC proves what happened.**

### VCM
The current/core canonical semantic contract model. It defines the buyer-facing conditions that must be true without binding those conditions to one provider, protocol, or execution path.

### AVUF
The governed execution/fabric layer that determines how an eligible contract is fulfilled. The full fabric is candidate/evolving rather than a production-wide routing claim.

### PCC
Proof/evidence of what happened. Release 3 candidate work uses a full PCC result envelope with schema `2.0.0`.

PCC is not:
- identity authority;
- payment authority;
- result-access authority;
- settlement authority;
- a permission token.

## Live production versus Release 3

### Current live production
The runtime-authoritative service generation is v2. Current paid production modes are:
- `verify_agent_output.v2` / Verify Standard — `$0.017/request`
- `web_context_verified.v2` / Web Direct — `$0.008/request`

The live runtime/OpenAPI and current quote remain authoritative.

### Release 3 candidate
Candidate families:
- `company_evidence_graph.v3`
- `web_context_verified.v3`
- `document_evidence_json.v3`
- `verify_agent_output.v3`

Service Contract `3.0.0`, PCC schema `2.0.0`, and buyer-authorized result handling for `document_evidence_json.v3` and `verify_agent_output.v3` are candidate semantics under pre-release qualification, not the production default.

## Authority separation

SITEBORNE distinguishes:
- identity;
- mandate;
- policy;
- payment authorization;
- execution authority;
- result authorization;
- proof/evidence;
- settlement authority.

Therefore:
- `RESULT EXISTENCE != RESULT AUTHORIZATION`
- `PAYMENT RECEIPT != SETTLEMENT AUTHORITY`
- `PCC != PERMISSION`
- `SUPPLIER CAPABILITY != QUALIFICATION`
- `PAYMENT != IDENTITY`
- `EXECUTION SUCCESS != CONTRACT SATISFACTION`

## Protocol projections

One canonical semantic truth projects into MCP, A2A / Agent Card, OpenAPI, and Catalog / Registry. Release 3 candidate projections remain separately labeled CANDIDATE or QUALIFYING until activation and read-back prove production convergence.

For exact current executable behavior, use `https://utility.siteborne.net/`.


## Governing architecture update

Current **GOVERNING DESIGN** further separates `AuthorityGrant → ExecutionLease + fencing → CommitGrant where required → Assurance → FinalPccDocument → Result Authorization + ResultBinding → Settlement Authority + SettlementGrant`. This design context is not a production-deployment claim; fresh repository/runtime evidence remains required for implementation state.