Governance Modes

Every tenant in TheWARDN operates in one of three governance modes. The mode determines whether governance verdicts are binding, advisory, or skipped entirely. Governance modes let you safely test and iterate on policies before enforcing them, and provide emergency escape valves when needed.

The Three Modes

Mode	Evaluation	Verdicts Binding	Audit Records	Use Case
ENFORCED	Full pipeline	Yes	Yes	Production operation (default)
AUDIT_ONLY	Full pipeline	No (overridden to CLEARED)	Yes	Testing policies without blocking agents
DISABLED	None	N/A (pass-through)	No	Initial integration testing only

ENFORCED Mode (Default)

ENFORCED is the default and intended operating mode. In this mode:

• The full governance pipeline executes for every action.
• Sentinel evaluates against all SGP principles and CHAM policies.
• Verdicts (CLEARED, HELD, BLOCKED) are binding -- agents must comply.
• All actions produce hash-chained audit records.
• Escrow is active for HELD verdicts.
• Violations are recorded for BLOCKED verdicts.

{
  "governance_mode": "ENFORCED",
  "set_at": "2026-04-01T00:00:00Z",
  "set_by": "admin@company.com",
  "expires_at": null
}

This is the only mode that provides full governance guarantees. All compliance claims, audit trail integrity, and regulatory coverage require ENFORCED mode.

WARNING

If your tenant is not in ENFORCED mode, your governance is not active. Compliance reports generated during non-ENFORCED periods will clearly indicate the governance mode, which may raise concerns during audits.

AUDIT_ONLY Mode

AUDIT_ONLY mode runs the full governance pipeline but overrides all verdicts to CLEARED. This means:

• Every action goes through the full evaluation -- SGP scan, tier resolution, confidence checks, CHAM policy evaluation, Sentinel reasoning.
• The actual verdict (what Sentinel would have decided) is computed and recorded.
• The effective verdict (what the agent receives) is always CLEARED.
• Full audit records are created, including the actual verdict.
• Agents are never blocked or held.

Why Use AUDIT_ONLY

AUDIT_ONLY is the primary tool for policy development and testing. It answers the question: "What would happen if I enforced these policies?" without actually blocking any agents.

Common use cases:

1. New policy testing: Create a new CHAM policy and observe its impact in AUDIT_ONLY mode before switching to ENFORCED.
2. Tier mapping calibration: Adjust tier mappings and see which actions would be HELD or BLOCKED, then fine-tune before enforcing.
3. Confidence floor tuning: Set confidence floors and observe how many actions would fail to meet them.
4. Initial onboarding: When first connecting agents to TheWARDN, run in AUDIT_ONLY to understand the action patterns before enforcing governance.

Audit Records in AUDIT_ONLY

Audit records in AUDIT_ONLY mode include both verdicts:

{
  "seq": 1042,
  "verdict": "CLEARED",
  "actual_verdict": "BLOCKED",
  "actual_tier": "C",
  "governance_mode": "AUDIT_ONLY",
  "reasoning": "[AUDIT_ONLY] Would have been BLOCKED: CHAM policy 'action_type_block' prohibits database_drop in production.",
  "policies_fired": ["policy_db_drop_block"],
  "rule_violated": "policy_db_drop_block"
}

The actual_verdict and actual_tier fields show what would have happened in ENFORCED mode. The governance_mode field makes it clear that this record was produced during AUDIT_ONLY operation.

Setting AUDIT_ONLY Mode

PUT /governance/mode
Content-Type: application/json

{
  "mode": "AUDIT_ONLY",
  "reason": "Testing new confidence floor policies before enforcement",
  "expires_at": "2026-04-12T00:00:00Z"
}

TIP

Always set an expires_at when switching to AUDIT_ONLY. This ensures the tenant automatically reverts to ENFORCED after your testing window, even if you forget to switch back manually.

Analyzing AUDIT_ONLY Results

After running in AUDIT_ONLY mode, query the audit trail to understand the impact:

GET /audit?governance_mode=AUDIT_ONLY&actual_verdict=BLOCKED

This returns all actions that would have been blocked, letting you assess whether your policies are calibrated correctly before enforcing.

Questions to answer before switching to ENFORCED:

Question	How to Check
How many actions would be blocked?	Count actual_verdict=BLOCKED records
Which agents are affected?	Group blocked records by agent_id
Which policies fire most often?	Aggregate policies_fired across all records
Are there false positives?	Review blocked records -- are any legitimate actions being caught?
What is the escrow volume?	Count actual_verdict=HELD records to estimate reviewer workload

DISABLED Mode

DISABLED mode bypasses the governance pipeline entirely. No evaluation occurs. Every action receives an immediate CLEARED response.

• No Sentinel evaluation.
• No CHAM policy checks.
• No audit records created.
• No escrow.
• No violation tracking.

{
  "governance_mode": "DISABLED",
  "set_at": "2026-04-10T12:00:00Z",
  "set_by": "admin@company.com",
  "reason": "Initial integration testing -- verifying agent connectivity",
  "expires_at": "2026-04-10T13:00:00Z"
}

WARNING

DISABLED mode provides zero governance. No audit trail is produced, which means there is no evidence of what agents did during this period. Use this mode only for initial connectivity testing and never in production.

When DISABLED is Appropriate

The only legitimate use case for DISABLED mode is initial integration testing -- verifying that an agent can successfully send requests to POST /govern and receive responses. Once connectivity is confirmed, switch to AUDIT_ONLY for policy testing, then to ENFORCED for production.

Integration workflow:

DISABLED ──(connectivity verified)──> AUDIT_ONLY ──(policies calibrated)──> ENFORCED
   |                                       |                                    |
 Minutes                               Hours/Days                          Permanent

Mode Expiration

All governance modes support an optional expires_at field. When the expiration time is reached, the mode automatically reverts to ENFORCED.

PUT /governance/mode
Content-Type: application/json

{
  "mode": "AUDIT_ONLY",
  "reason": "24-hour policy testing window",
  "expires_at": "2026-04-11T12:00:00Z"
}

When the mode expires:

1. The mode is set back to ENFORCED.
2. An audit record is created noting the automatic revert.
3. All subsequent actions are fully governed.

This prevents a common risk: switching to AUDIT_ONLY or DISABLED for testing and forgetting to switch back.

Mode	Expiration Recommendation
ENFORCED	No expiration needed (this is the default/permanent state)
AUDIT_ONLY	Always set an expiration. Recommended: 24-72 hours.
DISABLED	Always set an expiration. Recommended: 1 hour maximum.

Mode Transitions

          +-----------+
    +---->| ENFORCED  |<----+
    |     +-----------+     |
    |          |  |         |
    |          |  +-------->+
    |          v            |
    |   +------------+      |
    +---| AUDIT_ONLY |------+
    |   +------------+      |
    |          |            |
    |          v            |
    |    +----------+       |
    +----| DISABLED |-------+
         +----------+

All transitions are bidirectional. You can move from any mode to any other mode. However, the recommended path is:

1. DISABLED (brief connectivity test)
2. AUDIT_ONLY (policy calibration)
3. ENFORCED (production operation)

Going backward (ENFORCED to AUDIT_ONLY or DISABLED) should be done with caution and always with an expiration timer.

Every mode transition is recorded in the audit trail with the set_by user, the reason, and the timestamp.

Checking Current Mode

GET /governance/mode

Response:

{
  "mode": "ENFORCED",
  "set_at": "2026-04-01T00:00:00Z",
  "set_by": "admin@company.com",
  "reason": "Production governance active",
  "expires_at": null,
  "history": [
    {
      "mode": "AUDIT_ONLY",
      "set_at": "2026-03-30T10:00:00Z",
      "set_by": "admin@company.com",
      "reason": "Pre-launch policy testing",
      "expired_at": "2026-04-01T00:00:00Z"
    },
    {
      "mode": "DISABLED",
      "set_at": "2026-03-30T09:00:00Z",
      "set_by": "admin@company.com",
      "reason": "Initial agent connectivity test",
      "expired_at": "2026-03-30T10:00:00Z"
    }
  ]
}

The history array shows the complete mode transition history, providing a full record of when governance was active, testing, or disabled.

Best Practices

1. Default to ENFORCED: Treat ENFORCED as the permanent state. Other modes are temporary deviations with expiration timers.

2. Use AUDIT_ONLY liberally for testing: There is no cost to running in AUDIT_ONLY mode -- it produces the same audit records and evaluation as ENFORCED, just without blocking agents. Use it to test every policy change.

3. Never use DISABLED in production: DISABLED mode produces no audit trail. Any period of DISABLED operation is a gap in your governance record that will be visible in compliance reports.

4. Always set expirations on non-ENFORCED modes: This prevents the "forgot to switch back" scenario, which is one of the most common governance failures.

5. Monitor mode transitions: Set up alerts for governance mode changes, especially transitions away from ENFORCED. Every mode change should be intentional and documented.

6. Review AUDIT_ONLY results before enforcing: Do not switch directly from AUDIT_ONLY to ENFORCED without reviewing the audit data. Check for false positives, excessive blocks, and policy conflicts first.