Gateways, runtimes, identity systems, providers, and payment rails can stay excellent at their own jobs. SITEBORNE adds the contract and assurance boundary that defines what successful completion means—and how to prove it.
Each objection below has a public answer, a way to test the claim, and a place where the surrounding platform remains useful.
Keep your gateway, runtime, identity system, and payment rail. SITEBORNE defines what successful completion means and checks the delivered result without taking over those systems.
Governance determines what may proceed. Assurance checks what actually happened against the agreed outcome. Proof, result release, and settlement remain separate responsibilities.
A workflow can complete perfectly and still return an unacceptable result. SITEBORNE lets durable runtimes do what they do best, then evaluates the outcome against the contract.
MCP, A2A, OpenAPI, and catalogs are different connection surfaces. They should project the same definition of success instead of forcing buyers to reinterpret the capability on every protocol.
A workflow can change steps, suppliers, retries, or execution environments without changing what the buyer asked for. SITEBORNE keeps the acceptance meaning outside the workflow graph.
PCC can carry result and proof material, but proof does not authorize execution, result access, or settlement. Those decisions remain governed separately.
Platforms can still expose specialized capabilities. SITEBORNE only prevents those platform details from silently redefining what the buyer means by success.
A valid payment says something about the economic path. It does not prove who the caller is, whether the result is acceptable, or whether a sensitive result may be retrieved.
SITEBORNE does not need to own identity, gateways, telemetry, registries, or payment rails. It is designed to work with standards and platforms at those layers while keeping the outcome contract coherent.
Providers should compete on execution quality, capability, reliability, and economics. Buyers should not have to redefine acceptable completion every time supply changes.
These cards describe the governed model across current production and Release 3 candidate work. Candidate semantics are labeled as candidate and do not change the live v2 runtime default. Status separates live production from Release 3 candidate →
These are public, inspectable failure conditions. If one occurs, the corresponding claim should not be treated as proven.
Protocol projections preserve the same governed result meaning.
MCP, A2A, OpenAPI, or SDK output changes the acceptance semantics.
Developers ↗Replay returns the persisted canonical result without semantic mutation.
Replay re-signs, invents a new result, or changes buyer-visible meaning.
Lifecycle ↗Identity, payment, proof, result release, and settlement stay distinct.
A receipt, trace ID, wallet, or metadata field silently grants authority.
Trust ↗Changing a qualified path does not redefine acceptable completion.
Provider-specific success criteria overwrite the buyer's contract.
Contract ↗Retry/failover preserves one canonical economic owner and avoids duplicate completion.
Equivalent retries can independently trigger contradictory settlement effects.
Economics ↗Human claims, machine projections, status, and runtime state align to governed release truth.
A public surface claims capability or state the runtime does not support.
Status ↗SITEBORNE does not become more valuable by rebuilding mature infrastructure. It becomes more valuable when those systems remain excellent and their evidence can be composed around one outcome contract.
OIDC/OAuth, delegated-intent, workload identity, and related systems can supply identity or delegation evidence.
evidence sourceGateways can enforce authentication, policy, quotas, routing, protocol controls, and operational guardrails.
traffic authorityWorkflow and agent runtimes can own retries, state, scheduling, recovery, and execution continuity.
execution substrateTelemetry can expose traces, events, latency, failures, and service behavior without becoming operation authority.
operational evidenceEconomic rails can authorize and transfer value while SITEBORNE keeps outcome acceptance and settlement eligibility semantically distinct.
economic railMCP, A2A, OpenAPI, registries, and catalogs can expose capability without owning the canonical meaning of success.
projection surfaceRole labels describe semantic fit, not blanket support claims. Current implementation and qualification state is published on Status.
The non-obvious advantage is that SITEBORNE does not require one party to own every layer.
Demand as proof: public contract, parity, replay behavior, authority boundaries, current status.
Demand as proof: clean projection boundaries and no silent promotion of external metadata into SITEBORNE authority.
Demand as proof: explicit capability semantics, release state, and observable outcome evidence. Adaptive qualification remains status-gated.
These boundaries are intentionally visible because autonomous systems fail when metadata, payments, signatures, and observability are allowed to masquerade as authority.
The public site is organized so an evaluator can move from claim → model → interface → observed state without needing access to private advantage-producing internals.
Verification Contract, VCM, PCC, protocol projections, and the public/private boundary.
Open Docs ↗ 02 / AUTHORITYIdentity, proof, metadata, and authority remain deliberately distinct.
Open Trust ↗ 03 / INTERFACESOne semantic source, multiple public interfaces, with parity as a correctness property.
Open Developers ↗ 04 / OBSERVED STATELifecycle labels and production-facing state remain separate from DESIGN and ROADMAP.
Open Status ↗