hawkes.aiKey ideas
- The one idea — R1 doesn't plan with a to-do list — it decomposes a job into a verifiable tree: a Statement of Work where Sessions run in sequence, Tasks are dependency-ordered, and Acceptance Criteria gate every session transition. A plan it can prove, not just promise.
- How it is shown — A prose job decomposing into R1's SOW tree — Sessions → Tasks → Acceptance Criteria — with a gate between sessions that won't open until the criteria pass.
- The trap to avoid — Treating a plan as a to-do list — a list of promises checkable only at the end. A SOW tree with AC-gated sessions is verifiable at every node.
- What it sets up — Each acceptance criterion is a claim the tree makes — so how does R1 actually verify one? it doesn't 'check,' it descends.
An agent's to-do list is a stack of promises checkable only at the end. The better shape is a tree where every step carries its own pass-fail test.
The one idea
R1 doesn't plan with a to-do list — it decomposes a job into a verifiable tree: a Statement of Work where Sessions run in sequence, Tasks are dependency-ordered, and Acceptance Criteria gate every session transition. A plan it can prove, not just promise.
Act ten turns from principles to a real system: R1, our runtime, built from everything the last act argued for. Start with how it plans. Not a to-do list — a tree it can prove. R1 decomposes a job into a Statement of Work: Sessions, Tasks, and Acceptance Criteria, arranged so "done" can be demonstrated, not just claimed. The Statement of Work has three tiers. Sessions run in sequence. Inside each, Tasks are dependency-ordered, so a task waits on what it needs first. And hanging off the work are Acceptance Criteria — the concrete conditions that define success. Structure at three scales, interlocking into one plan. Here's the mechanism that matters: those acceptance criteria gate the transitions between sessions.
How it works — the demo
A prose job decomposing into R1's SOW tree — Sessions → Tasks → Acceptance Criteria — with a gate between sessions that won't open until the criteria pass.
You can't advance until the current session's criteria are met. Progress isn't the agent feeling finished; it's contingent on verification. The plan has hard gates in its spine — moving forward means having proven the step behind you. Where does the tree come from? R1 converts your prose request into it: a semantic merge folds the intent together, a coverage review confirms nothing in the ask went unrepresented, then a final approval. The conversion is the point — a tree checked to cover what you asked for, not a plan that quietly drops the boring half. Why a tree and not a list? A flat to-do list is checkable only at the end — until then it's a bundle of promises. A gated tree is verifiable at every node: work happens when its prerequisites are real, and each session is proven before the next begins. Structure turns "done" from an assertion into something demonstrable.
The trap to avoid
Treating a plan as a to-do list — a list of promises checkable only at the end. A SOW tree with AC-gated sessions is verifiable at every node.
Why it matters — and what’s next
Each acceptance criterion is a claim the tree makes — so how does R1 actually verify one? it doesn't 'check,' it descends.
The trap: treating a plan as a to-do list. A ticked checklist is self-report — every box is a claim the agent made about its own work, the softness the last act warned about dressed up as progress. A SOW tree gates completion by criteria instead of the worker's say-so. The plan stops being a promise and becomes a proof structure. So R1 plans as a provable tree: sessions, tasks, acceptance criteria, hard gates between sessions, built from your prose. The plan is a proof structure, not a promise. But each acceptance criterion is itself a claim that must be made true. So how does R1 verify one? It doesn't just check it — it descends. Next: the T1 through T8 verification descent.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:45 of narration
Act ten turns from principles to a real system: R1, our runtime, built from everything the last act argued for. Start with how it plans. Not a to-do list — a tree it can prove. R1 decomposes a job into a Statement of Work: Sessions, Tasks, and Acceptance Criteria, arranged so "done" can be demonstrated, not just claimed.
The Statement of Work has three tiers. Sessions run in sequence. Inside each, Tasks are dependency-ordered, so a task waits on what it needs first. And hanging off the work are Acceptance Criteria — the concrete conditions that define success. Structure at three scales, interlocking into one plan.
Here's the mechanism that matters: those acceptance criteria gate the transitions between sessions. You can't advance until the current session's criteria are met. Progress isn't the agent feeling finished; it's contingent on verification. The plan has hard gates in its spine — moving forward means having proven the step behind you.
Where does the tree come from? R1 converts your prose request into it: a semantic merge folds the intent together, a coverage review confirms nothing in the ask went unrepresented, then a final approval. The conversion is the point — a tree checked to cover what you asked for, not a plan that quietly drops the boring half.
Why a tree and not a list? A flat to-do list is checkable only at the end — until then it's a bundle of promises. A gated tree is verifiable at every node: work happens when its prerequisites are real, and each session is proven before the next begins. Structure turns "done" from an assertion into something demonstrable.
The trap: treating a plan as a to-do list. A ticked checklist is self-report — every box is a claim the agent made about its own work, the softness the last act warned about dressed up as progress. A SOW tree gates completion by criteria instead of the worker's say-so. The plan stops being a promise and becomes a proof structure.
So R1 plans as a provable tree: sessions, tasks, acceptance criteria, hard gates between sessions, built from your prose. The plan is a proof structure, not a promise. But each acceptance criterion is itself a claim that must be made true. So how does R1 verify one? It doesn't just check it — it descends. Next: the T1 through T8 verification descent.