01 / CONTRACT
Define what must be true.
VCM defines the outcome, claims, evidence requirements, constraints, and acceptance conditions once. Protocol metadata is a deterministic projection of this contract—not a competing semantic authority.
Product / How it works
Define the outcome once. Govern execution. Verify before you accept.
A buyer defines the outcome once. SITEBORNE carries that contract across compatible systems, governs the operation, verifies the returned result, preserves proof, and keeps result access and settlement as separate decisions.
Release 3 candidate semantics use the public thin waist: VCM Capability Contract → Policy + Authority Decision → Causal Execution State → Assurance Decision → PCC two-proof envelope → Result Authorization → Settlement Authority. The governing architecture further separates AuthorityGrant, ExecutionLease/fencing, CommitGrant where required, FinalPccDocument, ResultBinding, and SettlementGrant; those names describe governing design unless repository/runtime evidence promotes their implementation state. The production runtime remains authoritative for what is live.
02 / AUTHORITY + POLICY
Decide whether governed execution may proceed.
Identity, mandate, policy, payment authorization, and execution authority are distinct inputs. Release 3 candidate work makes this separation explicit before execution.
03 / EXECUTION
Run under governed authority.
AVUF is the governed fulfillment fabric: it determines how an eligible contract is fulfilled across qualified BUILD / BUY / BROKER / COMPOSE paths without changing the contract itself.
04 / ASSURANCE
Verify what actually happened.
Assurance evaluates the delivered result and evidence against the contract. A successful provider or tool invocation is not automatically a successful contract outcome.
05 / PCC
Preserve a proof-carrying result.
Release 3 candidate PCC uses a full result envelope (schema 2.0.0) to record what happened. PCC is evidence; it is not identity, permission, result-access authority, payment authority, or settlement authority.
06 / RESULT AUTHORIZATION
Authorize sensitive result handling separately.
Public services can return contract-governed output. In the Release 3 candidate, sensitive document and verification results use buyer-authorized semantics. Payment or execution alone does not authorize result retrieval.
07 / SETTLEMENT AUTHORITY
Complete the economic path independently.
Settlement eligibility remains a separate governed decision. A payment receipt is economic evidence; it does not become identity, PCC, result authorization, or settlement authority.
Release-state discipline: production remains v2 and runtime-authoritative. Release 3 / Service Contract 3.0.0 and PCC schema 2.0.0 are candidate state and are not the production default.
What changes with SITEBORNE
A successful call is useful.
A successful call is useful.
A contract tells you whether the job was actually done.
The examples below show the extra questions SITEBORNE makes explicit: what counted as success, whether the result met it, and when completion can safely move forward.
These examples reflect the Release 3 authority model while keeping production activation separate. Candidate AVUF, result-authorization, and PCC 2.0.0 semantics must not be read as current live-v2 activation.
COMMON SUCCESS SIGNALtransport / provider
Request→Provider→200 / success
Did the returned result satisfy the buyer's actual acceptance conditions?
Not established by the success code alone.
SITEBORNE OUTCOME PATHcontract / assurance
Contract→Qualified path→Assure→Accepted result
Did the result meet the conditions defined before execution?
The completion decision is evaluated against the contract and evidence.
Change the path.
Keep the promise.
A buyer asks for one bounded outcome. Release 3 candidate AVUF semantics can choose among eligible fulfillment paths without silently changing what the buyer agreed to receive.
Provider A↘ONE CONTRACT↗Provider B
AVUF is candidate/evolving fulfillment architecture; production activation still follows live runtime state.
“It ran” can still
mean “reject.”
An agent can return a syntactically valid result and still miss required evidence or claims. SITEBORNE separates execution success from contract satisfaction.
EXECUTION SUCCESS≠CONTRACT ACCEPTED
This distinction is part of the public security/economic model.
Authorize spending.
Do not confuse it with proof.
Payment evidence can admit a paid operation without becoming identity, execution authority, or proof that the result satisfied the contract.
AUTH→WORK→ASSURE→SETTLE
Exact settlement behavior depends on the admitted runtime contract and rail.
THE PRACTICAL DIFFERENCE
Normal infrastructure can tell you that work happened. SITEBORNE adds a governed definition of what acceptable completion means—and evidence for evaluating it.
Architecture role index
Each badge is a different responsibility.
Keeping these roles distinct is part of the product contract.
Verification Contract / VCM
Canonical capability contract: defines what must be true.
CORESecurity Authority
Policy + authority decision boundary; evidence does not silently become permission.
CANDIDATE MODELAVUF
Governed fulfillment across qualified BUILD / BUY / BROKER / COMPOSE paths.
CANDIDATE / EVOLVINGAssurance
Contract-specific assurance decision over result and evidence.
COREPCC
Full proof-carrying result envelope in Release 3 candidate; evidence, not permission.
R3 CANDIDATE · 2.0.0Result Authorization
Governed result-release decision; buyer-authorized semantics for sensitive candidate services.
R3 CANDIDATESettlement Authority
Economic completion authority remains distinct from execution, proof, and result access.
SEPARATE AUTHORITYEvidence Graph
Durable contract-specific evidence accumulation.
DESIGNRAVI-P
Future provider/reliability intelligence.
ROADMAP