Enforcement Layer Reference

This page is a Reference. It describes the enforcement machinery. Consult it when you need to know exactly what a guard checks, what a gate validates, or what the audit log schema contains. For background on why enforcement works the way it does, see Understanding the VECTOR Architecture.

Enforcement Components

VECTOR's enforcement layer has four components:

Dispatch Guard

The Dispatch Guard runs before any PM or worker session is spawned. A spawn request that fails the Dispatch Guard is rejected. No spawn occurs.

Checks

Mode check

Reads state/vector-mode.json. Allowed spawn types per mode:

Hierarchy check

A Tier 1 PM attempting to spawn another PM is a Dispatch Guard violation. The spawn is rejected and the violation is logged to audit_log.

Ticket existence check

Every spawn must reference a valid ticket ID in state/vector.db. A spawn request with no corresponding tickets record is rejected.

OS scope check

Any spawn that requests browser, terminal, Peekaboo, or system configuration access is rejected unless the spawner is VECTOR (Tier 0).

Mode State File

Location: state/vector-mode.json

{
  "mode": "autonomous",
  "changed_at": "2026-02-27T00:00:00Z",
  "changed_by": "chief",
  "reason": null
}

Failsafe Triggers

State is preserved on all mode transitions. In-flight worker output is not discarded.

Gate System

Quality gates are checkpoints in the task lifecycle. Gates are not optional. A task that cannot present a gate ID for a required stage is not accepted as complete.

Gate A — Plan Review

When: Before any worker is spawned.

Inputs required:

• spec_path — path to the task spec markdown file
• pm_id — PM issuing the gate check

Checks performed:

Output on pass: Gate ID in format GATE-A-YYYYMMDD-NNN

Output on fail:

Gate A FAILED for [task description]:
  - [specific failure reason 1]
  - [specific failure reason 2]
Action: Address failures and resubmit.

Required usage: Gate ID must be embedded in the worker task spec as [GATE:GATE-A-YYYYMMDD-NNN]. Worker spawns without a Gate A ID are rejected by the Dispatch Guard.

Gate B — Code Review

When: After worker completes, before merge.

Inputs required:

• output_dir — path to the directory containing worker output
• pm_id — PM issuing the gate check

Review method: git diff main..task/TASK-xxx — the PM reviews the actual diff, not the worker's self-report or PTY output.

Checks performed:

Output on pass: Gate ID in format GATE-B-YYYYMMDD-NNN

Output on fail:

Gate B FAILED for [task description]:
  - [specific failure: file, line, reason]
  - [specific failure: file, line, reason]
Action: Address failures, resubmit Gate B.

Loop behavior: On Gate B failure, the PM sends specific fix requirements to the same Codex worker session. The loop continues until Gate B passes or timeout is reached (15 minutes per worker session).

Gate C — Integration Check

When: Before merge to main branch.

Inputs required:

• branch — the task branch name (e.g., task/TASK-20260226-010)
• pm_id — PM issuing the gate check

Checks performed:

Output on pass: Gate ID in format GATE-C-YYYYMMDD-NNN

CUSTOM_PATCHES.md conflict behavior: Any file listed in CUSTOM_PATCHES.md is automatically classified as DANGER. Gate C will not pass for a branch containing DANGER-classified changes without explicit Chief approval recorded in the ticket.

Gate ID Format

GATE-{TYPE}-{YYYYMMDD}-{NNN}

Examples:
  GATE-A-20260227-001
  GATE-B-20260227-014
  GATE-C-20260227-007

Gate IDs are unique across the system. They are stored in audit_log.gate_id for traceability.

Schema Validators

openclaw.json Validator

Location: scripts/validate-openclaw-config.js

When to run: Before any change to openclaw.json is saved. The gateway has no fallback on invalid config — a malformed config crashes the daemon on next restart.

Checks performed:

Output on pass:

✓ openclaw.json is valid
✓ No credentials detected in config
✓ All required keys present

Output on fail:

✗ Validation failed:
  - auth.profiles.anthropic.mode: "api-key" is not a valid mode. Use "api_key".
  - gateway.port: must be an integer, got string "18789"

BEE Belief Validator

When: Before any belief is written to state/vector.db.

Required fields:

Rejected conditions:

• source references a non-existent ticket ID
• status is anything other than provisional on write (PMs cannot create active beliefs)
• confidence is above 1.0 or below 0.0
• scope is global (PMs cannot create global-scope beliefs — only VECTOR can write global scope)

Audit Trail

Table: audit_log in state/vector.db

CREATE TABLE audit_log (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  timestamp   TEXT    NOT NULL DEFAULT (datetime('now')),
  actor       TEXT    NOT NULL,
  action      TEXT    NOT NULL,
  target      TEXT,
  result      TEXT,
  detail      TEXT,
  gate_id     TEXT
);

Action Types

Retention

Audit log records are never deleted. Monthly archival (midnight UTC, first of month) compresses records older than 90 days to state/audit_archive_YYYYMM.db. The primary audit_log table retains the trailing 90 days for fast queries.

Example Queries

# Last 20 actions
sqlite3 state/vector.db \
  "SELECT timestamp, actor, action, result FROM audit_log ORDER BY id DESC LIMIT 20;"

# All gate failures in the last 7 days
sqlite3 state/vector.db \
  "SELECT timestamp, actor, target, detail FROM audit_log
   WHERE action = 'gate_check' AND result = 'failed'
   AND timestamp > datetime('now', '-7 days');"

# All actions on a specific task
sqlite3 state/vector.db \
  "SELECT timestamp, actor, action, result FROM audit_log
   WHERE target LIKE '%TASK-20260226-010%'
   ORDER BY id ASC;"

# Dispatch violations this month
sqlite3 state/vector.db \
  "SELECT timestamp, detail FROM audit_log
   WHERE action = 'dispatch_violation'
   AND timestamp > datetime('now', 'start of month');"