# LifeOS Verification Doctrine: How Cross-Vendor Audit Works at E4/E5 Tiers

> Understand the LifeOS verification doctrine and its E4/E5 cross-vendor audit process. Learn how claims are verified through live-probe, advisor review, and independent LLM audits.

- Repository: [Daniel Miessler 🛡️/LifeOS](https://github.com/danielmiessler/LifeOS)
- Tags: deep-dive
- Published: 2026-08-12

---

**The LifeOS verification doctrine requires every claim to be anchored in concrete evidence through three stages—live-probe verification, Advisor review, and cross-vendor audit— with the E4/E5 cross-vendor audit performed by the Forge agent running on a different LLM vendor than the primary build agent.**

The **verification doctrine** sits at the constitutional layer of LifeOS, an open-source agentic operating system developed by Daniel Miessler. Rather than accepting outputs that "should work," the system enforces evidence-based validation before any claim is treated as true. This article explains the doctrine's three-stage structure and how the **cross-vendor audit mechanism** provides independent validation at the deepest effort tiers.

## What Is the LifeOS Verification Doctrine?

The verification doctrine appears in [`LIFEOS/LIFEOS_SYSTEM_PROMPT.md`](https://github.com/danielmiessler/LifeOS/blob/main/LIFEOS/LIFEOS_SYSTEM_PROMPT.md) as a governing constitution that overrides plain-Claude behavior. As described in [`LifeOS/install/LIFEOS/DOCUMENTATION/Algorithm/AscentStates.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/Algorithm/AscentStates.md) at **line 67**: *"Anchoring is the verification doctrine in one word"*—like a climber securing a hold before trusting body weight to it.

The doctrine operates through three linked verification stages:

1. **Live-probe verification** — Simple, automated checks performed during the **VERIFY** phase (real-browser snapshots, URL validation, file existence).
2. **Advisor calls** — The **Claude-Fable** model provides second-look review on high-impact work.
3. **Cross-vendor audit** — Independent audit at **E4/E5** tiers by an agent running on a different LLM vendor.

These stages nest within LifeOS's core algorithm flow:

```

OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN
                                           │
                                           ├─ Live-probe (simple checks)
                                           ├─ Advisor (Claude-Fable)
                                           └─ Cross-vendor audit (Forge audit-mode) ← E4/E5

```

## How Cross-Vendor Audit Works at E4/E5 Tiers

The **E4 (deep)** and **E5 (comprehensive)** effort tiers trigger optional but strongly recommended cross-vendor audits. This mechanism addresses a critical failure mode: LLM families share blind spots from training data, RLHF patterns, and formatting conventions.

### The Forge Audit Agent

**Forge** performs the cross-vendor audit in **audit mode**, as defined in [`LifeOS/install/agents/Forge.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/agents/Forge.md). Unlike primary build agents (Claude-family models), Forge runs on **OpenAI's GPT-5.6 Sol**—a completely different vendor stack.

This architectural separation matters because:

- **Shared biases are eliminated.** Claude models may consistently mishandle certain markdown formatting or code patterns due to shared training; Forge's distinct foundation spots these errors.
- **Builder ≠ auditor invariant is enforced.** When Claude builds, Forge audits. When Forge builds, a Claude-family Advisor provides cross-vendor review.

### Key Audit Rules

| Rule | Implementation |
|------|----------------|
| **Rule 2a** | Automatic auditor spawning based on builder identity; prevents self-audit |
| **E4/E5 optionality** | Algorithm elects audit when blast radius justifies cost; skipped audits require `Log` justification |
| **Schema-enforced output** | Forge returns structured JSON: `pass`, `concerns`, or `fail` |

The audit verdict flows into the ISA's **`## Verification`** section, as specified in [`LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md) (**lines 375-380**). Downstream gates—ISA-Close and Stop-Gates—read this section to determine completion.

## Implementing Cross-Vendor Audit in Practice

### Invoking the Audit from a Skill Script

In [`LifeOS/install/LIFEOS/TOOLS/CrossVendorAudit.ts`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/TOOLS/CrossVendorAudit.ts), the pipeline generates audit context, calls Forge, and parses results:

```typescript
// LifeOS skill script (e.g., a Build workflow)
import { runAgent } from "LifeOS/TOOLS/AgentInvocation.ts";

async function verifyAndBuild(isaPath: string) {
  // 1️⃣ Run the primary build (Claude-family)
  await runAgent({ subagent_type: "ClaudeResearcher", mode: "build", isa: isaPath });

  // 2️⃣ Invoke the cross-vendor audit (Forge in audit mode) – only executed at E4/E5
  await runAgent({
    subagent_type: "Forge",
    mode: "audit",               // forces read-only, cross-vendor verification
    isa: isaPath,
  });

  // 3️⃣ Record the audit verdict in the ISA's ## Verification section

  // (handled automatically by Forge → CrossVendorAudit.ts)
}

```

The **audit mode** flag enforces read-only behavior—Forge cannot modify files, only inspect and judge.

### Reading the Audit Result in an ISA

Post-audit, the **`## Verification`** section contains structured evidence:

```markdown

## Verification

- **Forge audit**: pass
- **Advisor**: ✅ verified by Claude-Fable
- **Live-probe**: ✅ Chrome screenshot captured

```

This block is automatically populated by [`CrossVendorAudit.ts`](https://github.com/danielmiessler/LifeOS/blob/main/CrossVendorAudit.ts) and stored in the `VERIFICATION/` memory folder. The ISA-Close gate checks this section before marking work complete; a `fail` verdict triggers revision, while `concerns` may require human escalation.

## Verification Doctrine File Reference

| File | Purpose | Key Location |
|------|---------|--------------|
| [`LIFEOS/LIFEOS_SYSTEM_PROMPT.md`](https://github.com/danielmiessler/LifeOS/blob/main/LIFEOS/LIFEOS_SYSTEM_PROMPT.md) | Constitutional verification doctrine | [Full doctrine](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/LIFEOS_SYSTEM_PROMPT.md) |
| [`README.md`](https://github.com/danielmiessler/LifeOS/blob/main/README.md) | Algorithm summary with E4/E5 audit mention | [Lines 301-308](https://github.com/danielmiessler/LifeOS/blob/main/README.md#L301-L308) |
| [`LifeOS/install/agents/Forge.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/agents/Forge.md) | Forge agent definition, build vs. audit modes | [Lines 3-5](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/agents/Forge.md#L3-L5) |
| [`LifeOS/install/LIFEOS/DOCUMENTATION/Algorithm/AscentStates.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/Algorithm/AscentStates.md) | "Anchoring" conceptual metaphor | [Line 67](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/Algorithm/AscentStates.md#L67) |
| [`LifeOS/install/LIFEOS/TOOLS/CrossVendorAudit.ts`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/TOOLS/CrossVendorAudit.ts) | Audit pipeline implementation | [Lines 3-5](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/TOOLS/CrossVendorAudit.ts#L3-L5) |
| [`LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md`](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md) | ISA structure, Verification section rules | [Lines 375-380](https://github.com/danielmiessler/LifeOS/blob/main/LifeOS/install/LIFEOS/DOCUMENTATION/ISA/ISAFormat.md#L375-L380) |

## Summary

- **The LifeOS verification doctrine** rejects "should work" assumptions in favor of concrete, anchored evidence.
- **Three verification stages** progressively increase rigor: live-probe (automated), Advisor (Claude-Fable second look), and cross-vendor audit (Forge at E4/E5).
- **Cross-vendor audit** runs Forge on GPT-5.6 Sol against Claude-family builds, breaking shared-blindspot risks through vendor diversity.
- **Rule 2a enforces builder-auditor separation** regardless of which agent performed the primary work.
- **Audit results flow into ISA Verification sections** as schema-enforced JSON, gating completion decisions.

## Frequently Asked Questions

### What triggers a cross-vendor audit in LifeOS?

The **Algorithm** elects to run a cross-vendor audit at **E4 (deep)** or **E5 (comprehensive)** tiers when a work item's blast radius justifies the cost. Skipping the audit is permitted but must be logged and justified in a `Log` row per [`Forge.md`](https://github.com/danielmiessler/LifeOS/blob/main/Forge.md) specifications.

### Why does Forge run on OpenAI instead of Anthropic models?

**Vendor separation eliminates correlated failures.** Claude-family models share training distributions, RLHF patterns, and formatting conventions. Forge's GPT-5.6 Sol foundation provides statistically independent error detection, catching blind spots that would persist across multiple Claude instances.

### What happens when a cross-vendor audit fails?

Forge returns **`fail`** or **`concerns`** via JSON verdict. A `fail` routes the ISA back to **BUILD** or **PLAN** phase for revision. `Concerns` may pause the ISA pending human review. Both results are recorded in the **`## Verification`** section and evaluated by ISA-Close gates.

### Can Forge ever audit its own work?

**No—Rule 2a prevents self-audit.** When Forge performed the build, a Claude-family **Advisor** automatically provides the cross-vendor second look. This invariant holds regardless of which agent type initiated the work, maintaining verification independence at all E4/E5 operations.