The Governance Pipeline

Every AI action that passes through TheWARDN follows a deterministic, auditable pipeline. This page describes each stage of that pipeline, from the moment an agent submits an action to POST /govern through to the sealed verdict and response.

Pipeline Overview

The governance pipeline is a fail-closed sequence of evaluation stages. If any stage encounters an error or cannot complete, the action is BLOCKED -- never silently approved. This is a foundational safety property.

                        POST /govern
                            |
                            v
                 +---------------------+
                 | 1. Governance Mode   |
                 |    Check             |
                 +---------------------+
                            |
              +-------------+-------------+
              |             |             |
           ENFORCED     AUDIT_ONLY    DISABLED
              |             |             |
              v             v             v
         (continue)   (continue,     (immediate
                       log only)    pass-through)
                            |
                            v
                 +---------------------+
                 | 2. Agent Status      |
                 |    Verification      |
                 +---------------------+
                            |
                            v
                 +---------------------+
                 | 3. CHAM Policy       |
                 |    Load              |
                 +---------------------+
                            |
                            v
                 +---------------------+
                 | 4. Decision Boundary |
                 |    Checks            |
                 +---------------------+
                 | - Sequence limits    |
                 | - Active grants      |
                 | - L6 model gov       |
                 +---------------------+
                            |
                            v
                 +---------------------+
                 | 5. Sentinel          |
                 |    Evaluation        |
                 +---------------------+
                 | 21 SGP principles    |
                 | Tier classification  |
                 | Confidence scoring   |
                 +---------------------+
                            |
                            v
                 +---------------------+
                 | 6. Audit Sealing     |
                 +---------------------+
                 | SHA-256 hash chain   |
                 | Monotonic seq number |
                 +---------------------+
                            |
                   +--------+--------+
                   |        |        |
                CLEARED   HELD    BLOCKED
                   |        |        |
                   v        v        v
               (return)  Escrow   Violation
                          Queue    Record
                   |        |        |
                   v        v        v
                 +---------------------+
                 | 7. Response          |
                 +---------------------+

Stage 1: Governance Mode Check

The first thing the pipeline checks is the tenant's governance mode. This determines how the rest of the pipeline behaves.

Mode	Behavior
ENFORCED	Full pipeline evaluation. Verdicts are binding. This is the default.
AUDIT_ONLY	Full pipeline evaluation, but all verdicts are overridden to CLEARED. Policies are tested without blocking agents.
DISABLED	No evaluation. Immediate pass-through. Use only during initial integration testing.

If the mode is DISABLED, the pipeline short-circuits and returns an immediate CLEARED response with no audit record. If the mode is AUDIT_ONLY, the full pipeline executes but the final verdict is always CLEARED regardless of what Sentinel decides -- the original verdict is still logged for analysis.

WARNING

DISABLED mode produces no audit trail. It should never be used in production. Governance modes can have expiration timers that auto-revert to ENFORCED.

Stage 2: Agent Status Verification

The pipeline verifies that the submitting agent is in a valid state to request governance decisions.

Agents have a status lifecycle:

active --> paused --> blocked --> deregistered --> identity_revoked

Only agents with active status can submit actions. If an agent is in any other state:

• paused: Action is BLOCKED with reason agent_paused. The agent should stop submitting until reactivated.
• blocked: Action is BLOCKED with reason agent_blocked. Administrative intervention required.
• deregistered: Action is BLOCKED with reason agent_deregistered. Agent must re-register.
• identity_revoked: Action is BLOCKED with reason identity_revoked. Permanent. The agent ID can never be reused.

Stage 3: CHAM Policy Load

The pipeline loads all applicable CHAM (Configurable, Hot-swappable, Auditable, Measurable) policies for the action. Policies are loaded in two scopes:

1. Tenant-wide policies -- apply to all agents in the tenant.
2. Agent-scoped policies -- apply only to the specific agent submitting the action.

Agent-scoped policies take precedence over tenant-wide policies when both exist for the same policy type. All loaded policies are attached to the evaluation context so Sentinel can reference them.

See CHAM Policies for the full list of policy types.

Stage 4: Decision Boundary Checks

Before Sentinel evaluates the action, the pipeline runs a set of fast boundary checks that can short-circuit the evaluation:

Sequence Limits

If the agent has exceeded its configured maximum actions per time window (rate limiting), the action is immediately BLOCKED with reason rate_limit_exceeded. This is enforced via Redis sliding window counters.

Active Grants

Grants are pre-approved permissions for specific action types. If the action matches an active, non-expired grant, it may be fast-tracked to CLEARED without full Sentinel evaluation, depending on the grant's scope. Grants have:

• A defined action type or pattern
• An expiration timestamp
• An optional scope (environment, target service)
• A maximum use count

L6 Model Governance

Layer 6 (Model Governance) checks whether the underlying model being used by the agent is approved for the requested action type. If the model is not in the approved list, or if the model's risk classification exceeds the action's tier, the action is BLOCKED with reason model_not_approved.

Stage 5: Sentinel Evaluation

This is the core of the governance pipeline. The Sentinel engine evaluates the action against:

1. 21 Sentinel Governance Principles (SGP) -- hardcoded, immutable rules that cannot be overridden by any policy.
2. CHAM policies -- the configurable rules loaded in Stage 3.
3. Tier mappings -- the action type's configured tier (A, B, C, or X).
4. Confidence thresholds -- the agent's reported confidence scores vs. configured floors.
5. Change windows -- whether the current time falls within an approved change window for the action type and environment.

Sentinel produces a verdict:

Verdict	Meaning
CLEARED	Action is approved. Agent may execute.
HELD	Action requires human review. Placed in escrow queue.
BLOCKED	Action is rejected. Agent must not execute.

The verdict includes:

• tier -- the resolved tier (A, B, C, or X)
• reasoning -- why this verdict was reached
• policies_fired -- which CHAM policies influenced the decision
• rule_violated -- if BLOCKED, which SGP or policy was violated
• confidence -- the evaluated confidence dimensions

See Sentinel Engine for the full evaluation logic.

Stage 6: Audit Sealing

Every governed action -- regardless of verdict -- receives a tamper-evident audit record. The audit record is sealed with:

• A monotonic sequence number (seq) that increments with every record.
• A SHA-256 hash computed from the action payload concatenated with the previous record's hash, forming a hash chain.
• A sealed_at timestamp.

This hash chain means that if any historical record is modified, all subsequent hashes will be invalid. The chain can be verified at any time via the verification endpoint.

Record N-1                    Record N                     Record N+1
+-----------+                +-----------+                +-----------+
| seq: 41   |                | seq: 42   |                | seq: 43   |
| hash: abc |---prev_hash--->| hash: def |---prev_hash--->| hash: ghi |
| payload   |                | payload   |                | payload   |
+-----------+                +-----------+                +-----------+

See Audit Trail & Hash Chain for full details.

Stage 7: Escrow, Violation, and Response

Based on the verdict, one of three paths executes:

CLEARED (Tier A)

The response is returned immediately to the agent with verdict: "CLEARED". The agent is authorized to execute the action.

HELD (Tier B)

The action is placed in the escrow queue for human review. The agent receives verdict: "HELD" with an escrow_id it can use to poll for the outcome. The escrow record has a configurable timeout (default: 10 minutes for B-tier, 30 minutes for C-tier). See Escrow Queue.

BLOCKED (Tier C or X)

A violation record is created with full context: the action, the rule or policy that was violated, the severity, and the Sentinel reasoning. The agent receives verdict: "BLOCKED" with the violation details. The agent must not execute the action.

TIP

The response always includes the seq (sequence number) and hash from the audit record, so the agent can independently verify that its action was recorded in the governance chain.

Request and Response Format

Request (POST /govern)

{
  "agent_id": "agt_abc123",
  "action_type": "code_deploy",
  "target_service": "payment-api",
  "environment": "production",
  "confidence": {
    "incident": 0.92,
    "fix": 0.87,
    "containment": 0.95
  },
  "reasoning": "Deploying hotfix for payment timeout bug #4521",
  "payload": {
    "commit_sha": "a1b2c3d",
    "branch": "hotfix/payment-timeout",
    "rollback_plan": "revert to v2.3.1"
  }
}

Response (CLEARED)

{
  "verdict": "CLEARED",
  "tier": "A",
  "reasoning": "Action type code_deploy is Tier A for agent agt_abc123. All confidence thresholds met. Within approved change window.",
  "seq": 1042,
  "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "policies_fired": ["confidence_floor_production"],
  "sealed_at": "2026-04-10T14:32:01.000Z"
}

Response (HELD)

{
  "verdict": "HELD",
  "tier": "B",
  "reasoning": "Action type code_deploy requires human approval for production environment.",
  "escrow_id": "esc_xyz789",
  "timeout_at": "2026-04-10T14:42:01.000Z",
  "seq": 1043,
  "hash": "d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592",
  "policies_fired": ["environment_restriction_production"],
  "sealed_at": "2026-04-10T14:32:01.000Z"
}

Response (BLOCKED)

{
  "verdict": "BLOCKED",
  "tier": "X",
  "reasoning": "SGP-17 prohibits autonomous deletion of production data without human authorization.",
  "rule_violated": "SGP-17",
  "seq": 1044,
  "hash": "4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce",
  "policies_fired": [],
  "sealed_at": "2026-04-10T14:32:01.000Z"
}

Pipeline Properties

Property	Guarantee
Fail-closed	Any error in any stage results in BLOCKED, never CLEARED.
Deterministic	Same input + same policies + same state = same verdict.
Auditable	Every action, regardless of verdict, gets a hash-chained audit record.
Non-bypassable	Sentinel cannot be disabled. Even AUDIT_ONLY mode runs the full pipeline.
Latency	Pipeline targets < 50ms for CLEARED verdicts (no escrow).