Define the outcome once, use the production surface that is live today, and inspect Release 3 candidate contracts without confusing candidate progress with production activation.
Production remains runtime-authoritative on v2. Release 3 candidate work introduces Service Contract 3.0.0, PCC schema 2.0.0, v3 service families, buyer-authorized result semantics for sensitive services, and protocol-projection convergence under qualification.
/readyruntime readiness/catalogservice catalog/schemasschema references/services/{service_id}service metadata/v2/verify/agent-outputverify + PCC/v2/web/contextverified web contextFor production, check what is live now and make one v2 request. Release 3 candidate contracts are for inspection and qualification—not production calls.
Use the runtime as the operational source of truth. Discovery endpoints are public metadata. Paid routes return x402 requirements before execution when economic authorization is required.
curl -s https://utility.siteborne.net/ready
curl -s https://utility.siteborne.net/catalog
curl -s https://utility.siteborne.net/schemasStart with live service state and schema references. Do not infer availability from marketing copy.
curl -s \
https://utility.siteborne.net/services/verify_agent_output.v2Service metadata exposes the current version, availability, economics, and schema references without making you reverse-engineer the route.
For the current x402 path, the first request can return a payment requirement. Sign locally, retry the identical body with the payment signature, then consume the paid response and PCC.
Current public paid v2 routes deliver the governed result in the paid response. No public result-retrieval route is exposed in the current OpenAPI. Current public paid v2 routes do not establish caller identity: x402 payment authorization is quote-bound economic evidence, not identity or general execution permission. Pin the live OpenAPI, service metadata, and quote/challenge at integration time.
Inspect exact runtime contract ↗Use Production for calls you can make today. Use Release 3 Candidate to inspect the next contract, proof, authorization, and protocol model without treating it as activated.
Verify Standard verify_agent_output.v2 and Web Direct web_context_verified.v2 are the current paid production modes. Company Evidence and Document Evidence remain published but production-disabled.
Release 3 candidate work contains four v3 service families, full PCC result envelopes, buyer-authorized handling for sensitive document/verification results, and converging MCP, A2A, OpenAPI, and catalog projections.
| Candidate service | Authorization | Candidate economics | State |
|---|---|---|---|
| company_evidence_graph.v3 | public/governed | $0.0312 / request | CANDIDATE |
| web_context_verified.v3 | public/governed | $0.008 / request | CANDIDATE |
| document_evidence_json.v3 | BUYER_AUTHORIZED | $0.0098 native · $0.0156 OCR · $0.0238 table / page · ≤$0.19 job | CANDIDATE |
| verify_agent_output.v3 | BUYER_AUTHORIZED | $0.017 / request | CANDIDATE |
Not production-purchasable: candidate economics describe governed Release 3 values. The live runtime quote/OpenAPI remains authoritative for anything purchasable now.
Live v2 remains the production default. Two paid modes are enabled now; other published v2 definitions remain unavailable. Release 3 candidate state is intentionally shown separately above.
Treat this matrix as explanatory context only. The live OpenAPI, service metadata, quote, and x402 challenge remain authoritative if availability, price, schema, or mode changes.
POST /v2/verify/agent-output
Standard mode is production-enabled. Independent reproduction is separately defined at $0.049 but is not currently purchasable.
POST /v2/web/context
Direct mode is production-enabled. Rendered mode is separately defined at $0.029 but is not currently purchasable.
POST /v2/company/evidence-graph
The v2 contract and economics are published, but production execution is disabled. Do not build a production dependency on it yet.
POST /v2/document/evidence-json
The v2 job contract is published with metered per-page economics and a declared maximum, but production execution is disabled.
HTTP, MCP, A2A, and x402 serve different jobs. They connect to the same underlying definition of what counts as an acceptable result.
Use the live OpenAPI document for exact production v2 paths, schemas, errors, economics, and security declarations. Release 3 also has a release-qualified candidate OpenAPI contract; that artifact does not replace the live /openapi.json until activation.
MCP is a projection surface, not a second contract definition. Live MCP remains an observed production surface. Release 3 candidate execution wiring exists for all four v3 services while projection metadata convergence is still qualifying; do not equate candidate wiring with production activation. The public MCP endpoint is also entering a governed URL migration: use current discovery metadata rather than treating today’s /mcp address as an immutable future endpoint.
The live Agent Card describes current discoverable capability. Release 3 candidate A2A projection is tracked separately; discovery metadata helps find and understand a capability but does not grant execution or result authority.
Current production paid routes use x402. Payment authorization is an economic input—not identity, execution authority, PCC, result authorization, or settlement authority. Candidate Release 3 economics remain non-purchasable until runtime activation.
Current boundary: legacy Nevermined execution modes are not production-admitted in the live contract.
The example below shows the business idea directly: define the facts and evidence required for success, submit a candidate result, then see whether it is accepted. The live utility remains the source for current fields, availability, and price.
{
"verification_contract": {
"claims": [{
"claim_id": "company_name",
"predicate": "equals",
"expected_value": "Acme Corp",
"materiality": "material"
}],
"deterministic_requirements": [
{ "requirement_id": "schema", "check": "schema_valid" },
{ "requirement_id": "evidence", "check": "evidence_resolves" }
]
},
"candidate_output": {
"company": "Acme Corp",
"confidence": 0.95
},
"required_schema": {
"type": "object",
"properties": { "company": { "type": "string" } },
"required": ["company"]
},
"verification_mode": "standard",
"maximum_authorized_price": {
"amount": "0.017",
"currency": "USD"
}
}Send the body without PAYMENT-SIGNATURE.
Read PAYMENT-REQUIRED; invalid requests fail before a payment challenge.
Your x402-capable client or wallet authorizes the exact requirement. Keep the private key client-side.
Add PAYMENT-SIGNATURE. The governed paid lifecycle performs admission, execution, receipt generation, and settlement.
Consume the paid response and preserve PAYMENT-RESPONSE plus the proof-carrying result material.
The second request uses the same body plus the signed payment authorization returned by your x402 client.
curl -i -X POST \
https://utility.siteborne.net/v2/verify/agent-output \
-H 'content-type: application/json' \
--data-binary @request.jsonThese snippets intentionally stop at the 402 boundary. Feed PAYMENT-REQUIRED into your chosen x402 signer, keep the private key local, then retry the exact same body with PAYMENT-SIGNATURE.
const body = JSON.stringify(request);
const res = await fetch(
"https://utility.siteborne.net/v2/verify/agent-output",
{
method: "POST",
headers: { "content-type": "application/json" },
body
}
);
if (res.status === 402) {
const requirement =
res.headers.get("PAYMENT-REQUIRED");
// Sign requirement locally with your x402 client,
// then retry this exact `body`.
}import json, urllib.request, urllib.error
body = json.dumps(request).encode()
req = urllib.request.Request(
"https://utility.siteborne.net/v2/verify/agent-output",
data=body,
headers={"content-type": "application/json"},
method="POST",
)
try:
urllib.request.urlopen(req)
except urllib.error.HTTPError as e:
if e.code == 402:
requirement = e.headers["PAYMENT-REQUIRED"]
# Sign locally; retry the identical `body`.Try a match, a mismatch, or missing evidence. The same contract produces a clear ACCEPT or REJECT decision.
{
"decision": "ready",
"claim": "company_name",
"proof": "demo_only"
}SITEBORNE is designed to sit beside your cloud, models, workflows, identity, gateways, observability, and payment systems—not replace them.
External systems supply execution, identity, policy, telemetry, discovery, provenance, or economic mechanisms. They remain evidence, adapters, or projections—not silent canonical authority over SITEBORNE contract satisfaction.
Agent/runtime ecosystem context.
Enterprise/cloud/agent ecosystem.
Cloud/agent/API ecosystem.
Edge/runtime infrastructure context.
Model and agent ecosystem context.
Durable execution integration direction.
Retrieval/automation integration target.
Verification Contract
define → verify → prove
Tool/machine projection.
Agent discovery/interoperability.
HTTP contract projection.
Transport substrate.
Validation vocabulary.
Current machine payment rail.
Additional payment-rail compatibility.
Lifecycle labels describe SITEBORNE’s relationship to each technology, not partnership, endorsement, or universal production support.
Use SITEBORNE where a result needs an explicit acceptance check: after a tool call, before a handoff, before publishing, or before treating work as complete.
Run the agent where it already lives; call SITEBORNE at a deterministic verification hook when the outcome needs contract-bound assurance.
REFERENCE INTEGRATIONKeep AgentCore responsible for runtime concerns while SITEBORNE verifies the buyer-visible outcome contract outside the execution substrate.
REFERENCE INTEGRATIONAdd verification at a graph boundary—after a tool, before handoff, before publish, or on acceptance—without turning the graph into the canonical contract.
REFERENCE TARGETUse a contract check as middleware around agent/tool execution while preserving the framework’s own orchestration and state responsibilities.
REFERENCE TARGETExpose SITEBORNE through remote MCP-compatible client flows while keeping MCP metadata as a projection rather than the definition of outcome success.
REFERENCE TARGETUse remote MCP/client integration as the transport surface; bind acceptance to the same Verification Contract used elsewhere.
REFERENCE TARGETKeep enterprise identity and client controls intact; normalize their evidence without silently promoting the external platform into SITEBORNE authority.
REFERENCE TARGETWhere remote connector policy permits, invoke SITEBORNE as an external verification service without embedding private qualification logic in the client.
REFERENCE TARGETLet the workflow engine own durable execution and retries. Put SITEBORNE at an acceptance boundary so workflow completion and contract satisfaction remain distinct.
ROADMAP INTEGRATIONUse Apify for request building, external observation, benchmark fixtures, or black-box load generation while keeping the canonical verification and payment path directly bound to SITEBORNE.
REFERENCE TARGETKeep traffic policy, rate limits, routing, and gateway controls where they already belong. Add SITEBORNE only where a buyer-visible result needs independent contract-bound verification.
COMPLEMENTARY PATTERNYou do not need to verify every token or every tool call. Insert a contract check at a stable system boundary where acceptance, payment, action, publication, or handoff matters.
Mirror candidate results into SITEBORNE without changing the existing workflow. Measure caught failures, disagreements, false positives, latency, cost, and operational burden before making assurance advisory or mandatory.
Independent observers publish live uptime and protocol evidence beside the runtime itself, so developers can inspect operational signals without relying on SITEBORNE copy alone.
Inspect the public evidence snapshot →
Agenstry uptimepositive live signal ↗
A2A protocolproven support ↗
MCP protocol erameasured support ↗
[](https://agenstry.com/agents/utility.siteborne.net)
[](https://agenstry.com/agents/utility.siteborne.net)
[](https://mcpmetrics.io/servers/net-siteborne-utility)A payment can be valid while a result is wrong. A result can exist without being authorized for retrieval. Proof can be correct without granting permission. SITEBORNE keeps these decisions separate.
Schema violation or unavailable mode. The live contract states no quote is created and nothing is charged for this failure class.
Read the bound x402 requirement. This is economic authorization—not caller identity or outcome proof.
A paid route can be closed by release policy. Treat absence as closed—not as permission to fall back silently.
The governed service executor is not configured. Do not reinterpret infrastructure failure as contract success.
The current paid profile is read-only execution with quote-bound x402 authorization. Buyer keys remain local; the server receives signed authorization evidence, not the buyer’s private key.
Read the trust model →Report a security issue →/ready and /catalog.Before release, confirm what is live, validate the request and response shape, preserve the proof you need, and re-check service state when the runtime changes.
Current service catalog and production metadata.
Machine discovery surface.
VCM, PCC, protocol projections, and public-safe semantics.
Identity, authority, proof, result, and settlement separation.
Observed state, qualification, and repair declarations.
Use the connection method your team already knows. Keep the definition of an acceptable outcome stable as providers, tools, and infrastructure evolve.