The Action Envelope Stack™.
In five seconds: these are the JSON shapes a verifier, an MCP server, an agent, or a platform uses to describe what it observed — a result state, the missing evidence, and where to go next. They carry guidance and routing. They never create or change verification state, host checkout, or stand in for the public proof surface.
One shape. Clear boundaries.
Every envelope carries the same always-true flags: local_policy_decides, recheck_before_reliance, and no_safety_or_approval_inference.
Developer Gateway
Documents and routes. It does not host checkout, create or change verification state, or act as a public proof surface.
TrustOps
Handles acquisition, setup, payment, and lifecycle. Setup happens there, not here.
Resolver
Remains the public proof surface for current state. Machines re-check it before reliance.
Four envelopes.
JSON Schema 2020-12. Read the human guidance, then fetch the schema or an example instance directly.
Resolver Action Envelope™
Universal public proof and action metadata. A read-only projection of current state.
MCP Action Envelope™
MCP / tool / server posture improvement path. Carries a result state, missing evidence, and a routing action set.
Agent Action Envelope™
Agent / KYA / operator / principal posture path. Points at Resolver for current state and TrustOps for setup.
Reciprocal Reliance Envelope™
Both sides of an agent ↔ MCP / tool interaction in one read-only object. Each side applies its own local policy.
Packets and manifests.
Request-to-Resolve™ packet
A locally generated guidance packet. Not signed and not created server-side. Routes only. It carries the message: “No public resolver proof found yet. This does not mean unsafe.”
Resolver Re-check Contract
Re-check semantics for verifiers. If the Resolver is unavailable, treat it as missing proof — never read it as proof. REQUIRE fails closed.
TrustOps Product / Action Manifest
A machine-readable routing manifest. It does not create checkout, entitlement, or public proof. Public proof appears only after ECZ-ID Core activation/provisioning, not at checkout alone. A read-only instance is published as the setup routing manifest.
Resolve the server. Re-check before reliance.
MCP server operator
Make your server resolver-identifiable so callers can check posture before a tool call.
Open TrustOps setup ↗MCP tool vendor / SaaS founder
Document provider-side posture for the tools and APIs your server exposes.
Check MCP resolver posture →AI developer / agent builder
Read an MCP Action Envelope before letting an agent call a high-risk tool.
View MCP envelope →DevOps / platform engineer
Wire the result-state vocabulary into your own checks. Re-check before reliance.
View result states →Security / CISO
Map result states and reason codes to allow / warn / require gates. Local policy decides.
View MCP Policy guidance →Procurement / vendor risk
Ask vendors for resolver-verifiable posture as part of review. No checkout here.
Share resolver guidance →Marketplace / platform reviewer
Consume envelopes uniformly across servers, agents, and counterparties.
Review both sides →Autonomous agent / policy engine
Parse the JSON schema directly and apply policy_hint with your own thresholds.
View schema index →Resolve the agent. Show the accountable operator.
Solo builder
Make your agent resolver-identifiable with an identity floor.
Make your agent resolver-identifiable →AI automation agency
Show the accountable operator behind each agent you ship.
Show the accountable operator →SaaS founder deploying agents
Prepare agents for serious business review with a verified posture.
Prepare for serious business review →Business owner using agents
Understand what current state a counterparty can re-check before reliance.
View Agent envelope →API provider receiving agent traffic
Read an Agent Action Envelope before accepting calls. Re-check before reliance.
Receiving-agent workflow →Merchant preparing for agentic commerce
Document operator posture ahead of automated counterparty review.
Open TrustOps setup ↗Enterprise security / CISO
High-reliance resolver posture for agents in serious environments.
View Assured KYA →Procurement / vendor risk
Request resolver-verifiable operator context as part of onboarding.
Request Resolver Proof →Financial operations / payment risk
Public proof follows ECZ-ID Core activation/provisioning, not checkout; re-check current state at the Resolver.
Open Resolver ↗Regulated-sector buyer
Use a high-reliance posture path that supports fail-closed verification.
Fail-closed verification →Principal / accountable operator
Become the accountable operator a counterparty can resolve.
Open TrustOps setup ↗Agent customer checking who is behind an agent
Read the public posture and re-check before reliance. This does not mean unsafe.
Share resolver guidance →For agents and LLMs reading this page.
Parse the schema index and fetch any schema directly. These objects describe metadata only. Nothing here writes verification state, activates proof, processes purchase, or carries any inference of safety, certification, approval, insurance, full compliance, or platform endorsement. Local policy decides. Re-check before reliance.