Skip to main content
Version:

Trust Tiers

Trust tier definition

A trust tier is a policy-defined classification assigned to a specific trust boundary from accumulated evidence. Trust tiers can reduce approval friction within policy bounds, but they must never weaken permit validation, audit recording, or checkpoint enforcement (per CB-005).

Example tier names in the normative model include untrusted, provisional, trusted, and high-trust (trust_state_persistence_spec.md §5).

Trust as an authoritative resource

Trust state is an authoritative control-plane resource, not a cache and not a hint (per TP-001). Trust records are persisted, versioned, and audited in the same governed store discipline as approvals and permits (trust_state_persistence_spec.md §4).

No containers: per-boundary independence

There is no session-level, identity-level, or operator-level trust that implicitly covers a class of actions. Every distinct combination of (specialist × tool × capability class × path scope × workflow class × provider) is its own boundary with its own trust record starting at zero. The system has no concept of "generally trusted" — only "trusted here, for this, now." (per TP-003, CB-007)

Boundary-level trust independence applies to tool, path scope, specialist, provider, workflow class, and other policy-defined dimensions.

Accumulation and destruction asymmetry

Trust accumulates slowly through evidence; trust is destroyed instantly through violation. This calibration is correct for a system where a single unauthorized action can be catastrophic. (per TP-006a, CB-006)

Accumulation uses policy-defined evidence classes over repeated compliant behavior. Destruction is immediate reset to untrusted on first violation, with no grace period and no partial carryover.

Offense history persistence

Repeat offense history is persistent across sessions. Violation history is not session-local and remains until explicitly reset by authorized operation (per TP-006, trust_state_persistence_spec.md §14).

Cross-session trust continuity

Cross-session continuity is required for evidence-based friction reduction (per TP-002, trust_state_persistence_spec.md §8).

Exception: session-scoped specialist trust is created for the session and revoked at session end with explicit revocation events (per TP-008, trust_state_persistence_spec.md §9).

Policy version in trust records

Trust records embed the policy version that governed their tier evaluation. Policy upgrades can trigger trust-tier re-evaluation and demotion if mappings tighten (per TP-007, trust_state_persistence_spec.md §16).

Trust tiers and permit scope

Trust tiers can reduce friction, but they do not weaken the execution gate. What trust can change is which approval path is available:

  • low trust may require a fresh one-time approval
  • stable trust may allow session-scoped reuse when the operator chooses session
  • policy rules may allow policy-sourced auto-permit or policy-session-grant behavior only at or above a required trust tier

The important boundary is that trust affects whether friction is reduced, not whether permit validation or audit recording still happen.

Governance-suspended minimum tier

governance_mode_policy.minimum_auto_permit_tier_if_suspended is evaluated against the current workspace trust tier at session start.

If the current tier is below that minimum, governance-suspended mode is rejected with an audit event and exit code 4. This prevents a headless run from starting in a workspace that does not currently meet the required trust posture.

Trust record structure

Minimum trust-record fields (trust_state_persistence_spec.md §5):

  • record identifier
  • boundary type
  • boundary identity
  • confidence score (0-100 internal)
  • current trust tier
  • evidence log
  • policy version
  • last promotion timestamp
  • last demotion timestamp
  • last violation timestamp
  • offense count and repeat-offense tier
  • revocation status
  • created-at timestamp
  • record version