Trust Graduation Protocol

1.Contract¶

An implementation MUST classify a proposed action before execution.

An implementation SHOULD expose these primitive operations:

• canExecute or equivalent decision function
• prepareApprovalPacket
• recordReceipt
• recordEvidence
• posterior

The trust unit is the action_class. Evidence for draft.compose MUST NOT imply permission for email.send.external.

2.Action Classes¶

Action classes use lowercase dot notation. The v0.1 canonical registry:

Legacy aliases SHOULD canonicalize as follows:

Implementations MAY add local classes, but MUST preserve the same decision, evidence, posterior, and receipt semantics.

3.Decision States¶

Decision states are:

• allowed: execution may proceed.
• allowed_with_constraints: execution may proceed only inside machine-evaluable constraints.
• review_required: prepare an approval packet; do not execute externally.
• deferred: queued for asynchronous approval; do not execute externally.
• blocked: not permitted under current policy or evidence.
• human_only: only the principal may perform this action.

allowed_with_constraints is a post-approval execution boundary, not a pre-approval autonomy class. The constraints scope the authority that an approval — explicit (principal sign-off) or rule-derived (graduated policy) — has already granted. Implementations MUST NOT use allowed_with_constraints to bypass the review_required or human_only gates.

3.1Constraint Vocabulary¶

allowed_with_constraints MUST use structured constraints, not prose-only instructions. The v0.1 constraint vocabulary:

• internal_only
• staging_only
• dry_run_only
• max_amount
• rate_limit
• recipient_allowlist
• domain_allowlist
• expires_at
• requires_witness
• redaction_rules

{
  "status": "allowed_with_constraints",
  "action_class": "email.send.internal",
  "constraints": {
    "domain_allowlist": ["company.com"],
    "rate_limit": { "count": 5, "window": "PT1H" },
    "expires_at": "2026-06-13T18:00:00Z"
  }
}

4.Evidence Model¶

Evidence has two axes:

1. decision_weight: the observed outcome quality.
2. provenance_weight: the reliability of the source that produced the evidence.

The intended evidence update is:

evidence_weight = decision_weight × provenance_weight

Mission's current runtime ships decision-quality weighting. Provenance weighting is part of the v0.1 normative evidence model and is scheduled for runtime convergence in v0.2.

4.1Decision Weights¶

Trust violations, safety incidents, leaks, or exposed private data SHOULD carry weight -1.00 and force review until cleared by the principal.

4.2Provenance Weights¶

Implementations MAY learn provenance weights per workspace and action class, but MUST NOT silently upgrade model_inferred evidence to receipt-grade evidence.

5.Posterior¶

Trust Graduation computes a Beta posterior over approval/success probability per action class.

The default prior is:

alpha = 2
beta  = 2

For each non-zero evidence row:

• positive evidence adds |evidence_weight| to alpha
• negative evidence adds |evidence_weight| to beta

Implementations SHOULD compute mean, ci_low, ci_high, ci_width, samples, tier, and graduation_ready. The Mission reference computes the 95% credible interval with the regularized incomplete beta function and quantile bisection.

Default graduation thresholds:

External-effect classes MUST NOT auto-promote to ungated external execution solely from the posterior. The posterior may recommend readiness; the enforcement gate remains authoritative.

6.JSON Schemas¶

These schemas are intentionally minimal. Implementations MAY add fields. All schemas use JSON Schema draft 2020-12 and resolve at their $id URL.

7.Hash-Chained Receipts¶

Receipt hash chaining is specified for auditability but not required for minimal v0.1 implementations.

Implementations SHOULD use RFC 8785 JSON Canonicalization Scheme before hashing receipt commitments. A receipt MAY delete or redact private content while preserving:

• receipt_id
• prev_hash
• content_hash
• redacted_for
• non-sensitive metadata needed for audit continuity

Key rotation and external anchoring are deferred to v0.2. Mission Cloud may act as the first anchor store; future implementations may use a public transparency log.

8.Standards Mapping¶

Standards mapping is informational, not required for protocol conformance.

• W3C PROV-O. Receipts, evidence rows, and approval packets can be represented as provenance entities, activities, and agents.
• NIST AI RMF / NIST AI 600-1. Trust Graduation provides concrete governance, provenance, testing, and incident-record artifacts for agentic work.
• ISO/IEC 42001. Trust Graduation receipts and risk reports can support traceability, transparency, and AI management-system evidence.
• EU AI Act Article 14. Approval packets, override, stop/blocked states, and human-only classes operationalize human oversight for consequential AI-assisted actions.

9.Implementation Status¶

Mission currently ships:

• canonical action-class registry
• reference wrapper
• approval packet pattern
• receipt pattern
• decision-quality weighting
• Beta posterior with 95% credible intervals
• prepare-before-execute public product boundary

Mission has not yet fully shipped:

• unified provenance-weight × decision-weight runtime updates
• MCP proxy enforcement around arbitrary third-party MCP servers
• hash-chained receipt storage
• external anchoring
• standards appendices as public buyer collateral

← Back to homepage