Glossary

Canonical terms

Decision Trust Protocol (DTP)

The protocol. A nine-step authorization pipeline — seven decision gates plus two system steps — that evaluates every agent-initiated transaction and returns an enriched, explainable decision.

KYA Score (Know Your Agent)

The customer-facing composite trust score (0–1) attached to every authorization decision and every agent. Maps to four trust zones — GREEN / AMBER / RED / CRITICAL (see Trust zones). If a number travels to your dashboard, webhook, or network field, it is the KYA Score.

EDQS (Economic Decision Quality Score)

The research methodology behind decision-quality evaluation. Scores the quality of an agent's economic reasoning across six dimensions: alternative analysis, confidence calibration, constraint alignment, temporal efficiency, value optimization, and risk-adjusted reasoning. EDQS is internal signal science; it surfaces to customers through the anomaly gate and the KYA Score. See the EDQS Research Framework and the three-layer model below.

Three-layer signal model

Layer 1 — collection: seven ABT signal classes (cadence, intent coherence, amount distribution, merchant affinity, session topology, error response, trust trajectory) gather observed behavior. Layer 2 — detection: six anomaly detectors at gate 3 (confidence inflation, alternatives collapse, reasoning length anomaly, vocabulary shift, amount escalation, MCC drift) test each transaction against the baseline. Layer 3 — evaluation: the six EDQS quality dimensions grade the decision itself. The three lists are related but distinct — do not interchange their names.

Authorization pipeline

The canonical nine steps: 1 Agent Resolve · 2 Intent Verification · 3 Anomaly Gate (EDQS) · 4 Mandate Enforcement · 5 Behavioral Overlay · 6 Risk Scoring · 7 KYA Decision · 8 Persist + Webhooks (system) · 9 Async Post-Decision (system). Steps 1–7 are decision gates; 8–9 are system steps.

Entity hierarchy

The data model is strictly nested: Client → Program and Principal → Agent → Mandate. The Client is the tenant and credential holder; Programs and Principals are created under a Client; Agents belong to a Principal; Mandates constrain an Agent. Do not conflate Client (the contracting organization) with Principal (a person or merchant onboarded under that Client).

Client

The contracting organization — the tenant. A Client is vetted through KYB before provisioning, holds the Mandate Labs API credential (ID prefix cli_), and onboards Programs, Principals, and Agents beneath it. Client-authenticated requests pass the key in the X-API-Key header. There is no self-serve sign-up; become a Client through sales (Book a demo) or try the protocol in the sandbox MCP playground.

Program

A card or crypto program operated under a Client (ID prefix prg_). A Principal is attached to one or more Programs, which determine the rails and issuing/settlement configuration available to its Agents.

Principal

A person or merchant onboarded by a Client (ID prefix prn_). A Principal delegates spending authority to the Agents it owns and is the subject of KYC/KYB verification. The Principal is not the contracting organization — that is the Client.

Agent

An autonomous AI system registered under a Principal that initiates transactions on that Principal's authority (ID prefix agt_). Identified by an agent ID, with an accumulated behavioral baseline.

Mandate

A programmable grant of spending authority to an Agent (ID prefix mnd_): amount ceilings, merchant category (MCC) restrictions, geographic constraints, temporal windows, and frequency limits. Mandates are enforced at gate 4 against platform-held data — they are not agent-attested.

intent_context

The structured object an agent must submit with every authorization request: intent_type, task_reference, reasoning_summary, confidence, alternatives_considered. An attestation, not a credential — see What we verify vs. what agents attest.

Trust zones

Four zones, mapped from the KYA Score: GREEN (≥ 0.7 — healthy, continue) · AMBER (0.4–0.7 — degradation detected, limits tightened 25%) · RED (0.2–0.4 — significant risk, limits halved) · CRITICAL (< 0.2 — session termination recommended). Zone transitions fire kya.zone.* webhooks; kya.zone.red and kya.zone.critical mark the two escalation thresholds.

Behavioral Overlay

Gate 5: model-risk monitoring of the agent's current behavioral state — reasoning degradation, drift from baseline, and prompt-injection indicators. (Research publications refer to this layer as cognitive trust monitoring.)

Decision

The pipeline output: APPROVE, DECLINE, or STEP_UP, with KYA Score, risk score, fired gates, and reason codes. Decisions are advisory inputs to the customer's own authorization logic (see MSA §1.3).

Fail policy

Platform behavior when a dependency is unavailable. Default FAIL_CLOSED (decline recommendation). Clients may configure fail-open below a maximum amount threshold, at their own risk.

MCI (Mandate Certified Integration)

The certification program gating production access: sandbox conformance across all transaction types, intent_context implementation review, mandate configuration validation, webhook and failure-handling verification, and UAT sign-off.

Numbers canon

Every count, and what it refers to — do not interchange: 9 pipeline steps (7 decision gates + 2 system steps) · 7 ABT signal classes (collection) · 42 ABF features (six per signal class, 6×7) · 17 risk-signal taxonomy types (DTP §7.2, deep analysis) · 8 signal categories surfaced in the dashboard (product subset of the 17) · 6 anomaly detectors (gate 3) · 6 EDQS quality dimensions (evaluation rubric) · 4 trust zones · 4 KYA components (production formula) · 23ms engine decision time under burst; sub-100ms P50 sustained end-to-end (see status page for live figures).

Derived Data

De-identified, aggregated telemetry derived from platform usage, used to improve scoring models and publish benchmarks. Defined in MSA §7.3.

Deprecated terms