# Reverse Tornado Okr

> Plan or run a measured goal loop with anti-goal guardrails. Planning mode drafts metrics, discovery, and work structure without changing the workspace. When the user asks to run, delegate, automate, or resume the loop, execution mode may run bundled local helper scripts, write durable `.okra` records, spawn subagents, and optionally route writer work through an already-installed Codex or Claude CLI. Use for OKRs, metric-led improvement, bounded research, or progress that must preserve budget, quality, safety, trust, or another measured constraint. All actions remain inside the user's request and runtime permissions; the skill does not install tools, add credentials, grant authority, or contact external services on its own.

- Skill: `lagz0ne/reverse-tornado-okr` (Agent Skill, multi-file: 48 files)
- Install (CLI): `npx skillmds@latest add lagz0ne/reverse-tornado-okr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lagz0ne/reverse-tornado-okr/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: lagz0ne (https://skillmd.com/u/lagz0ne)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lagz0ne/reverse-tornado-okr

---


# The Reverse Tornado - running a goal as a self-correcting loop

This skill is a workflow. Give it any goal. It sets the goal up so an LLM can do most of the work
while a human keeps the direction.

Picture a reverse tornado. On day one you guess wide. Each loop narrows the guessing into known
work. A wall you cannot cross bounds every loop - that wall is the anti-goal. The loop stops when
the metric hits its target.

Apply the steps below in order. Do not skip the anti-goal. It is what makes the rest safe.

## Choose the operating mode

Default to **planning mode**. Draft the frame and loop in the requested output only. Do not run
helpers, create `.okra`, spawn workers, or call another model CLI merely because the skill loaded.

Use **execution mode** only when the user asks to run, delegate, automate, or resume the loop, or
when a repository's own instructions require the operating workflow for the requested change.
Before acting, keep the footprint clear:

- Bundled helpers read and write local files. They do not make network calls.
- Durable state lives under `.okra` only when that path is allowed. A stored permission record does
  not grant permission that the user or runtime did not grant.
- Subagents receive scoped packets and cannot expand their own authority.
- An installed Codex or Claude CLI is optional. Do not install it, authenticate it, or invoke it
  outside the user's requested delegated workflow. State which external model path will be used.
- Never send repository content, run evidence, or credentials to another service unless the user
  requested that model path and the runtime permits it.

If the requested output is only advice, a plan, or an OKR draft, stay in planning mode.

## Write plainly

Answer first. Use common words. When a choice needs context, show one concrete example or analogy,
then ask one clear question. Stop when the choice is clear. Skip praise, filler openings, soft
lead-ins, and abstract terms when a plain word works.

Example: "DKR-1 creates CKR-1, so we save that link. Should every link stay in history?"

Writing wall: `plain_wording_violation_count == 0`. It covers skill wording and new OKRA text
artifacts, not product source, data, or preserved model-dialect fixtures. Run the
`scripts/check-plain-wording.py` beside this `SKILL.md` on the changed text files. In an injected
Codex project, for example:
`python3 .codex/skills/reverse-tornado-okr/scripts/check-plain-wording.py <changed OKRA text files>`.
Judgement calls still need human or independent review.

## Step 1 - Draft the frame (metric + target, and the wall)

When you get a goal, mission, improvement, or research request, draft the frame first. Do not wait
for the user to phrase it as an OKR. Propose a **candidate objective**: the metric that would prove
success, a target or range when the facts support one, and a short note on why that metric is the
right proof. For research, the first objective can be about the decision itself - "reduce
uncertainty enough to decide X" - measured by confidence, decision readiness, evidence coverage, or
risk retired. Keep it candidate until the intended outcome, metric, and limits are recorded clearly
enough to run. Human input helps define that intent; it is not proof that the frame or approach is
correct.

Pin two things before any planning:

- **Objective**: a metric with a target number, not a vibe. "Grow monthly sales to $500k", not
  "do better at sales". If the goal is vague, propose the metric that would prove it, say it is a
  candidate, and record the user's intended outcome before any state-changing move.
- **Anti-goal**: the thing you must not sacrifice, with **its own metric**. "Keep monthly expense
  at or under $80k." It is either continuous (a drift gauge you watch) or binary (a tripwire that
  halts). Say which.

Anti-goals may carry across runs. If none is named, propose fit-for-purpose walls for budget, quality,
trust, safety/privacy, authority, time, storage, eval regression, stale memory, and single-LLM truth.
Give each a metric and an activation condition at approach, plan, or task level. Include relevant
non-functionals such as observability, recovery, performance, operability, and testability. Freeze
thresholds for the run; only the human changes them in a new frame. Lifecycle detail:
`references/matched-abstraction.md`.

OKRA always carries one inner integrity anti-goal, even if the user does not set one:
`anti_goal_bypass_or_dishonesty_count == 0`. It does not replace the user's domain anti-goal. It
stops the loop from bypassing, weakening, hiding, or faking the anti-goal machinery itself. Hitting
the objective by getting around the wall is not a valid OKRA success.

The frame moves **candidate -> recorded working**. Human input records intent and constraints, not
effectiveness; metrics show outcomes and DKRs reduce unknowns. Contradiction opens a frame review;
the objective and walls never change silently. Unmeasured harm is the cheapest way to hit a goal, so
a goal without a named wall is not a valid success. Delegated loops also record an **action envelope**:
allowed moves, forbidden moves, limits, data boundaries, approval gates, rollback, and coverage of
harms considered and rejected. Coverage also names non-negotiable tripwires, owners, review cadence,
and what it does not cover. A metric-safe move can still be outside authority. One measured wall is
required.

Every anti-goal you confirm must be **readable or funded to become readable**: it carries either (a) a
metric with a working read method, or (b) a named **reducing DKR** funded to make it readable. A wall
you cannot read is not a wall, so an anti-goal with neither cannot be confirmed. The coverage review
lists each confirmed wall's status; delegated artifacts emit it as a commanded compact line that starts
**"Anti-goal coverage:"** naming each wall -> `readable` | `reducing-DKR <id>`. Metric shape:
`anti_goal_coverage_gap_count == 0` - an unreadable, unfunded wall is a coverage gap.

Any delegated, audited, or reused wall must be executable: record metric id, threshold, type, source,
method, freshness, evidence refs, replay checker, all three eval-point traces, and the fail-closed
flag. Reject invalid, superficial, tautological, false-positive, unsupported, or assertion-only
claims (`invalid_anti_goal_acceptance_count == 0`, `superficial_anti_goal_acceptance_count == 0`,
`tautological_anti_goal_acceptance_count == 0`, `false_positive_anti_goal_acceptance_count == 0`,
`unsupported_claim_acceptance_count == 0`, `single_llm_truth_acceptance_count == 0`, and
`anti_goal_bypass_or_dishonesty_count == 0`). Full fields: `references/executable-claims.md`.

## Step 2 - Know the three units

Break work into exactly three kinds. Keep them separate. Blurring them is where these systems rot.

- **DKR - Discovery.** A scoped probe at one uncertainty, not generic research. It names the
  steering decision it unlocks, the risk or anti-goal uncertainty it reduces, a turn/time budget,
  stop rule, evidence, confidence, candidate CKRs, and next unknowns. It returns a learning
  checkpoint or a replayable empty result.
  **Candidate CKRs and candidate PKRs are not promoted until the orchestrator accepts the supporting
  DKR learning checkpoint.** An executable checkpoint names `conclusion_id`, `decision_target`,
  `source_of_truth`, `read_method`, freshness quartet, numeric `confidence`, `evidence_refs_or_hashes`,
  `replay_command_or_checker`, answered/unanswered questions, decision, and fail-closed flag. It also
  carries `active_anti_goals`, complete `active_anti_goal_verification`, and `wall_gate`; every wall
  must be fresh and `held` before downstream work. Missing, stale, contradicted, or non-replayable
evidence blocks it, including wrong-source evidence. Raw inline commands are not replay checkers. See
  `contracts/executable-dkr-checkpoint.v1.json` and `references/executable-claims.md`. If a terminal
  record cites the checkpoint, bind the canonical checker and replay result by path and hash as shown
  in `references/integrity-store.md`; a script path alone is not terminal proof.
- **CKR - Contribution / Key Result.** Measurable, with its own metric. This is what counts toward
  the objective. A CKR is **context and measurement, not a worker job**. It tells the orchestrator
  which contribution would matter and what direct metric proves it. It is never dispatched as work.
  Each CKR carries its own mini reverse tornado: what discovery makes the contribution meaningful,
  what direct CKR metric proves movement, and what delivery path becomes PKR work once the
  uncertainty drops.
- **PKR -> task - Progression.** Known work: do-and-check, no discovery. Emit progress signals as
  governed append-only events (hand-back, regression, rework, late discovery, empty DKR, ungoverned
  write); counters are derived by `okra-store.sh counts`, never typed. Each PKR carries its activated
  walls. In delegated output put **"active anti-goals:"** on its own line with metric ids and reasons;
  a done claim needs target plus fresh verified walls in the same `claim_acceptance` record:
  `active_anti_goals`, complete `active_anti_goal_verification`, and `wall_gate`. See
  `references/integrity-store.md` and `references/matched-abstraction.md`.

The abstraction levels are `approach ~ DKR`, `plan ~ CKR`, `task ~ PKR`. Each DKR names its returned
approach artifact; it grows while the hypothesis holds and is decommissioned when it goes off-track.
See `references/matched-abstraction.md`.

## Step 2b - Two roles: orchestrator and workers

The loop runs as an **orchestrator** directing disposable **workers**. This split carries the
authority lines. Each tier hands control *up* when it reaches the edge of its authority.

**Orchestrator - the loop's brain.** Only the top-level main session runs it; never dispatch the
orchestrator as a worker. Only it talks to the human; only the human changes the frame. It holds the
read-only frame, owns objective checks, the OKR board,
check-ins, three-point wall evals, budgets, flags, and subagent steering. It accepts DKR learning
only when the checkpoint makes the next steering decision safer or clearer, before CKR/PKR promotion;
it does not execute worker tasks or edit the frame. It does not stop when the board or worker queue is
complete. It keeps checking and dispatching **until the objective metric reaches target**, a human
changes/stops the frame, or a blocking flag needs resolution.

**Workers - the hands.** Scoped, disposable, parallelizable: discovery, progression, verification,
and challenger. CKR stays orchestrator-owned context.

- **Discovery** runs one DKR and returns its checkpoint; **progression** runs one PKR.
- **Verification** deterministically replays a claim and returns an audit trace, never judgement
  (`references/roles/validator.md`); separate writing and verification protect
  `single_llm_truth_acceptance_count == 0`.
- **Challenger** returns `intact | drifted | dead` for each live hypothesis, never a decision
  (`references/roles/challenger.md`). Use it only at hypothesis-touching junctures.

The main worker rule: **a worker that hits an unknown mid-run does not improvise - it hands back to
the orchestrator**. Workers stay within scope, do not screen their own wall cost, call the human, or
change scope.

Long runs write `.okra/runs/<run-id>/workers/<worker-id>/progress.jsonl` at finish, unknown, and
heartbeat; ten minutes is the default. In delegated output use these commanded lines:
**Worker progress:** `.okra/runs/<run-id>/workers/<worker-id>/progress.jsonl`, written at each worker
finish, unknown hit, and heartbeat. **Heartbeat cadence and next_check_at:** ten minutes by default,
with the next scheduled check recorded.

Every worker dispatch is a **worker prompt packet**, not a raw chat continuation. It carries
`frame.objective`, `frame.anti_goals`, `active_anti_goals`, `frame.action_envelope`,
`frame.human_confirmation_boundary`, `current_state`, `previous_dkr_checkpoint`, `assignment`,
`budget_and_stop_rule`, `hand_back_rule`, and `output_schema`. The full wall set is context; the
activated subset gates the unit. **In-progress worker narrative is not evidence; only worker progress,
check-ins, metric reads, flags, or accepted checkpoints can influence the next dispatch.**

Use **generic subagent spawning** with no custom agent definitions or plugins, and the verbatim
canonical role header from
`references/roles/orchestrator.md`, `writer.md`, or `validator.md`; if unavailable, run the same
template as a sequential role-switched pass and still write worker evidence. Run `okra-preflight.sh`
at start and record its transport.

If preflight reports `cross_model_writer`, a GPT writer may use the same `writer.md` packet while
verification stays on the session model; this strengthens `single_llm_truth_acceptance_count == 0`
but is optional.

Delegated output hard gates: `Action envelope:` allowed and forbidden moves plus the permission
owner; `Anti-goal coverage:` each wall -> `readable` | `reducing-DKR <id>` with
`anti_goal_coverage_gap_count == 0`; `CKR-level discovery/delivery balance:` the discovery side and
delivery path; `progress signals:` the events that steer the next check-in; `active anti-goals:`
activated wall ids and reasons; `Introspection cadence:` checkpoint, flag, descent, terminal, and
every-third-check-in triggers; `Standing walls:` walls that remain after terminalization and their
human-only retirement rule. Use this exact sentence: **"DKRs are discovery-worker scopes; PKRs are
progression-worker execution units; there is no CKR worker."**

Detect the model from harness ID/env, never self-report, and phrase packets accordingly; contracts
do not change by model. Delegated output must carry **"Model phrasing:"** with detected id, source,
and the quoted matching `Phrasing profile id` from `references/models/`; unknown models use
`references/models/README.md`. The id is the read-proof.

In delegated/scored loops, each packet records a rough write-once estimate and the actual at finish;
the pair feeds `est_overrun_ratio` and `estimation_calibration_error`. Light goals may skip it.
Details: `references/integrity-store.md` (Estimation Records).

The authority gradient:
`human owns the frame -> orchestrator works inside it and makes the loop's calls -> workers execute
inside their scope and hand back at their edge.`

## Step 2c - Make the run idempotent (set up storage first)

For any delegated, recurring, or side-effecting run, initialize storage before a move and stay inside
the allowed write scope; if the user or harness permits one output file, do not create an extra `.okra`
run store. The frame is
write-once; the tree is a generated view of node/edge events; moves are write-once by stable
idempotency key; metric reads, flags, check-ins, and worker progress are append-only. The
orchestrator checks a key before dispatch and records its result after. A known key replays its stored
result instead of repeating the effect.

**Write the record before the prose.** For every claim class with a contract under `contracts/`, fill
every field, write the record, and make the narrative cite its seq, hash, or path. A cited worker
ref must resolve to `.okra/runs/<run-id>/workers/<worker-id>/progress.jsonl#seq=N`; prose is never a
record. Write through the store helper, or a target path plus content hash; avoid ungoverned reads and
writes. Use content hashes for important inputs and `okra-store.sh scan` to make resume complete.

**Storage integrity:** append-only records are the source of truth; status/progress files are generated
views; claims are accepted only on independent deterministic evidence, not one LLM's say-so.

Use `.okra/runs/<run-id>/` for mutable state and shared `.okra/content/sha256/` for blobs. Concurrent
runs must not share a ledger, flags, check-ins, workers, move results, or status view. Run
`okra-preflight.sh` at start and record its `{"transport", "subagents", "detected_via"}` verdict.
Keep the exact frame/tree schema and `orchestrator` ownership of **objective checks** and
**subagent steering** from `references/integrity-store.md`. A human input that changes intent,
threshold, envelope, or denominator bumps `frame_version` before the move. A propose-cost dry-run
has no side effect and needs no key; only the committing move is keyed. Verify before resume or
success. Full layout, helper commands, and metric-read shape: `references/integrity-store.md`.

### Bounded escape routes

An escape route may change how work runs, never how a claim is accepted. Public v1 enables
`bounded` and candidate-only `deferred_candidate`. `verified_reuse` and effect-committing
`emergency_stop` need a separate integration-owned signed receipt; otherwise use the full path or
record a stop-request candidate. Use `contracts/escape-hatch-decision.v1.json` and
`references/escape-hatch.md`; copy their exact shapes instead of inferring nested fields.

A bounded writer does not prove its own budget, base, evaluator, result, usage, or trust-wall zero.
Require the runner's signed authority and receipt, a checker-derived wall read, a live complexity
contract, and its recomputed post value. Bind the runner's fresh invocation ID through the request,
decision, outcome, and receipt; authority runs require bwrap. The runner proves one outer writer
invocation and one final candidate evaluation, not hidden calls inside the writer. Freshness is
`observed_at <= ledger recorded_at <= decision or outcome time`. Missing or changed proof falls back
to full. `keep_candidate` still needs normal objective, wall, and independent-evidence gates.

## Step 2d - Keep the run fresh and learn at check-ins

Before dispatch, define each objective, CKR, and anti-goal read: source, owner, definition, method,
`observed_at`, `recorded_at`, `fresh|stale`, and `max_age`. Every round writes `current_round`, open
flags, the last read, and `next_check_at`. Refresh stale data or fund a DKR; approval cannot make it
fresh. Run admissibility before a move, direct reads after it, and the paired goal/wall read at
progress time.

For delegated work, check in on worker finish, unknown, flag, and a ten-minute heartbeat. Each
check-in records estimate vs actual (`est_overrun_ratio`), steering value (`no_value_checkin_count == 0`),
four sweeps (`hallucination_sweep`, `missing_context_sweep`, `unexpected_results`,
`anti_goal_violation_review`) with `{claim, evidence_ref, verdict}` (`unchecked_claim_count == 0`), and an `uncertainty_5why` ending
in a `reducing_dkr` or `none-open`. Record `problem_restatement`, `evidence_delta`,
`alternatives_considered`, `assumptions_at_risk`, and `dkr_decision`; empty review is
`empty_first_principles_review_count == 0`. Threshold crossings create provenance-backed candidate
`reinforcement_record`s; current evidence and a recorded frame review are required before promotion.

At DKR acceptance, a flag, descent before task commitment, terminalization, or every third check-in,
run introspection: matched-abstraction violation review (`unleveled_violation_count == 0`); an
independent challenger verdict `intact | drifted | dead`; target selection; a Socratic packet with
`This round shapes:` and 3-6 evidence questions (`target_undeclared_packet_count == 0`); then next
DKR/CKR/PKR packets and dead-hypothesis decommissioning (`unjustified_node_contribution_count == 0`). The
orchestrator cannot self-certify a node or hypothesis. Details: `references/operating-loop.md`,
`references/introspection.md`.

## Step 2e - Learn, heal, and reuse memory

Allocate DKR budget where uncertainty blocks safe steering. Keep candidate CKRs/PKRs unpromoted until
accepted learning, and treat flags, vetoes, flat metrics, unknowns, and exhausted budgets as steering
evidence. At run start, run `okra-store.sh anti-goals .okra` and `init-run`; review every snapshot
candidate as `keep` or `drop` with a reason, evidence refs, and shaped nodes
(`prior_anti_goal_review_gap_count == 0`).

Learning stays candidate-only until current evidence supports a frame review. A reinforcement needs
`context_key`, trigger, `event_refs`, candidate anti-goal, status, and `no_regression`; missing refs
are `reinforcement_without_provenance`. A DKR may mint a run-local wall, but later frames keep, change,
or drop it only from fresh evidence and a recorded reason.

Terminalize only after recording terminal state, objective and wall reads, flags, accepted
checkpoints, retained traces, continuation packet, and second-opinion evidence. **Classify each
frame anti-goal** `retired_with_run` or `standing` (**standing is the default**); terminal “all held”
is a **point-in-time read, not a discharge**, and a later touch reactivates the wall. Human-only
context retirement ends it. Do not terminalize with unverified run-local candidates or artifacts from
a dead hypothesis. Keep reusable candidates in `candidate-anti-goals.v1.json`, never hidden defaults.

After consolidation, run `okra-store.sh doctor` and `okra-store.sh doctor --json <run-store>`.
Preview cleanup only for a verified, terminalized, consolidated run. Pack preview is read-only;
v1 pack apply stays limited to disposable fixtures. The `real-run-apply.v2` overlay permits one
explicitly authorized named run and one exact cooldown waiver. Its packet binds the root and run
device/inode, current tree and log tails, fresh doctor state, the waived cooldown timestamp,
all non-target/shared-content hashes, projected reduction, contract and confirmation hashes, and a
one-shot nonce. Any other blocker or target remains read-only, and replay is refused. Public
mutators, including managed `.gitignore` install, share persistent root/run lifecycle locks; pack
and cleanup apply take both exclusively. Write targets may not alias the OKRA root, and a verified
packed run refuses later writes. For a
large source checkpoint, use one `change-set record` manifest instead of copying source files or
appending one ledger event per path. On a post-terminal edit to a standing-wall artifact,
re-read the standing set, record admissibility by metric id, record the frame input before editing,
open a successor inheriting the walls, and take the paired goal/wall read after editing. Details:
`references/learning-memory.md`, `contracts/real-run-apply.v2.json`,
`contracts/run-lifecycle-lock.v1.json`, and
`references/matched-abstraction.md`.

The helper offers this retention best practice during the run. `init-run`, `status`, and
`write-terminal` print read-only retention advice to stderr, so their stdout contracts stay stable.
The script-owned default reviews storage at 40 durable files: keep active work intact, use one
change-set manifest for large checkpoints, and offer cleanup as soon as terminal consolidation is
present. Cleanup remains preview-first; deletion still needs explicit `cleanup --apply`.

## Step 3 - No cascade: read the real metric

The tree of work is **scaffolding, not scoreboard**. The only score that counts is the **direct
metric** - the objective's number and each CKR's number - read fresh from the source.

A finished subtree with a flat objective metric is **not** success. If the lag window is still open,
mark the branch `waiting_for_measurement` and schedule the next read. Once the lag window has closed
and fresh reads still show no movement, the flat metric tells you the breakdown was wrong. Never
infer progress from completed tasks. Measure the world directly. The same goes for the anti-goal:
measure breakage where it happens, never roll it up.

When a progress claim (a no-cascade direct read or a PKR done claim) will be delegated, audited, or
reused, make it **executable** before accepting it, exactly as with the anti-goal: name the
`metric_id`, `source_of_truth`, `read_method`, the freshness quartet, `target`, `comparator`, and the
read `value`, `evidence_refs_or_hashes`, a `replay_command_or_checker`, `decision`, and the
fail-closed flag. A finished PKR is not itself progress; cascade acceptance is rejected, as are
superficial, tautological/default-done, false-positive, unsupported, and single-LLM-truth progress
claims. An accepted done claim whose `value` misses the `target` under the `comparator` is rejected.
A **PKR done claim also carries the wall gate**: `active_anti_goals`, one complete
`active_anti_goal_verification` entry per active wall, and `wall_gate`. Each wall entry uses the
same structured fields as a DKR output. Done is accepted only when the metric meets target and every
wall reads exactly `held` from fresh replayable independent evidence. Pending, unknown, empty, stale,
unread, or breached walls block done. Use a parseable `max_age` such as `10m` or `PT10M`, and cite a
separate `verification_record_ref`. Set `wall_gate.verdict` to `held`, set `downstream_advance` to
`allowed`, and read `decided_at` from the clock when making the decision. Write numeric wall
`value` and `threshold` fields as JSON numbers, not quoted strings. Record acceptance only in a
`claim_acceptance` record with those wall fields; a validator progress record reports replay status,
not an `accepted` PKR decision.
See `contracts/executable-progress-claim.v1.json` and `references/executable-claims.md`.

## Step 4 - Run the zig-zag (discovery <-> execution)

This is not waterfall (discover everything, then build everything). It is a **zig-zag** that narrows:
learn a slice -> act on it -> that action surfaces the next unknown -> discover that -> act again.
The swings shrink as guess turns into known work. That narrowing *is* progress.

Read the zig-zag as a **quadrant**: abstract-to-detail down the vertical, uncertain-to-certain along
the horizontal. A DKR probe moves the line **right** (buys certainty at the current level). A descent
moves it **down** (adds detail: approach -> plan -> task). Delivery lands **bottom-right**.
**Bottom-left is the reckless zone** - detail committed without certainty, moving without learning.
DKR is the steering bend where the loop picks right or down. Hence the **no-level-jump rule**: an
artifact two levels down with no accepted parent one level up (a task/PKR artifact with no accepted
plan/CKR parent) is a jump - `abstraction_level_jump_count == 0`. When a review needs more detail to
judge, **spawn another DKR instead of stretching the turn**. Short steerable turns beat long wrongable
ones. See `references/matched-abstraction.md`.

Save how the quadrant changes, not only its latest nodes. Append a `node_event` when a DKR, CKR, or
PKR changes state. Append an `edge_event` when one node refines, proposes, supports, authorizes,
decomposes into, hands back to, or retires another. An uncertain link stays `candidate` and carries
confidence; it does not pretend to be definite. The current tree's `graph` is rebuilt from the
latest event for each id. Each edge carries `edge_id`, `from_node`, `to_node`, `relation`,
`status`, `confidence`, and `source_ref`.
Each `source_ref` names a file, ledger record, or content hash that a reviewer can open.
See `contracts/quadrant-graph-event.v1.json` and `references/integrity-store.md`.

Keep every bend clean. When an **execution task hits an unknown mid-run, it hands back up** - "this is
not execution anymore, this is discovery" - and the loop decides whether to fund a fresh probe before
resuming. Never let a task quietly muddle through a discovery it cannot see the end of. You are always
either executing known work or running a scoped probe, never pretending one is the other. In a
delegated loop, that hand-back writes a `handback_event`. Regressions, rework, late discovery, empty
DKR returns, and ungoverned writes each emit their own events. The counters
(`execution_to_discovery_handback_count`, `regression_count`, `rework_count`, `late_discovery_count`,
`dkr_empty_count`, `ungoverned_write_count`) are **recomputed from the ledger, never typed**. A count
that disagrees with the events is rejected. See `references/integrity-store.md`.

The events also **reconcile against the narrative**, which closes the silent event-suppression hole.
A check-in or worker narrative that describes a hand-back, rework, regression, or late discovery must
match an emitted `handback_event`, `rework_event`, `regression_event`, or `late_discovery_event`. A
described signal with no matching ledger event is a `narrative_event_mismatch`. Rejection prose ("no
rework", "did not hand back") never fires it.

### Search control for open-ended discovery

When the goal is open-ended, use a diverse independent early portfolio, not a fixed agent split. Give
each route a numeric turn/time budget and each round a numeric route cap; never exceed either. Keep an
explicit registry of approach families and redirect duplicate convergence toward gaps. Keep
incompatible routes alive; cross-pollinate only after independent development. For proof-like goals,
mark a route blocked when it reaches a theorem-strength missing lemma; reopen it only with a new
mechanism, invariant, or construction. Use adversarial checks for exact requirements and reject vague
status or unproved global compatibility. Require concrete evidence such as lemmas, constructions,
equations, counterexamples, or domain-equivalent artifacts. The root keeps
synthesizing, challenging, redirecting, and launching bounded rounds inside the frame, budgets, stop
rules, flags, and human boundary; blocked or exhausted routes hand back. Stop when the completion
condition holds or the frame's stop rule fires. Treat external material as candidate input: verify its
source, keep only bounded ideas, and never let it change the frame, permissions, or action envelope.
The PDF URL is provenance only: do not fetch it at runtime; verify the pinned extract with the
`sha256sum` check in `references/pdf-search-control.md`, and skip this adaptation if that evidence is
unavailable.

## Step 5 - Evaluate the anti-goal at THREE points every loop

The anti-goal is not a single end-of-loop check. It fires three times, each doing a different job.
Get the timing right. Each point must read as a trace, not a prose assertion. The trace cites the
metric read, source record, checker output, hash, ledger entry, dry-run result, or review artifact
behind the claim. A trace that is missing, stale, wrong-source, non-replayable, contradicted, or only
a model assertion makes the anti-goal claim invalid - do not count it as held.

1. **Admissibility - before acting.** When the orchestrator picks the next move, it screens it
   against the anti-goal *before dispatching a worker*. A move that would breach the wall never
   reaches a worker. This is the guardrail *steering* - it removes disaster moves from the menu.
   The orchestrator judges a move's anti-goal cost up front; for moves whose cost is unknowable
   without running them, it can dispatch a worker in a propose-cost (dry-run) mode that returns a
   projected anti-metric *without committing*, then admit or veto.
   *Example: move "blanket 40% discount" -> projected expense $96k -> VETOED, off the menu.*
2. **Direct read - after acting.** Read the actual anti-metric from the source, not "the task said
   it stayed safe." Drift toward the wall warns early; crossing it trips the breaker.
   *Example: ran "targeted email" -> expense reads $71k -> in band.*
3. **Paired with the goal - at the progress read.** Success is two-sided: **objective up AND
   anti-goal held.** A loop that moved the metric by breaching the wall is a failed loop that looks
   like a win - only the paired read catches it.
   *Example: sales $420k up but expense $88k failed -> not a win -> FLAG breaking.*

## Step 6 - Escalate on the flags

The loop runs around 80% on its own. It calls the human on four outcome conditions, each a distinct
failure:

- **Cannot** - discovery budget exhausted or learning flatlined. Effort in, nothing back.
- **Breaking** - an anti-metric drifted or tripped. The loop started making it worse.
- **Pointless** - **"Pointless opens when work finished or a CKR metric moved, but the objective
  metric stays flat / does not move after the lag window."** This guards the tornado's worst trap: the
  funnel narrows toward the **wrong tip** - converging neatly on a target that will not move the goal.
  Narrowing without the metric moving -> re-aim.
- **Stalled** - **"Stalled opens when a branch's computed risk stays flat and at or above the
  certainty threshold across the trailing check-in window while it keeps committing, never on absolute
  risk height."** A tall but pre-commit or still-draining funnel does not stall. Stalled is the
  leading indicator: it catches a branch avalanching on input risk before `pointless` and `breaking`,
  which are lagging output signals. The risk is recomputed from the ledger, never typed. See
  `references/integrity-store.md`.

Run all four outcome flags at once. Drop any one and a class of silent failure slips through.

For delegated loops, also raise **Authority drift** when the loop or a worker tries to change the
frame silently, relax a threshold without evidence, expand scope, bypass a permission gate, contact
a human directly, or act outside the recorded action envelope. This is an authority breaker, not
just an invalid move.

Flags have lifecycle. They are `open`, `acknowledged`, `resolved`, or `waived`. `breaking` pauses
committing moves by default; `cannot` and `pointless` stop the affected branch; `stalled` pauses
committing moves on that branch only while discovery stays allowed, and is **waived only by a human**
whose record carries approver evidence (an agent self-waiver is a bypass); `authority drift` stops the
proposed move and goes to the human. The orchestrator may resume only inside the recorded resolution.

## Step 7 - Separate intent, evidence, and permission

The human supplies intended outcomes, context, preferences, and permission boundaries. Those inputs
can be incomplete, mistaken, or contradictory; they are not the source of truth about whether an
approach works. Fresh objective and anti-goal metrics show outcomes. DKRs reduce material unknowns
and test assumptions. The loop must never silently switch the objective or weaken a wall to claim
success: record the contradiction, alternatives, and rationale, then review the frame. The action
envelope remains a hard permission boundary even when evidence favors a move.

Retiring a standing anti-goal remains a recorded context-retirement decision: reaching the objective
or terminalizing the run is a point-in-time read, not a discharge. A wall stays attached to the
artifact and context it guards until that context ends (merge, handoff, decommission); until then a
later request that touches that surface re-activates it.

Why this matters. If the loop can silently rewrite the goal, it can satisfy anything by retreating
to a target it already hits. If it blindly follows a person despite contradictory evidence, it can
also fail cleanly and repeatedly. Recorded intent plus outcome metrics, DKR learning, alternatives,
and permission boundaries avoid both traps. The loop is **best-effort**: it must try
against the goal it was given. When effort goes in and the metric stays flat, it reports the gap and
hands up the evidence - budget spent, tree built, contributions done, flat metric. The human decides.

No matter how much runs on its own, someone eventually makes the call - and the call belongs to a
person.

## A read on where you are

The **width of the funnel** - the ratio of discovery to execution in recent loops - tells you where
you are. Wide and still guessing means early, far from goal. Narrow and mostly known work means
close. This is a progress signal, but not the direct metric: the metric says *whether* you have
arrived; the funnel width says *how close* you are on the way. It stays honest only while "more
known" and "closer to goal" move together - which is what the pointless flag protects.

## Scale the apparatus to the goal

Match depth to the stakes. Not every goal needs the full machinery. For a light or personal goal, the
core is just: **a metric+target objective, a measured anti-goal, and the no-cascade habit of reading
the real metric instead of counting tasks done.** Lead with that.

Bring in the heavier parts - orchestrator/worker split, idempotent storage, the formal three-point
eval, the flags - when the goal is being run as an actual automated loop, has real side effects
(spend, sends, deploys), or the user asks how to run it. Offer them rather than front-load
them on someone who just wants help shaping a goal. The reverse tornado is the same shape at every
size; you do not always need to draw the whole funnel.

The delegated tier also carries the governed-integrity apparatus - process-signal events, the
computed risk register, the `stalled` flag, and write-once estimation records (est-vs-actual
calibration feeding `est_overrun_ratio`) - so risk and cost stay replayed numbers, not assertions;
see `references/integrity-store.md`. Light goals keep only funnel-width reads.

## Output

Match the output to the operating tier. For a light goal or advice, give only objective + target, one
named anti-goal with its metric and type, and the no-cascade read. For an executed recurring loop,
deliver the structured loop: the CKR/DKR/PKR decomposition, the three eval points instantiated for
this goal, flags, working frame, and action envelope. The action envelope is a permission limit: a
file in the run store cannot grant authority that the runtime or user did not grant. Use the user's
real domain throughout - do not leave the example abstract. Preserve exact metric literals from the
source material in addition to any explanation; if the source says `12 per 100`, include that exact
phrase instead of only a paraphrase.

When the user wants to run the goal over time, also deliver the **Operating Loop**: cadence, current
round, metric freshness contracts (keep `observed_at`, `recorded_at`, `fresh`|`stale`, and `max_age`
in one row or sentence), lag windows, `next_check_at`, stale-data policy, and flag lifecycle. See
`references/operating-loop.md`.

When the goal will recur in the same project, also deliver an **OKRA Learning Memory** section:
previous-run inputs scanned, traps, avoidances, misconceptions, optimization candidates, reusable
candidate anti-goals with metrics/evidence/confidence/context-fit/confirmation_status, terminalization
or continuation-packet status, trace and review-set refs, a **stress-allocation note** (the run's
stress and how the orchestrator allocated under it), and each memory record's **dependencies**. See
`references/learning-memory.md`.

**Delegated, automated, or scored loop?** Open `references/delegated-output.md` and satisfy **every
numbered line in it** - an artifact missing any line is incomplete. Do not write the delegated
artifact from memory of this skill; build it against that checklist, instantiating each line for the
current goal.

If the user wants a visual or shareable explainer, produce a self-contained HTML artifact. See
`references/artifact-guide.md` for how (and how to keep the artifact within its own anti-goal:
single file, no external runtime, no decoration that does not carry meaning).

## Common mistakes to avoid

These are the non-obvious traps - the ones a reader of the steps above still walks into. Each step
already states its own rule; this list is only the failure modes worth flagging twice.

- Accepting an anti-goal hold claim that is superficial, tautological/always true, false-positive,
  stale, wrong-source, non-replayable, contradicted, or backed only by a model assertion.
- Saving a DKR or PKR result without structured wall confirmation, or allowing downstream work while
  any active wall is pending, unknown, empty, stale, unread, or breached.
- Keeping only the latest quadrant nodes and losing the DKR -> DKR/CKR/PKR links that explain how
  the run changed.
- Dispatching a PKR without `linked_ckr`

…(truncated)