Defense-in-Depth: Agent Rule Compliance After Truncation (v1.5.4)

AI Agents in long conversations experience context truncation — the platform drops earlier context to stay within token limits. When this happens, the agent silently loses all rules loaded at session start.

PARA Workspace implements a 4-layer Defense-in-Depth strategy to ensure rule compliance survives truncation. No single layer is perfect; the strength lies in their combination and independence.

The Core Problem: Circular Dependency

Rules tell the agent to re-read rules when context is lost. But if the agent has lost context, it has also forgotten the rule that tells it to re-read rules:

Agent loses context → Forgets "re-read rules" rule → Doesn't re-read → Violates rules

This circular dependency is why a single-layer approach fails. Each layer below addresses this from a different angle.

4 Layers of Protection

Layer 1: Rule File — Context Recovery Protocol

File: agent-behavior.md §4

The agent is instructed to re-read .agent/rules.md when it detects context decay. Detection signals:

1. Truncation notice — platform explicitly says context was truncated
2. Forgotten rules — agent can’t recall specific rule details
3. Long conversation — session exceeds typical length

Recovery chain: Detect decay → Read workspace rules.md → Read project rules.md (if has_rules: true) → Load specific rule files on demand.

File-Level Guards table maps file patterns to rules that MUST be re-read before editing:

Extensible: Project rules MAY define additional guards in Projects/<name>/.agent/rules.md.

Strength: Covers workflow bypass (direct file edits). Two-Tier loading saves ~90% tokens.

Weakness: Passive — depends on agent recognizing it has lost context (circular dependency).

Layer 2: Workflow Output — Safety Block

File: /open Step 8 report template

The /open report includes a compact rules reminder (~40 tokens) positioned near the end of the report output. This placement is strategic:

/open report output:
  ┌─────────────────────────────────┐
  │  📋 Project status             │  ← Truncated first (oldest)
  │  📊 Backlog summary            │
  │  🛡️ SAFETY BLOCK              │  ← Survives longest (newest)
  └─────────────────────────────────┘

Safety Block content (3 lines, principle-based):

🛡️ SAFETY (persist across truncation):
- Git: Do NOT merge/branch/tag without user approval.
- Governance: Do NOT modify kernel/ or .para/.
- Recovery: If rules feel incomplete → re-read .agent/rules.md

Why only /open? Other workflows have Layer 3 (Pre-flight). /open is the session-start workflow that generates the baseline context — the only output that persists across the entire session.

Strength: Persists in checkpoint summaries. Zero agent effort required.

Weakness: General reminder only. Platform-dependent — truncation strategy varies.

Layer 3: Workflow Pre-flight — Step 0

Files: 7 workflows with side-effects

The only layer that breaks the circular dependency:

Agent runs /push → Step 0 FORCES re-read rules.md → Rules restored → Safe execution

Step 0 is a mandatory first step in workflows that perform side-effects:

Why it works: The agent reads the workflow file from disk → sees Step 0 → executes it → rules are loaded fresh. No dependency on agent memory.

Why Step 0? Before any other step. If placed at Step 3, Steps 1-2 would execute unprotected.

Strength: Active protection. Breaks circular dependency. Fresh from disk.

Weakness: Only triggers when agent uses a workflow. Direct file edits bypass this.

Layer 4: File Guard Headers ⭐

Files: Protected files across the workspace

The strongest layer — based on the Proximity Principle: the guard is embedded in the file the agent must open before editing.

4 Guard Types:

Position convention:

• Files with YAML frontmatter: guard goes after closing ---, before # Title
• Files without YAML: guard goes after # Title (line 3)

Why it’s the strongest:

1. Zero dependencies — no memory, no workflow, no platform needed
2. Proximity Principle — closest to the violation point
3. Hidden when rendered — HTML comments don’t affect document appearance
4. Token-compact — ~10-13 tokens per guard

Defined as constraint C6 in hybrid-3-file-integrity.md.

Strength: Works even when agent has lost ALL context. Covers kernel, rules, tasks, and workspace files.

Weakness: Only protects files that have guard headers. Pre-v1.5.4 projects need migration.

Coverage Matrix

Action                          L1   L2   L3   L4
──────────────────────────────  ──   ──   ──   ──
Agent runs /push                ⚠️   ✅   ✅   —
Agent runs /end                 ⚠️   ✅   ✅   ✅
Agent edits done.md directly    ✅   —    —    ✅  ← L4 is the last defense
Agent modifies kernel file      ✅   ✅   —    ✅
Agent edits rules file          ✅   —    —    ✅
Free-form request (no workflow) ⚠️   —    —    ✅  ← Only L4 catches this

Each layer catches what the previous one missed, creating a safety net with minimal gaps.

Token Budget

Total footprint: ~300 tokens/session (~3-5% of session budget). Negligible cost for comprehensive protection.

File Map

References

• Agent Behavior §4 — Context Recovery + File-Level Guards
• Hybrid 3-File Integrity C6 — File Guard Headers
• Context Rules Rule #4 — File Guards format specification
• Rule Layers & Trigger Index — Two-Tier loading + workflow coverage
• Hybrid 3-File Architecture — C6 guard headers

→ Learn: Rule Layers & Trigger Index → Learn: Hybrid 3-File Architecture → Learn: Kernel Architecture