Tier System (A/B/C/X)

Every action governed by TheWARDN is classified into one of four tiers. The tier determines the verdict -- whether the action is approved, held for review, or blocked. Tiers represent a spectrum from full autonomy to absolute prohibition.

Tier Overview

Tier	Name	Verdict	Agent Behavior	Human Involvement
A	Autonomous	`CLEARED`	Agent executes immediately	None required
B	Supervised	`HELD`	Agent waits for human decision	Human reviews and approves/rejects
C	Controlled	`BLOCKED`	Agent must not execute	Human is notified, violation recorded
X	Prohibited	`BLOCKED`	Agent must not execute	Violation recorded, potential autonomy reset

Tier A: Autonomous

Tier A actions are approved for immediate autonomous execution. The agent receives a CLEARED verdict and may proceed without waiting for human input.

When an action is Tier A:

The action type is mapped to Tier A in the tenant's tier configuration.
All confidence thresholds are met.
No CHAM policies escalate the tier.
The action is within an approved change window (if applicable).
No SGP principles are violated.

Example Tier A actions:

Reading non-sensitive log files
Running diagnostic queries in staging
Sending status notifications
Restarting a non-critical service in development

json

{
  "verdict": "CLEARED",
  "tier": "A",
  "reasoning": "Action type log_read is Tier A. All confidence thresholds met."
}

TIP

Tier A does not mean "unmonitored." Every Tier A action is still recorded in the audit trail with a full hash-chained record. Autonomous does not mean ungoverned.

Tier B: Supervised

Tier B actions require human review before execution. The agent receives a HELD verdict and the action is placed in the escrow queue. A human reviewer must explicitly release (approve) or kill (reject) the action.

When an action is Tier B:

The action type is mapped to Tier B in the tier configuration.
A Tier A action was escalated due to low confidence scores.
A CHAM policy (e.g., environment_restriction) escalated the tier.
The action is outside an approved change window.

Escrow behavior:

The agent receives an escrow_id to track the action's status.
The action has a timeout (default: 10 minutes for Tier B).
If the timeout expires without a human decision, the action is automatically killed.
The agent can poll the escrow status endpoint to check for a decision.

Example Tier B actions:

Deploying code to production
Modifying configuration in production
Scaling infrastructure up or down
Accessing sensitive data stores

json

{
  "verdict": "HELD",
  "tier": "B",
  "escrow_id": "esc_abc123",
  "timeout_at": "2026-04-10T15:10:00Z",
  "reasoning": "Action type code_deploy is Tier B for production environment."
}

Three possible outcomes:

Outcome	Trigger	Result
Release	Human approves	Agent receives `CLEARED` on next poll
Kill	Human rejects	Agent receives `BLOCKED` on next poll
Timeout	Timer expires	Agent receives `BLOCKED` (timeout = rejection)

Tier C: Controlled

Tier C actions are blocked by CHAM policy violations. The agent receives a BLOCKED verdict and must not execute the action. A violation record is created for audit purposes.

When an action is Tier C:

The action type is explicitly mapped to Tier C.
A CHAM policy (e.g., action_type_block) explicitly blocks the action.
A Tier B action was further escalated due to compounding policy violations.
Confidence scores are critically below thresholds.

Key difference from Tier X: Tier C blocks are policy-level -- they result from configurable CHAM rules, not from hardcoded SGP violations. A Tier C block can be resolved by changing policies, adjusting confidence thresholds, or modifying the action.

Example Tier C actions:

Running database migrations outside the change window with no emergency flag
Accessing a data classification that the agent is not authorized for
Exceeding rate limits

json

{
  "verdict": "BLOCKED",
  "tier": "C",
  "reasoning": "CHAM policy 'action_type_block' prohibits database_drop in production.",
  "rule_violated": "policy_db_drop_block",
  "policies_fired": ["policy_db_drop_block"]
}

Tier X: Prohibited

Tier X actions violate one or more of the 21 Sentinel Governance Principles. This is the highest severity classification. The action is BLOCKED, a high-severity violation record is created, and the agent may face an autonomy reset -- a forced reduction in the agent's permitted tier level.

When an action is Tier X:

The action violates an SGP principle (e.g., SGP-17: prohibited action classes).
The action's reasoning contains governance circumvention patterns (SGP-21: X_ABSOLUTE).
The action attempts to modify the governance system itself (SGP-18).
Confidence inflation is detected (SGP-19).

Key difference from Tier C: Tier X blocks are principle-level -- they result from violations of the immutable SGP, not from configurable policies. No configuration change can make a Tier X action permissible. The only resolution is to fundamentally change what the agent is attempting to do.

Autonomy reset: When a Tier X violation is recorded, the agent's autonomy level may be reset to L0 (lowest autonomy). This means all of the agent's subsequent actions -- even ones that would normally be Tier A -- are escalated to at least Tier B until the agent's autonomy level is restored by an administrator.

Example Tier X actions:

Attempting to delete production databases
Attempting to exfiltrate credentials
Submitting actions with reasoning that argues for disabling governance
Attempting to modify the Sentinel engine or audit trail

json

{
  "verdict": "BLOCKED",
  "tier": "X",
  "reasoning": "SGP-17 prohibits autonomous deletion of production data. SGP-21 triggered: reasoning contains governance circumvention patterns.",
  "rule_violated": "SGP-17, SGP-21",
  "policies_fired": [],
  "autonomy_reset": true
}

WARNING

Tier X violations are permanent audit records. They cannot be deleted, modified, or expunged. They are visible in compliance reports and regulatory exports. An organization's Tier X violation count is a key governance health metric.

Tier Mapping Configuration

Tier mappings define which tier applies to each action type. They are configured per tenant and can be overridden per agent.

Default Tier Mapping

json

{
  "tier_mappings": {
    "log_read": "A",
    "metric_query": "A",
    "status_check": "A",
    "notification_send": "A",
    "code_deploy": "B",
    "config_change": "B",
    "service_restart": "B",
    "data_migration": "B",
    "infra_scale": "B",
    "database_drop": "C",
    "schema_delete": "C",
    "data_purge": "C",
    "credential_rotate": "B",
    "user_permission_change": "B",
    "governance_modify": "X",
    "audit_delete": "X"
  }
}

Environment-Specific Overrides

Tier mappings can be different per environment:

json

{
  "tier_mappings": {
    "code_deploy": {
      "development": "A",
      "staging": "A",
      "production": "B"
    },
    "service_restart": {
      "development": "A",
      "staging": "B",
      "production": "B"
    }
  }
}

Agent Tier Overrides

Individual agents can have their tiers overridden, either escalating or restricting:

json

{
  "agent_id": "agt_new_agent",
  "tier_override": "B",
  "reason": "New agent -- all actions require human review until trust is established"
}

When an agent has a tier_override, all of that agent's actions are classified at the override tier or higher. The override acts as a floor -- if an action would normally be Tier A but the agent has a Tier B override, it becomes Tier B. If an action would normally be Tier C, it stays Tier C (the override does not lower tiers).

Tier Escalation Rules

Tiers can only escalate upward, never downward:

A (least restrictive) --> B --> C --> X (most restrictive)

Multiple factors can escalate a tier within a single evaluation:

Factor	Escalation
Low confidence scores	A to B, or B to C
Environment restriction policy	A to B, or A to C
Outside change window	A to B
Agent tier override	A to B (or higher)
CHAM policy violation	To C
SGP violation	To X

If multiple factors apply, the most restrictive result wins.

Tier Distribution Metrics

TheWARDN tracks the distribution of tiers across all governed actions. A healthy governance configuration typically shows:

Metric	Healthy Range	Concern
Tier A rate	60-80%	Too low = overly restrictive, too high = insufficient oversight
Tier B rate	15-30%	Too low = insufficient review, too high = bottleneck
Tier C rate	< 5%	High rate = agents consistently hitting policy blocks
Tier X rate	< 0.1%	Any non-zero rate = investigate immediately

These metrics are available on the governance dashboard and in exported compliance reports.

Tier System (A/B/C/X) ​

Tier Overview ​

Tier A: Autonomous ​

Tier B: Supervised ​

Tier C: Controlled ​

Tier X: Prohibited ​

Tier Mapping Configuration ​

Default Tier Mapping ​

Environment-Specific Overrides ​

Agent Tier Overrides ​

Tier Escalation Rules ​

Tier Distribution Metrics ​

Tier System (A/B/C/X)

Tier Overview

Tier A: Autonomous

Tier B: Supervised

Tier C: Controlled

Tier X: Prohibited

Tier Mapping Configuration

Default Tier Mapping

Environment-Specific Overrides

Agent Tier Overrides

Tier Escalation Rules

Tier Distribution Metrics