WHAT IS AN EXECUTION SURFACE?
One surface, one irreversible action class
An execution surface is the point where a system action becomes irreversible. The taxonomy is deliberately small: each surface represents one irreversible action class, named with infrastructure vocabulary (not industry workflows, not product features, not user intentions).
The 13 canonical surfaces are the protocol-recognized authorization boundaries. They are bounded (~10-13 cap), umbrella categories, many real-world actions across many industries collapse under them.
Authoritative source: Resources (surface taxonomy and governance summaries).
REGISTRY INDEX (PLATFORM SYNC)
Live surface table
The table below reflects the same canonical registry index used to build this site; it is kept in sync with the protocol registry. It is the canonical shape for surface, riskClass, reversible, and category.
| Surface | riskClass | reversible | category |
|---|---|---|---|
| Loading registry… | |||
THE TWO-TIER MODEL
Recognized vocabulary, not runtime dispatch
TrigGuard's published capabilities manifest exposes surfaces under two fields:
execution_surfaces, the live runtime-recognized vocabulary, currently four legacy snake_case names plus the canonicaldata.export. These names appear on receipts and in manifests for vocabulary alignment.execution_surfaces_planned, the canonical 13 listed below. These are the long-term protocol vocabulary.
Honest current state
Offline receipt verification (CLI, /verify, keys from /.well-known/trigguard-keys.json) does not dispatch per surface: it checks cryptographic binding and receipt fields regardless of the surface string. The manifest declares runtime dispatch explicitly:
surface_taxonomy.enforcement_model.runtime_dispatch = falsePer-surface runtime dispatch will land with the Execution Authorization Gateway (TG-EXECUTION-AUTH-01); it is not deployed today. Until then, the surface field is recognized vocabulary, not runtime-enforced gating.
STRATEGIC ANCHORS
The five surfaces that define the category
Five of the canonical 13 are anchor surfaces. Together they cover the most widely applicable authorization boundaries across industries, trust transfer, AI control, data boundary crossing, system change, and formal commitment:
authority.delegate
Trust transfer, granting another system or agent the power to act.
tool.invoke
AI control plane, an agent or LLM calling a side-effecting tool.
data.export
Boundary crossing, bulk data leaving a trust or regulatory zone.
deploy.release
System change, code or configuration becomes externally consequential.
document.sign
Formal commitment, a legally or operationally binding signature event.
THE CANONICAL 13
Full taxonomy
CORE INFRA, SYSTEM CHANGE AND SHIPPING
deploy.release
A new code or configuration release becomes externally consequential, promoted to production, exposed to end users, or made the active version. Falls under: container rollouts, helm upgrades, mobile app store releases, hardware firmware pushes, AI model promotions to a serving tier.
config.change
A runtime-affecting configuration change crosses into production scope, feature flags, routing, rate limits, IAM policy, environment variables, infra parameters. Distinct from deploy.release (no new code) and database.migrate (no schema or data shape change).
artifact.publish
A build or model artifact is published to a registry where downstream systems may pull it, container images, language packages, model weights, signed binaries.
database.migrate
Schema changes, large data migrations, irreversible DDL. Distinct from config.change, this surface is specifically about altering the shape of stored data, not the system that reads it.
SECRETS AND IDENTITY
secret.access
A secret is materialized for use, credential retrieval, KMS decryption, vault reads. TrigGuard authorizes the access event; the secret payload itself remains in your vault or KMS.
identity.assert
An identity claim is presented and accepted, login, token issuance, SSO assertion, machine-identity attestation. Distinct from authority.delegate (no power transfer occurs here, only identity binding).
authority.delegate
One actor grants another the power to act on its behalf, role assumption, agent delegation, OAuth-style authorization grant, temporary privilege escalation. The category-defining surface for trust transfer.
DATA AND GOVERNANCE
data.export
Data crosses a trust or regulatory boundary, bulk export, third-party transmission, downloadable extract, regulator submission. The category-defining surface for boundary crossing.
data.delete
A delete that is intended to be permanent, GDPR right-to-be-forgotten, irrecoverable record purge, compliance-driven destruction. Distinct from soft-delete or recycle-bin operations.
policy.activate
A new policy or rule becomes runtime-effective, content moderation rules going live, MFA enforcement turned on, agent-safety policy gating tool.invoke, circuit-breaker enabled.
AI AND AUTOMATION
tool.invoke
An agent or LLM calls a side-effecting tool, function call, plugin invocation, MCP server call, code-interpreter exec. The category-defining surface for AI control.
agent.execute
A multi-step agent run is launched against real systems, autonomous task execution, agentic workflow start, scheduled agent activation. Distinct from a single tool.invoke.
UNIVERSAL GOVERNANCE
document.sign
A formally binding signature is recorded, contract signing, policy approval, compliance attestation, regulator filing. Cross-industry primitive for formal commitment.
NAMING RULE
Infrastructure vocabulary, not industry workflows
Surfaces follow the shape <domain>.<action> (or <domain>.<object>.<action> when an object is meaningfully distinct). They describe system-level irreversible actions, not user intentions, business workflows, or industry semantics.
Industries do not get their own namespaces. A law firm signing a settlement, an HR offer letter being accepted, and a regulator filing being executed all collapse under document.sign. A bank wire, a medical-record export, and an analytics extract all collapse under data.export. This umbrella property is the source of the protocol's universality.
The naming rule and bounded cap are binding governance; see Resources for the published taxonomy decision summary.
MIGRATION HISTORY
Legacy surfaces - Phase C executed 2026-04-19
Four snake_case surface names were live before the canonical taxonomy was locked. Phase C of the migration was executed on 2026-04-19 by founder amendment, collapsing the previously planned 2026-07-01 alias window early because no meaningful external integrator depended on the legacy names. The legacy surfaces are no longer advertised on the public capabilities manifest:
| Legacy | Outcome | Status |
|---|---|---|
data_export | renamed to data.export | removed from public manifest 2026-04-19 |
spend_commit | retired (no replacement) | removed from public manifest 2026-04-19 |
time_commit | retired (no replacement) | removed from public manifest 2026-04-19 |
social_commit | retired (no replacement) | removed from public manifest 2026-04-19 |
Receipts already issued with legacy surface values remain valid forever - receipts are immutable artifacts and are never retroactively rewritten. The three retired behavioral surfaces (spend_commit, time_commit, social_commit) have no canonical replacement; they were product semantics, not infra primitives. An internal ingress-only compatibility shim still accepts the legacy names at the request boundary so historical and in-flight clients do not break, but every emitted artifact (receipts, logs, metrics, traces, commit tokens, public responses) carries the canonical name only; the shim is scheduled for removal once SDK telemetry confirms zero use.
Authoritative source: Resources (surface migration and taxonomy notes).
APPLY THE TAXONOMY
Mapping your actions onto canonical surfaces
Find the irreversible action class your system performs and map it to one of the canonical 13. Most teams begin with one of the strategic anchors, deploy.release, data.export, tool.invoke, authority.delegate, or document.sign.
If your action does not obviously fit one of the 13, the taxonomy is intentionally bounded. New surfaces require an explicit governance amendment, they are not added per integrator. This bounded cap is what keeps the protocol stable.