SITEBORNE · PRODUCT / ASSURANCEOne Contract.
One Contract.
Any Platform.
Verified Outcomes.
Define the outcome once. Keep it stable across the stack. SITEBORNE carries that contract across compatible execution systems, verifies the result, preserves proof, and keeps permission and settlement separate from merely producing an answer.
The contract and assurance layer for autonomous systems. VCM defines what must be true. AVUF determines how an eligible contract is fulfilled. Assurance verifies the result, PCC proves what happened, and result authorization and settlement remain separate governed decisions.
01One Contract
→
02Any Platform
→
03Verified Outcomes
Verification ContractsPCCMCPA2AOpenAPIx402LIVE · V2RELEASE 3 · CANDIDATE
SEMANTIC CORE // VCMPROTOCOL-NEUTRAL
MCPtool surface
A2Aagent surface
OpenAPIAPI surface
x402economic rail
ONE SEMANTIC SOURCECONTRACT → VERIFY → PROVE
CURRENT SURFACE · PRODUCT / HOME
Understand the product. Inspect the contract when you are ready.
Network identity lives on siteborne.net. Runtime truth lives on utility.siteborne.net.
Interoperability context
Platforms, protocols, and payment methods can change beneath the contract. These labels show ecosystem context—not partnership, endorsement, or universal production support.
Platforms and adapters remain replaceable beneath the Verification Contract. Ecosystem/reference labels describe interoperability context only; they do not confer qualification, authority, partnership, endorsement, or universal production support.
AWS AgentCoreREFERENCE
MicrosoftECOSYSTEM
GoogleECOSYSTEM
CloudflareREFERENCE
OpenAIECOSYSTEM
TemporalROADMAP
ApifyREFERENCE TARGET
MCPPROTOCOL
A2APROTOCOL
OpenAPIPROTOCOL
x402PAYMENT RAIL
AWS AgentCoreREFERENCE
MicrosoftECOSYSTEM
GoogleECOSYSTEM
CloudflareREFERENCE
OpenAIECOSYSTEM
TemporalROADMAP
ApifyREFERENCE TARGET
MCPPROTOCOL
A2APROTOCOL
OpenAPIPROTOCOL
x402PAYMENT RAIL
The simple version
Tell the network what counts as done.
Tell the network what counts as done.
Keep that meaning stable.
Tell SITEBORNE what must be true when the job is done. The systems underneath can change without changing that agreement.
The buyer-facing contract remains canonical while protocol projections, qualified execution paths, assurance, replay, and economic state remain separate but coherent.
15-second model
One semantic contract above many machine paths.
The network keeps the job definition stable while execution, protocols, and providers remain replaceable beneath it.
SITEBORNEcontract · authority · assuranceRESULTOutcome + evidence + governed completion state
Define the outcome.
State what must be delivered, what evidence is required, and what counts as acceptable completion.
Run a qualified path.
Technology underneath can change without changing what the buyer agreed should count as success.
Verify before acceptance.
Evaluate what actually happened, preserve evidence, and keep payment/result authority separate.
The rule:Buy the outcome contract, not a provider-specific call.
Concrete example
An agent says the job is finished.
An agent says the job is finished.
What proves that?
A task is not accepted just because software says it finished. The result still has to match the agreed facts and evidence.
Execution success is not contract satisfaction. The operation, evidence, result, decision, replay state, and economic state must remain independently attributable.
THE REQUEST
“Research this company, return the evidence, and only deliver a result if it satisfies the stated requirements.”
Bind the contractDefine exact outcome + evidence expectations.
Check authorityRequest, execution, and payment authority stay distinct.
ExecuteUse a qualified path without changing the contract.
VerifyEvaluate claims against admissible evidence.
Seal + replayPreserve the accepted body, proof, and economic lineage.
NOT ENOUGH“The API returned 200 OK.”
→THE GOAL“The delivered outcome satisfied the Verification Contract.”
Independent observation
Signals that refresh outside our own site.
Check independent uptime and protocol observations, then inspect the runtime for what is actually executable now.
Independent observers provide protocol and availability evidence; runtime endpoints and governed release metadata remain authoritative for execution-specific state.
INDEPENDENT · POSITIVE OBSERVED SIGNALS
Evidence snapshot →
Agenstry uptimepositive live signal ↗
A2A protocolproven support ↗
MCP protocol erameasured support ↗
Small Printregistry record · 0 advisories observed · 2026-09-24 sweep ↗
AgenstryA2A live probe + uptime methodology ↗
MCPMetricsMCP uptime + protocol measurements ↗
LIVE OBSERVATIONuptime and protocol support refresh outside SITEBORNE
SOURCE CONTEXTinspect the external profile for methodology and changing details
RUNTIME AUTHORITYlive execution state remains authoritative at utility.siteborne.net
These signals are served by the observers themselves and can change independently. Follow any badge to inspect the source record and methodology.
SITEBORNE · AUTHORITATIVE MACHINE REFERENCES
One semantic release
Independent evidence ≠ authority. External observation can increase confidence; it cannot redefine a contract, authorize execution, release a result, or settle an operation.
Signature interaction
One contract stays fixed.
One contract stays fixed.
The execution path can change.
Pick a different machine path below. The route can change while the definition of a successful result stays the same.
Switch among public protocol projections while the Verification Contract remains the semantic anchor. Execution, evidence, proof, result authorization, and economic completion remain distinct layers.
STABLE BUYER-FACING CONTRACT
Outcome · claims · evidence · limits · acceptance
CONTRACT FIXED
REPLACEABLE PATH
CONVERGENCE
01 Execute
02 Assure
03 Prove
04 Accept
RETURNED UP
Verified outcome
accepted against the same contract
End-to-end proof path
From discovery
From discovery
to governed completion.
A request moves through eight distinct responsibilities: discover the surface, define success, authorize the work, execute, verify, preserve proof, authorize sensitive result access, and keep settlement authority separate.
Why it mattersAgents can act.
Agents can act.
Assurance must keep up.
Every platform has different semantics.
Tools, identity, payment, success, and proof can mean different things on each surface.
A successful call can still be a failed outcome.
Execution correctness and contract satisfaction are different questions.
Money can move before trust is earned.
Payment proves that money was authorized or moved. It does not prove the work was correct or approved.
One Verification Contract sits above the stack.
Switch platforms or providers without rewriting what a successful outcome means.
Where it becomes usefulDifferent outcomes.
Different outcomes.
One assurance pattern.
Bounded web evidence
Gather source-backed evidence, then check the result against the agreed requirements.
Agent-to-agent work
Delegate without treating identity, payment, or agent metadata as blanket authority.
Structured evidence
Convert bounded documents into traceable evidence without making the parser or provider canonical authority.
Paid autonomous utilities
Lock the price to the request, authorize payment, run the work, verify the outcome, and keep a clear payment record.
One definition of success, available through the interfaces your systems already use.
Verification Contractwhat acceptable means
Qualified executionbounded operation
PCCportable evidence
Economic completionseparate authority
The modelAutonomous execution is easy to start.
Autonomous execution is easy to start.
Acceptance needs a contract.
Running successfully is not the same as being correct. SITEBORNE separates the work, the check, the evidence, acceptance, and payment.
Define
Define the result you want, what must be true, what evidence is needed, and what counts as acceptable.
Execute
Run the work only through an approved path and within the agreed spending limit.
Verify
Check what actually happened against the requirements agreed up front.
Prove
Package result identity, evidence, decision material, and signed receipt into portable proof.
Complete
Accept the result and complete payment only when the right checks and approvals have passed.
Three-surface model
Unified Semantic System.
Unified Semantic System.
Three public roles.
Use siteborne.com to understand the product, siteborne.net to inspect shared machine definitions, and utility.siteborne.net to execute what is live.
The public model separates product/developer, machine-network, and runtime responsibilities while keeping VCM and governed release metadata as the shared semantic source. No surface independently redefines capability meaning, schemas, pricing, security semantics, or result contracts.
PRODUCT + DEVELOPERS
HUMAN / PRODUCT
siteborne.com
Explain the product, evaluate trust, understand pricing, and find the right developer entry point.
Product/developer authority: product narrative, architecture explanation, trust, pricing/status, legal surfaces, developer quickstarts, and integration examples.
explainevaluatetrust
You are here · Product
MACHINE-FIRST NETWORK
NETWORK / DISCOVERY
siteborne.net
Give machines, registries, and evaluators a compact identity surface for releases, contracts, schemas, protocol metadata, and network discovery.
Machine-network authority: network identity, release manifests, capability catalog, versioned contracts/schemas, protocol projections, compatibility, and machine-readable references. It performs no service execution.
discoverinspectintegrate
Inspect Network surface ↗
MACHINE RUNTIME
RUNTIME / MACHINE
utility.siteborne.net
Inspect exact executable state and invoke admitted machine operations through the runtime interfaces.
Executable runtime authority: exact route admission, current schemas/economics/security declarations, governed execution, assurance/PCC generation, and runtime settlement behavior for capabilities that are actually admitted.
executeverifyreplay
Inspect Runtime surface ↗
UNIFIED SEMANTIC SYSTEMVCM + governed release
One Contract → Any Platform → Verified Outcomes.
Protocols and payment rails are projections/adapters; metadata is not executable authority.
MCPPROJECTION
A2APROJECTION
OpenAPIPROJECTION
JSON SchemaCONTRACT SURFACE
x402RAIL ADAPTER
MPPROADMAP
OAuth / OIDCEVIDENCE ADAPTER
SDKsDESIGN
Release manifestDESIGN
Use Product to understand the value, Network to inspect the shared definitions, and Runtime to execute. Status shows what is available now.
Standards & machine surfaces
Recognizable interfaces.
Recognizable interfaces.
One governed meaning.
Use familiar interfaces without creating a different definition of success for each one.
MCP, A2A, OpenAPI, JSON Schema, HTTP, and payment rails are protocol/transport projections around governed contract semantics. Lifecycle labels describe SITEBORNE state and relationship, not external endorsement.
⌁MCPModel Context ProtocolPUBLIC SURFACE
A2AAgent2Agentagent interoperabilityPUBLIC SURFACE
OASOpenAPIHTTP contract projectionPUBLIC SURFACE
402x402internet-native payment railQUALIFIED PATH
HTTPHTTPtransport substrateFOUNDATION
{ }JSON Schemamachine validation vocabularyCONTRACT SUPPORT
LIVE / QUALIFIEDDESIGN / DEFINEDROADMAPWATCH / ADAPTER
Verification ContractCanonical meaning
The job description machines can verify.
A Verification Contract describes acceptable completion without making a specific platform the source of truth.
OUTCOMEexplicit desired result
CLAIMSfacts that must be established
EVIDENCEwhat may support those claims
DECISIONconditions for acceptance
ECONOMICSgoverned quote / completion context
Conceptual public projection — not the private canonical schema.
Proof-Carrying ContextPCC
Proof travels with the outcome.
PCC is the proof package that shows what was requested, what evidence supported the result, and what decision was reached. Proof supports a decision; it does not grant permission.
Contract identityWHAT WAS AGREED
Claims + evidenceWHAT SUPPORTS IT
Decision materialWHAT WAS VERIFIED
Service resultWHAT EXECUTED
Signed receiptDURABLE PROOF
Architecture
The Utility Network is a chain of authorities,
The Utility Network is a chain of authorities,
not one magical box.
Each part of the network has one job. No badge or subsystem silently gets authority it was never given.
Verification Contract / VCM
Canonical capability contract: defines what must be true.
CORESecurity Authority
Separates identity, mandate, policy, payment, and execution authority decisions from evidence.
CANDIDATE MODELAVUF
Governed fulfillment across qualified BUILD / BUY / BROKER / COMPOSE paths.
CANDIDATE / EVOLVINGAssurance
Contract-specific verification over result claims and evidence.
COREProof-Carrying Context
Production v2 returns proof material today. Release 3 candidate advances PCC to a full result envelope with schema 2.0.0. Proof still does not grant permission.
LIVE V2 + R3 CANDIDATEResult Authorization
Separate governed decision for releasing sensitive results; buyer-authorized semantics in the Release 3 candidate.
R3 CANDIDATESettlement Authority
Complete payment once, without retries silently creating duplicate charges.
SEPARATE AUTHORITYEvidence Graph
Contract-specific operational evidence feeding future qualification intelligence.
DESIGNRAVI-P
Provider/reliability intelligence derived from accumulated evidence.
ROADMAPWHO ASKSHumans · organizations · apps · autonomous agents
↓
INTERFACESMCP · A2A · OpenAPI · SDK / HTTP
↓
SITEBORNEVCM → authority → AVUF → assurance → PCC → result authorization → settlementEXECUTION / SUPPLYclouds · APIs · models · MCP tools · A2A agents · native services
↓
EVIDENCE LOOPdurable result identity · replay · evidence graph · future RAVI-P
Standards horizon
Adopt standards where they reduce proprietary surface area.
Use established standards where they make integration easier. WATCH and ROADMAP items show direction, not features you can use today.
OAuth 2.0 / OIDCAUTHENTICATION EVIDENCE · STANDARD
DPoPPROOF OF POSSESSION · ADAPTER
mTLSTRANSPORT AUTH · ADAPTER
HTTP Message SignaturesREQUEST INTEGRITY · WATCH
AuthZENPOLICY API · PRIORITY
OPA / CedarPOLICY ECOSYSTEM · ADAPTER
MCP EMA / ID-JAGIDENTITY / AUTHORITY · ROADMAP
OWASP ACSRUNTIME HOOKS · ROADMAP
WIMSE / SPIFFEWORKLOAD IDENTITY · WATCH
CAEP / Shared SignalsSECURITY EVENTS · WATCH
RATSATTESTATION · WATCH
AP2 / Verifiable IntentDELEGATED INTENT · WATCH
MCP RegistryDISCOVERY · ECOSYSTEM
A2A Agent CardDISCOVERY · PUBLIC SURFACE
DNS-AIDDISCOVERY · WATCH
ANSAGENT IDENTITY / DISCOVERY · WATCH
OpenTelemetryOBSERVABILITY · PREFERRED
OCSFSECURITY TELEMETRY · WHERE FIT
SCITTPORTABLE AUDIT · WATCH
Sigstore-style bundlesPORTABLE PROOF · WATCH
C2PACONTENT PROVENANCE · ADAPTER
MPPPAYMENT RAIL · ROADMAP
WCAG 2.2 AAPUBLIC UI TARGET · NOT A CONFORMANCE CLAIM
One semantic source. Multiple surfaces.Build against the contract,
Build against the contract,
not the platform.
MCP, A2A, OpenAPI, and economic rails are projections around the same governed meaning. They should not become competing sources of truth.
MCP
MCP
Machine-callable tool surface for agents and clients.
A2A
A2A
A standard way for agents and systems to discover compatible capabilities.
API
OpenAPI
Explicit HTTP contracts for direct integrations and SDK generation.
402
x402
Payment rules stay separate from proof that the work was correct and permission to perform it.
Trust boundaries
Proof, authority, and payment are different things.
SITEBORNE does not treat metadata, payment, or model output as silent authority. Identity, request authentication, delegated intent, execution authority, verification proof, result authorization, and settlement authority remain distinct.
Identity, authentication, delegated intent, execution authority, verification proof, result authorization, payment authorization, and settlement authority remain separate decision domains. Metadata, payment evidence, and model output cannot silently promote themselves into authority.
Inspect the trust modelrequest authority≠payment authority
execution authority≠verification proof
verification proof≠result authority
result authority≠settlement authority
Trust & safety modelThe rules stay explicit
The rules stay explicit
even when the system is complex.
Paying is not permission.
A payment can fund work without granting broader execution or result authority.
Identity is not permission.
Knowing who or what made a request does not itself authorize the requested action.
Tool output is not authority.
Pages, documents, tools, models, and metadata are data, not self-granting control planes.
Success is not proof.
An execution success code does not prove contract satisfaction.
Providers must qualify.
Discovery does not automatically make a supplier acceptable for a specific contract.
Unsafe paths fail closed.
SITEBORNE does not invent permission or lower required checks just to produce a result.
NON-NEGOTIABLERules may become stricter as risk increases. They may not silently become weaker.
Utility NetworkSmall utilities. Explicit contracts.
Small utilities. Explicit contracts.
Observable state.
This site explains the product. The runtime is the source for current availability, request-specific pricing, and execution details.
Verify Standard
Verify outcomes against agreed requirements, keep the evidence, and bind payment to the same request.
Web Direct
Direct web-oriented utility execution under the same contract/economic separation model.
Document Evidence
Structured, traceable document evidence utility from the earlier public catalog.
Company Evidence
Multi-source company evidence utility retained as a known disabled capability.
Rendered Web
Rendered-web acquisition capability retained as a known disabled service.
Independent Reproduction
Independent reproduction/verification capability retained as a known disabled service.
Economic completionWhat was bought matters more than
What was bought matters more than
which rail moved the money.
What you bought stays separate from how you paid. A successful payment does not prove the result was correct.
x402
The verified Release-1 paid canary used the current machine-to-machine payment path for Verify Standard.
MPP
Support more machine-payment options without making any one payment rail define the product.
Other rails
Future qualified payment methods can fit behind the same economic model if they preserve authority and replay invariants.
RoadmapExpanding the network
Expanding the network
without weakening the contract.
New providers, protocols, and payment options can be added without changing what the customer originally asked to count as success.
Seal the full proof package
Make accepted results carry enough portable proof for another system to verify what happened.
Make replay reliably identical
Retrieve the same accepted result later without changing its meaning, evidence, or payment record.
Strengthen delegated authority
Support more complex delegated work without mixing up identity, permission, acceptance, and payment.
Converge every interface
Every supported interface should describe the same requested outcome and acceptance rules.
Publish one governed release
Update contracts, interfaces, pricing, trust information, and status together so customers and machines see the same story.
Grow qualified reach
Add integrations and payment options only when they preserve the same buyer agreement and verification expectations.
The promiseMore reach. Same contract.
The network can grow without making buyers relearn what success means.
Protocol and provider expansion stays subordinate to the canonical contract and governed release model.
EXPANDSinterfaces · qualified paths · SDKs · economic rails
STAYS FIXEDbuyer-visible contract meaning
GROWSportable proof · replay · release parity
Every machine interface should describe the same outcome in the same way.
# MCP
surface: "Remote Streamable HTTP"
namespace: "net.siteborne/utility"
contract_source: "Verification Contract"
result_proof: "PCC"
# Runtime origin
https://utility.siteborne.net
Machine-readable outside. Proprietary inside.
Publish what customers and integrators need to understand behavior, status, errors, replay, and evidence while keeping private security and competitive internals private.
MCPA2AHTTPOpenAPIJSON Schemasigned metadatacaller-bound resultsdurable replayx402payment-aware discovery
The site itself is part of the contract surface.
Public website, machine metadata, schemas, examples, runtime status, and discovery files should tell the same story.
MANIFEST/machine-manifest.json
LLM DISCOVERY/llms.txt
INDEXING/sitemap.xml + robots.txt
RUNTIMEutility.siteborne.net
FAQ
If you remember only five things.
What does SITEBORNE do in one sentence?
It helps autonomous systems agree on what success means, run through approved paths, verify the outcome, keep evidence, and complete payment under clear rules.
Is SITEBORNE another AI agent or gateway?
No. It is infrastructure for defining, verifying, and proving autonomous work across different systems and payment paths.
Does SITEBORNE replace AWS, Microsoft, Google, Cloudflare, OpenAI, or Temporal?
No. Those platforms can keep doing what they do best. SITEBORNE keeps the definition of a successful outcome stable across them.
Why isn't PCC just a signed receipt?
PCC packages the request, evidence, result, and decision record. A signature can protect that record from tampering, but it does not by itself prove the work met the agreement or grant permission.
Is every illustrated capability live?
No. Clear state labels show what is production, candidate, qualifying, watched, or disabled. Runtime and Status remain the source for current availability.
SITEBORNE Utility NetworkAsk for the outcome.
Ask for the outcome.
Let the stack stay flexible.
Define success once. Run through an approved path. Verify before accepting the result.
SITEBORNE Utility NetworkInfrastructure for autonomous systems that need results they can verify.
One Contract. Any Platform. Verified Outcomes.