# Why SITEBORNE

The claim is testable: the definition of an acceptable result should remain stable even when protocols, providers, and execution paths change beneath it.

SITEBORNE complements existing infrastructure rather than replacing it. Gateways can govern traffic, runtimes can own retries and recovery, identity systems can authenticate principals, observability systems can measure behavior, and payment rails can move value. SITEBORNE adds contract-defined outcome assurance across those systems.

## Isn't this just another agent gateway?

No. A gateway can govern traffic, access, quotas, and transport. SITEBORNE keeps the acceptance contract stable above those paths and verifies the delivered result against it.

If changing the gateway or protocol changes what “accepted” means, the contract is not invariant.

## Why isn't a successful execution enough?

Execution success says the work ran. It does not prove that the delivered result satisfied the buyer's required claims, evidence, limits, or contract semantics.

SITEBORNE separates execution state from assurance decision.

## Why not let every protocol define its own semantics?

Because independently maintained MCP, A2A, OpenAPI, and Catalog/Registry definitions can drift.

SITEBORNE treats the Verification/Capability Contract as canonical semantic truth and projects that truth deterministically into protocol surfaces.

## Is PCC another authorization token?

No. PCC proves/evidences what happened under the governed result model.

PCC is not identity, permission, payment authority, result-access authority, or settlement authority.

**PCC ≠ permission.**

## Does a payment receipt prove who owns the result?

No. Payment authorization is economic evidence. It does not automatically prove identity or authorize sensitive result retrieval.

Release 3 candidate semantics model `document_evidence_json.v3` and `verify_agent_output.v3` as `BUYER_AUTHORIZED`, keeping result authorization distinct from payment and execution.

**RESULT EXISTENCE ≠ RESULT AUTHORIZATION.**

## Why is settlement separate?

A result can exist, be verified, and carry proof without that proof automatically becoming settlement authority.

**PAYMENT RECEIPT ≠ SETTLEMENT AUTHORITY.**

## Complement positioning

SITEBORNE is designed to sit beside:
- identity and delegated-intent systems;
- API and AI gateways;
- durable runtimes/orchestrators;
- observability systems;
- provider/model infrastructure;
- MCP/A2A/OpenAPI/catalog surfaces;
- payment and settlement rails.

External evidence can satisfy a bound requirement but does not silently become SITEBORNE authority over contract satisfaction.

## Current-state discipline

Current live production remains runtime-authoritative v2. Release 3 (`3.0.0`) is candidate work under pre-release qualification and is not the production default.

See:
- [How it works](how-it-works.md)
- [Developers](developers.md)
- [Pricing](pricing.md)
- [Status](status.md)
- [Trust](security.md)
- `https://utility.siteborne.net/openapi.json`