The Loop Passed Its Research Bar, Not Its Implementation Bar

I asked an agent to run a difficult review of Tamoz’s OpenClaw chat workflow. The request was deliberately demanding: create a branch, reread the earlier study, run three specialist reviews, make each review meet a bar, brainstorm through a facilitator and a Fourier lens, run three product-engineering reviews, build nested orchestration, monitor the loop every ten minutes, and write the result into a durable documentation package. (evidence/original-request.md:15-29)

The useful answer is not “the agents did it.”

The useful answer is more precise:

The loop produced an evidence-rich study and found real Tamoz defects. It followed most of the requested structure. It did not fully satisfy the independence and monitoring requirements because three Lane C attempts and the product-engineering parent stalled before materializing their own summaries (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:36-47,96-119; evidence/subagent-logs/lane-c-final.log:1-2; evidence/subagent-logs/pe-orchestrator.log:1).

That distinction is the subject of this article.

If you run agent reviews, take three rules from this one: define the evidence bar before dispatch, require a small checkpoint before a long report, and make the controller—not a worker or a fallback—the authority for completion. The rest of this postmortem shows why those rules matter.

The raw records are preserved in the evidence archive (source archive). The original request is preserved in original-request.md (source archive). The completed Tamoz review package is copied under evidence/refresh-package (source archive). The independent postmortem audits are in fact-audit.md (source archive) and loop-design-audit.md (source archive).

The first rule: define what “done” means

The first thing I did well was create a bar before asking the agents to investigate. The bar required exact repository evidence, explicit labels for facts and hypotheses, end-to-end source reading, user-visible failure modes, root causes, ranked recommendations, owner seams, acceptance tests, real transport/provider gates, non-goals, and a verdict.

Those requirements are recorded in evidence/refresh-package/openclaw-chat-study-refresh/00-review-bar.md:14-50.

The bar also defined what the final package had to contain:

• an indexed README;
• the bar itself;
• three specialist reports;
• two brainstorming reports;
• a consolidated study;
• a roadmap;
• three product-engineering reports;
• an evidence index;
• a correction log.

The package inventory is verified by evidence/refresh-package/openclaw-chat-study-refresh/README.md:7-43 and evidence/archive-validation.md:12-17.

This was the right control. It made “high quality” inspectable. It also made it possible to say that the current Tamoz experience was not ready even when a report was complete.

The important distinction was:

State	Meaning
Requested	The user asked for this work.
Dispatched	An agent was started for it.
Started	The agent wrote a progress checkpoint.
Materialized	The assigned output file exists.
Reviewed	The main orchestrator inspected the output against the bar.
Corrected	A targeted correction was requested and incorporated.
Accepted	The report content met its bar.
Blocked	A required fact or external condition remained unresolved.
Fallback	The main orchestrator wrote an output after delegated work failed to materialize.

Most agent workflows collapse these states into one word: “done.” That is how confidence leaks into the system.

What the loop actually did

The source archive contains 15 rollout JSONL records captured from the session directory: 12 content/orchestration records and three guardian-review records. The 14 original-prefix files contain 12 content/orchestration records and two guardian records; the fifteenth is another guardian record attached to the same parent thread. The parent record also contains later turns because the postmortem continued in the same Codex task. Guardian records are preserved as provenance but are not treated as analysis agents. The archive contains 11 relevant subagent progress logs, the 15-file refresh package, the 41-file prior study, repository instructions, and ART-043 reference material. The exact inventory is in evidence/MANIFEST.md (source archive) and archive-validation.md (source archive).

The execution sequence was:

1. A new branch was created: codex/openclaw-chat-experience-refresh-20260827 (evidence/source-snapshots/branch-state.md:5-9; parent rollout record 36).
2. The earlier OpenClaw/Tamoz study, implementation plan, benchmark protocol, scenario catalog, current code, tests, and documentation were read (evidence/subagent-logs/lane-a-gap-audit.log:1-3; evidence/subagent-logs/lane-b-interaction-product.log:1-3).
3. A refresh bar and indexed package were created under docs/openclaw-chat-study-refresh (evidence/refresh-package/openclaw-chat-study-refresh/00-review-bar.md:1-12; evidence/refresh-package/openclaw-chat-study-refresh/README.md:1-15).
4. Three specialist lanes were dispatched: gap audit, interaction/product, and chat/Telegram architecture (parent rollout records 116-118).
5. The gap lane initially found 17 evidence and product gaps. Its correction loop clarified the verdict and added G18, a confirmed clarification- projection defect, for 18 final gaps (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:15-24,36-47; evidence/refresh-package/openclaw-chat-study-refresh/specialist-reviews/01-gap-audit.md:671-697).
6. The interaction lane produced journeys, message cards, attention budgets, metrics, safety tradeoffs, and a phased product program (evidence/refresh-package/openclaw-chat-study-refresh/specialist-reviews/02-interaction-product.md:1-12,360-373).
7. The architecture lane synthesized but failed to materialize. Two narrower replacement passes also failed to materialize, so the main orchestrator wrote a transparent fallback architecture report (evidence/subagent-logs/lane-c-chat-architecture.log:1-3; evidence/subagent-logs/lane-c-chat-architecture-replacement.log:1; evidence/subagent-logs/lane-c-final.log:1-2; evidence/refresh-package/openclaw-chat-study-refresh/specialist-reviews/03-chat-telegram-architecture.md:14-16,369-377).
8. Two brainstorming agents then ran: a facilitator generated and clustered options; Fourier examined turn, conversation, work-session, operator, channel, organization, and long-term measurement scales (evidence/subagent-logs/brainstorm-facilitator.log:4-6; evidence/subagent-logs/brainstorm-fourier.log:1-3; evidence/refresh-package/openclaw-chat-study-refresh/brainstorming/01-facilitator.md:438-454; evidence/refresh-package/openclaw-chat-study-refresh/brainstorming/02-fourier.md:356-370).
9. A product-engineering orchestrator spawned three second-level reviewers: product/agent vision, architecture/security/reliability, and implementation/evidence (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:7-20).
10. All three child report files materialized, and the agents reported correction completion. Independent acceptance is not proved by those completion records. The parent orchestrator itself failed to materialize its summary, so the main orchestrator wrote a clearly labeled reconciliation fallback (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:7-20; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:96-119).
11. The package was checked with the pinned Ruby 3.3.11 executable. The documentation_tree_test.rb command passed with 7 runs and 1089 assertions; documentation_surface_test.rb passed with 9 runs and 95 assertions. The broader documentation_test.rb command remained red with three failures on pre-existing ADR-count and broken-link conditions (evidence/refresh-package/openclaw-chat-study-refresh/03-evidence-index.md:39-53; parent rollout records 1388-1392 and 1427-1430).

The raw rollout records are more authoritative than this summary. They contain the dispatches, waits, correction messages, completion claims, and tool outputs. Key sequence anchors are the branch snapshot at evidence/source-snapshots/branch-state.md:5-12; specialist dispatches and Lane C attempts in the parent records 116-118 and 678-781; brainstorming records 866-904 and 978; product-engineering dispatch and child activity in records 989, 1049, and 1287-1430; and the named test results in evidence/refresh-package/openclaw-chat-study-refresh/03-evidence-index.md:39-53.

Requirement-by-requirement ledger

Original requirement	Result	Evidence and honest boundary
Create a new feature branch	Followed	evidence/source-snapshots/branch-state.md:5-9; parent rollout record 36. The parent initially reported main, then the captured snapshot was on codex/openclaw-chat-experience-refresh-20260827.
Read and understand the previous study	Partly supported	Reading checkpoints: lane-a-gap-audit.log:1-3 and lane-b-interaction-product.log:1-3; copied archive: evidence/MANIFEST.md:19-22. Reading is evidenced; “understood” is an inference.
Start a gap-finding subagent	Followed	Parent rollout records 116-117; specialist-reviews/01-gap-audit.md; lane-a-gap-audit.log:5-6. This proves dispatch/materialization, not acceptance by itself.
Start an interaction/product subagent	Followed	Parent rollout records 116-117; specialist-reviews/02-interaction-product.md; lane-b-interaction-product.log:1-5. This proves dispatch/materialization, not acceptance by itself.
Start a chat/Telegram architecture subagent	Partly followed	Three Lane C attempts were dispatched but did not produce a delegated report: parent records 118 and 678-781; 04-correction-log.md:36-47. The main-authored fallback is specialist-reviews/03-chat-telegram-architecture.md.
Create a high bar and loop each specialist until it met the bar	Partly followed	Bar: 00-review-bar.md:32-50. Lane A/B report verdicts are in their report files; Lane C had three failed attempts and a fallback, so independent completion was not achieved: 04-correction-log.md:15-47.
Brainstorm through two agents	Followed for dispatch and materialization	Parent records 866-904 and 978; brainstorming logs and reports. Report acceptance remains bounded by the report contents, not completion messages.
Use a facilitator and Fourier lens	Followed	brainstorming/01-facilitator.md:438-454 and brainstorming/02-fourier.md:356-370; corresponding logs.
Set a bar and loop the brainstorming outcome	Partly followed	Those reports state content/readiness verdicts at the cited ranges; parent records show nudges/forced materialization, not a complete independent correction loop.
Write everything under a docs subfolder	Followed as materialization	evidence/source-snapshots/branch-state.md:10-12; 15 files. This is not proof that every report passed.
Run three product-engineering lenses	Followed for child dispatch/materialization	Parent record 989; child records 1239, 1412, and 1420; pe-product-agent-vision.log:4-5; pe-architecture-security-reliability.log:3-4.
Use multiple orchestration levels	Structurally followed; operationally incomplete	Parent records 989, 1049, and 1287-1310; product-engineering-reviews/00-orchestrator.md:7-20. The parent summary required a main fallback.
Check and optimize the loop every ten minutes	Partly followed	Request: evidence/original-request.md:29; correction log:89-94; parent wait/check records 207-264, 548-655, and 1005-1197. No scheduler or exact ten-minute cadence is evidenced.
Produce something useful for Tamoz and its agent vision	Study produced; product readiness not achieved	Readiness: product-engineering-reviews/00-orchestrator.md:108-119; no production changes: source-snapshots/branch-state.md:8-12. “Useful” is an inference, while human usefulness is explicitly unproven: 04-correction-log.md:33-35,85-87.
Use the original subagent data	Followed for archive preservation	evidence/MANIFEST.md:8-25; parent copy records 1498-1506. Derived conclusions remain bounded by MANIFEST.md:27-36.

This table is the most important answer to “what did you actually follow?” The structure was mostly followed. The independent materialization contract was not fully followed. The monitoring request was approximated manually.

What worked well

The bar came before the agents

The refresh bar prevented the review from turning into a collection of opinions. It forced every material statement into one of five categories: fact, inference, hypothesis, proposal, or evidence gap.

That discipline survived the review. The reports repeatedly said that focused tests and deterministic fixture providers proved plumbing, not intelligence, enjoyment, or real Telegram behavior (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:37-39; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:63-72).

Ownership was concrete

Each specialist had one report path, one log, and a no-production-edit scope. The brainstorming agents had separate paths. The product-engineering children had separate paths. This avoided report contention and made missing materialization visible. The absence of a reported path collision supports the contention assessment, but does not measure whether the ownership design caused it to be avoided (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:7-11,61-65; evidence/source-snapshots/branch-state.md:8-12).

The final package is not just a conversation transcript. It is a durable directory with a README, bar, reports, decisions, roadmap, evidence index, and correction log:

refresh README (source archive) (evidence/refresh-package/openclaw-chat-study-refresh/README.md:7-43).

Correction changed the substance

The correction loops were not cosmetic, based on the changed report contents and correction log rather than on completion messages alone (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:15-24,36-47,96-119).

The gap lane initially ended with an ambiguous NEEDS FIXES verdict. The correction forced it to distinguish report completeness from system readiness. It then verified and added G18: a clarification descriptor can reach the approval-only evidence lookup and raise before a question reaches the channel (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:15-24,36-47; specialist-reviews/01-gap-audit.md:671-697).

The product-engineering architecture lens found two further defects that the first consolidation had missed:

• request-scoped status can aggregate delivery/effect state across a conversation or thread;
• cancellation is thread-oriented rather than exact-reference scoped.

The product/agent-vision lens separately found that the proposed clarification answer had no durable comms ingress and that a safe goal label needed a deterministic owner. These findings changed the roadmap order. The attribution and source details are preserved in evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:43-67. Ownership and control truth must precede a polished human card.

The independent lenses converged — an editorial inference

The facilitator and Fourier reports did not merely repeat the same prose. This is an editorial inference from the distinct findings, not a measured causal proof. Fourier identified cross-scale feedback loops:

• worker-health silence creates status polling and resubmission;
• more liveness messages can create notification noise and muted channels;
• missing request identity makes local progress look like global truth;
• green fixture readiness can reduce pressure to run live evidence. (evidence/refresh-package/openclaw-chat-study-refresh/brainstorming/02-fourier.md:1-20,300-356; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:49-59)

The product, architecture, and implementation reviewers independently converged on the same hard gates: typed interruption, request-local truth, exact controls, worker health, real surface evidence, and separate usefulness measurement (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:22-41).

The system did not overclaim

The final package says the current readiness is NEEDS FIXES (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:108-119). It does not say that Tamoz communicates well because a fake transport delivered deterministic cards (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:33-35,85-87). Calling that restraint a success condition is an editorial assessment.

What did not work

Broad delegated briefs created silent synthesis stalls

The architecture specialist read and synthesized the relevant material but did not materialize its report. A replacement pass with a narrower brief and a final Lane C pass also stalled. The main orchestrator eventually wrote a fallback from verified source evidence (evidence/subagent-logs/lane-c-chat-architecture.log:1-3; lane-c-chat-architecture-replacement.log:1; lane-c-final.log:1-2; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:36-47).

The product-engineering parent did something similar: it spawned the required children, the child report files materialized, but the parent summary did not materialize. The main orchestrator wrote a reconciliation fallback (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:7-20).

This means the package contains the requested reports, but not every report was produced independently by the agent assigned to it. The correction log states that plainly. Any future article that says “all agents completed” would be false.

The monitoring loop was not a real monitor

The request asked for a check every ten minutes and optimization based on what was happening. The main process did perform repeated checks of:

• agent completion status;
• report-file existence;
• progress-log tails;
• branch/worktree state.

That was useful, but it was not a durable scheduler, heartbeat, or exact ten-minute control loop (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:89-94; parent rollout records 207-264, 548-655, and 1005-1197). No durable scheduler or machine-readable orchestration state is evidenced that could wake the main process, classify a stale child, and apply a policy automatically.

“Meet the bar” was initially ambiguous

A report can meet its content bar while the system it reviews fails readiness. The first Lane A verdict blurred those two meanings. The correction repaired the language, but the protocol should have separated them from the beginning:

• report/content status;
• current system/evidence readiness;
• implementation authorization status.

The raw evidence was not packaged at the beginning

The original review wrote its own package, but no initial manifest is evidenced in the retained original artifacts. The postmortem had to reconstruct the evidence from rollout records, logs, branch state, reports, and copied source packages.

The reconstruction succeeded because the session records were available at collection time. The claim that this was luck rather than a robust protocol is an operational inference, not a measured causal result.

Thoroughness appears to have consumed the critical path

The agents were asked to reread large document and source sets, then synthesize large reports before materializing. The records show long waits and stalled attempts, but no timing study proves causality. The operational inference is that this delayed visible output. A better process would require a short evidence map and initial findings checkpoint before the full narrative (parent rollout records 548-781 and 1005-1308; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:36-47,89-94).

What the study itself revealed

The process postmortem is also a product postmortem.

The reviewed system already had durable admission, lifecycle state, delivery fencing, unknown outcomes, cancellation visibility, context controls, and pairing according to the consolidated study and its evidence index (evidence/refresh-package/openclaw-chat-study-refresh/01-consolidated-study.md:20-46; evidence/refresh-package/openclaw-chat-study-refresh/03-evidence-index.md:10-19). The second sentence is a product inference: it still did not feel interactive enough because it lacked one truthful, actionable work session.

The most important confirmed defect was not a tone problem. A clarification interrupt was routed through approval semantics. The worker emitted an approval event for every non-empty interrupt, while the clarification descriptor had a question but no approval decision. The sink then fetched approval evidence (evidence/refresh-package/openclaw-chat-study-refresh/03-evidence-index.md:15; 04-correction-log.md:15-24,36-47).

The architecture review also found that a human could be shown a request-local status projection built from conversation-wide delivery/effect state, and that canceling did not reliably target one request among several (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:43-57). The final sentence is an inference about UX risk: a friendly card on top of those facts could make the wrong answer more persuasive.

The lesson for loop design is direct:

A review must challenge the authority and ownership boundaries beneath the user interface, not only the wording on the interface.

Five whys: an inference about why the loop was useful but not fully reliable

The following chain is an analysis model built from the observed waits, fallbacks, and manual checks; it is not a directly measured causal study.

1. Why did the final package need main-authored fallbacks? Because delegated agents and the parent orchestrator did not materialize their summaries within the available bounded waits (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:36-47,96-119).
2. Why could they remain active without a durable state transition? Because the loop used progress logs and manual waits, but did not enforce a machine-readable materialization deadline (parent rollout records 548-781 and 1005-1308; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:89-94).
3. Why was materialization not enforced? Because the bar described report quality more precisely than it described orchestration liveness and fallback semantics (evidence/refresh-package/openclaw-chat-study-refresh/00-review-bar.md:32-50; evidence/source-snapshots/subagent-orchestration.md:38-47).
4. Why did the process emphasize content over liveness? Because the task was treated primarily as a deep research problem, while the coordination loop itself was not modeled as a system with queueing, heartbeat, timeout, and recovery behavior (evidence/original-request.md:15-30; parent rollout records 207-264,548-781,1005-1308).
5. Why does that matter? Because the process reproduced the same failure mode under study: a human could not tell whether a lane was working, waiting, or stuck without inspecting an external log. This last sentence is an inference from the manual-monitoring evidence (evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:89-94).

Inference from those observed events: the loop had a quality bar but not a complete control-plane contract for agent liveness, artifact materialization, and fallback authority.

The optimized loop for next time

The answer is not “use more agents.” The answer is a smaller control plane with better state transitions.

Phase 0 — Freeze the request

Create one REQUEST.md containing:

• the verbatim user request;
• explicit requirements;
• implied outcomes;
• forbidden assumptions;
• scope and write permissions;
• success and stop conditions.

Create QUALITY_BAR.md before delegation. Split its final verdict into three independent axes:

1. content completeness;
2. evidence readiness;
3. implementation authorization.

Also create the immutable claim registry: one row per material claim with its claim class, safety class, required evidence, owner, and fallback eligibility. This registry is the authority used by the evidence validator and publication gate.

Phase 1 — Build the evidence spine first

Before analysis begins, capture the planned inventory:

• branch and base commit;
• worktree status;
• relevant prior study;
• repository instructions;
• test/runtime environment;
• source and artifact inventory;
• evidence retention paths.

Then append observed entries as the session creates them. The manifest must not pretend to know future session or subagent IDs. Each observed entry should carry the artifact path, producer, attempt ID, parent ID, content hash, event or line range, collection timestamp, availability, and any replacement or fallback relationship. A validator should reject a claim whose cited path, range, or digest is absent from the observed manifest.

This postmortem’s evidence/MANIFEST.md (source archive) is the archive artifact assembled after the original review. No initial manifest is evidenced in the retained original artifacts. In a future run, the manifest would be a two-phase, append-only record: planned inventory first, observed evidence second.

For implementation, use one manifest writer and canonical UTF-8 bytes with a declared SHA-256 digest. The planned phase records requirement ID, expected artifact class, owner, and destination. The observed phase appends the actual producer, attempt ID, parent ID, path, byte digest, event or line range, collection time, runtime/toolchain, availability, and supersession relation. The validator reads the manifest and the article claim registry, verifies that each cited path exists, its selected range is valid, its digest matches, and the artifact status permits the claim class. A source change creates a new observed entry and invalidates the old digest; it never rewrites history. Publication fails closed when a required entry is absent, contradictory, or unavailable.

Phase 2 — Use narrow specialists with early materialization

Keep three specialists, but give each two required outputs and explicit proposal-level deadlines. For example, a run may set a five-minute checkpoint deadline, a twenty-five-minute attempt deadline, and a thirty-five-minute parent budget. Those values are an example policy, not a fact about the original run; the controller must record the chosen values in the run ledger.

Each specialist must produce:

1. a short checkpoint by the checkpoint deadline: source map, top findings, and blocked questions;
2. a final report by the attempt deadline.

Use a monotonic clock for active deadlines and record queue time separately from active execution time. Persist the controller clock anchor and a recovery timestamp; after a controller restart, do not mark a lane stale from wall-clock silence alone. Reconcile the anchor first or emit monitor_inconclusive. The controller should allow at most one bounded replacement attempt unless the user explicitly authorizes more. The replacement receives a new attempt ID and a separate staging path.

The run ledger should distinguish these states:

• normal path: requested, dispatched, started, checkpointed, materialized, reviewed, corrected, accepted;
• exception path: blocked, failed, stale, stopped, replaced, fallback, reopened, superseded.

These are not free-form labels. A single controller owns the legal transitions, records an event timestamp, reason, owner or lease, and evidence digest, and rejects an illegal or stale write. Artifact status, independence status, content verdict, evidence verdict, readiness verdict, and implementation authorization are separate fields. A late artifact after stop or fallback is quarantined; it cannot silently replace the fallback or become independent evidence retroactively.

Each specialist should own one report path and one log path. No specialist should be asked to produce the entire final narrative before it has written a compact evidence map.

The report path is a promotion target, not a shared scratch file. An attempt writes to its own immutable staging path, then a validator checks the canonical bytes and SHA-256 digest. Only after the staged artifact is durably flushed and renamed into its immutable destination may the controller commit the matching ledger transition. Recovery reconciles the destination and digest before advancing state; a missing or mismatched artifact leaves the attempt blocked. SQLite WAL is paired with durable commit settings (for example, synchronous=FULL) and a filesystem that provides the promised rename durability. This is a proposed publication protocol, not evidence that the original run implemented it.

Executable ledger contract

The following is a proposed reference contract for the controller, not a claim about what the original run implemented. Store one append-only event ledger and one derived attempt projection in a durable store. A projection row must contain: run_id, attempt_id, parent_id, actor_id, artifact_path, state, artifact_status, independence_status, content_verdict, evidence_verdict, readiness_verdict, authorization_status, owner, lease_token, lease_epoch, lease_expiry_utc, started_at, checkpoint_deadline, attempt_deadline, last_checkpoint_at, source_digest, artifact_digest, reason, and supersedes_attempt_id.

Only the controller may advance the projection. A transition transaction must lock the run, require the expected current state and lease epoch, append the transition event, update the projection, and commit both together. A worker heartbeat or artifact write with an old lease epoch is rejected and recorded as stale. The event includes actor, previous state, next state, reason, timestamp, and digest; no state is changed by editing an earlier event.

The reference implementation for this proposal is one SQLite ledger in WAL mode. Lease acquisition runs in an immediate transaction: it requires an unleased or expired row, increments lease_epoch, creates a fresh random lease_token, assigns owner, and writes lease_expiry_utc. Renewal requires the same owner and token, the current epoch, a non-terminal state, and an unexpired lease; it extends the expiry and appends a heartbeat event. The controller that observes expiry advances the row to stale, increments the epoch, clears the token, and commits that fence before any replacement acquisition. A restart uses the persisted UTC expiry only after clock reconciliation; otherwise it records monitor_inconclusive and takes no lane-advancing action. This makes acquisition, renewal, expiry, and fencing one defined operation rather than a choice left to each worker.

The legal transition table is:

From	Allowed next states
requested	dispatched, blocked, failed
dispatched	started, blocked, failed
started	checkpointed, blocked, failed, stale
checkpointed	materialized, blocked, failed, stale
materialized	reviewed, blocked, failed
reviewed	corrected, accepted, blocked
corrected	reviewed, accepted, blocked
stale	stopped
stopped	replaced, fallback, blocked
failed	replaced, fallback, blocked
accepted	reopened, superseded
replaced	started, blocked, failed
reopened	dispatched, blocked
fallback	superseded

For a concrete default policy, set heartbeat to 60 seconds, declare an attempt stale after two missed heartbeats or at its absolute attempt deadline, send a stop request, and allow a 30-second stop-acknowledgment grace period. If the acknowledgment is absent, the controller advances the attempt to stopped with reason stop_ack_timeout, fences its lease, and only then creates the one replacement attempt. A child cannot consume the parent’s final grace period: the parent deadline is authoritative and child deadlines are allocated at dispatch. These values are proposals for a future implementation and must be configurable and recorded in the run ledger; they are not evidence about the original session.

Terminal publication requires an immutable attempt-scoped artifact whose content hash and validation result are already in the ledger. The final index points to that immutable path and digest; it does not overwrite a shared report path. If a process writes after its lease is fenced or its state is terminal, the controller stores the late artifact under a quarantine path and records it as inadmissible.

Phase 3 — Make correction policy explicit

The main orchestrator should apply typed correction actions:

• content correction: a required section or argument is missing;
• evidence correction: a citation, range, digest, or fact classification is missing or unverifiable;
• scope correction: the report crossed its file or question boundary;
• block: the evidence or environment cannot support the requested claim.

If a report exists and misses a bar item, send one targeted correction. If it cites unverifiable facts, return it for evidence correction. If there is no checkpoint by the checkpoint deadline, mark the attempt stale after one inspection. Before a replacement starts, fence the live attempt by changing its lease and state atomically. If there is no materialization by the attempt deadline, stop it and use one narrower replacement pass. If the replacement also fails, write a fallback only with a FALLBACK label.

Every attempt needs a distinct staging path and attempt ID. The fallback must retain the failed or stopped attempt references. It may fill a non-safety- critical synthesis gap, but it must never satisfy the independent-report gate, authorize a risky action, or erase an unresolved evidence gap.

The fallback eligibility predicate is: the missing artifact is synthesis-only; all safety-critical and authorizing claims have independent evidence; the stopped attempt and its reason are recorded; no ownership or lease conflict is unresolved; the main process names the fallback author; and the package labels the result FALLBACK or PARENT_FALLBACK. If any predicate is false, the only permitted outcome is blocked.

“Synthesis-only” is determined by an authoritative claim registry created in Phase 0, not by the fallback author. Each claim row has claim_id, claim_class, safety_class, required_evidence, owner, and fallback_eligible. The allowed claim classes are execution_fact, source_fact, inference, hypothesis, proposal, readiness, and authorization. safety_class is non_safety, safety_critical, or authorizing; fallback_eligible defaults to false and may be true only for a non-safety synthesis or editorial claim. The validator rejects a fallback if a covered claim is missing from the registry, has conflicting classification, or has safety_class safety_critical or authorizing. No worker or model may change these fields after the run starts; a reclassification requires a new run version and new evidence review.

This is what the original loop eventually did by judgment. The future loop should make it an append-only, fenced protocol.

Phase 4 — Brainstorm from evidence, not from fresh drift

Run the facilitator and Fourier lanes only after the specialist evidence map is closed enough to challenge.

The facilitator should produce:

• options;
• assumptions;
• tensions;
• clusters;
• a challenge to the strongest option;
• converged bets;
• discarded ideas.

Fourier should produce:

• turn-scale signal and latency;
• conversation-scale queueing and memory;
• work-session recovery;
• operator workflow;
• channel capabilities;
• organizational aggregation;
• long-term learning and measurement;
• cross-scale reversals.

Their outputs should be timeboxed and should not reopen the entire repository.

Phase 5 — Use a real second-level orchestrator

Use at most one bounded aggregation layer below the main orchestrator. The main process remains the control-plane owner. The product-engineering parent should have its own owner, lease, checkpoint deadline, final deadline, and explicit parent-fallback rule. It should own a small state table:

Child	Lens	Path	State	Last checkpoint	Verdict
P	product/vision	fixed path	state plus attempt/lease	timestamp	content/readiness
A	architecture/security	fixed path	state plus attempt/lease	timestamp	content/readiness
E	implementation/evidence	fixed path	state plus attempt/lease	timestamp	content/readiness

The parent may not claim completion until all three paths exist, their independence status is known, and it has written its own summary. If the parent stalls, the main process may write a reconciliation fallback, but the final package must say PARENT_FALLBACK and retain the child reports as the independent evidence. A parent fallback is a synthesis substitute, never a fourth independent lens.

The parent summary is promoted through the same ledger transaction as a child artifact: validate all three child references, record their digests and verdict axes, then publish an immutable parent artifact. A parent stop or replacement cannot mutate a child’s state. The main process owns the parent’s final stop decision; the parent may request a stop but cannot authorize its own fallback.

Phase 6 — Enforce the ten-minute monitor

The monitor should run from a durable state file or scheduler, not from memory. The controller should perform an immediate launch check and then observe on a maximum ten-minute interval with bounded jitter; “every ten minutes” must not depend on an exact wall-clock tick. A single writer or idempotent claim key must prevent two monitors from stopping or replacing the same attempt. Each observation should append:

1. child state, last checkpoint, lease, and deadline;
2. the classification: active, stale, materialized, blocked, failed, or monitor_inconclusive;
3. progress against the current bar;
4. the chosen action and its idempotency key;
5. what is working, what is not, what changed, and what will be optimized.

The monitor must distinguish a slow but healthy attempt from a dead one using heartbeats and progress evidence. If the monitor itself is unavailable, the run fails closed with monitor_inconclusive; it must not infer health from silence. The monitor is not there to generate more prose. It is there to make silence observable and intervention auditable.

The heartbeat event must include run_id, attempt_id, lease_epoch, monotonic timestamp, last completed unit, current state, and controller version. The monitor owns one durable claim key per intervention, for example attempt_id plus deadline plus action. On restart it reloads the last observation and claim keys before taking action; an already-claimed stop or replacement is not repeated. A monitor observation that cannot read the ledger, validate the clock anchor, or acquire its claim is monitor_inconclusive and cannot advance a lane.

Phase 7 — Close with a fail-closed gate

The package cannot be marked ready if:

• a required report is missing;
• a fallback is presented as independent evidence;
• a claim lacks a raw artifact pointer;
• a high-severity reviewer finding is unresolved;
• a real-provider or real-transport claim has only fixture evidence;
• the original request ledger has an unclassified requirement;
• the evidence manifest cannot explain where the session records went.

The controller should maintain this stop matrix, with each row persisted as a decision event:

Condition	Severity	Authority	State/evidence	Owner and recovery
write-boundary violation or ownership conflict	critical	main controller	stop, preserve artifact and lease event	main owner; no replacement until conflict resolved
stale source snapshot or malformed artifact	high	evidence validator	blocked with invalid digest or schema result	evidence owner; reopen as a new attempt
monitor cannot read ledger or trusted clock	high	monitor	monitor_inconclusive with last observation	main owner; restore monitor, no lane advance
checkpoint or attempt budget exhausted	medium/high	deadline controller	stopped with deadline event	lane owner; one fenced replacement if eligible
unsafe unknown outcome	critical	effect/control owner	blocked with immutable unknown receipt	domain owner; reconcile before any retry
missing independent evidence or known-red gate	high	publication gate	readiness blocked with missing requirement	main owner; obtain independent evidence or stop
ordinary lane failure	medium	main controller	failed with error receipt	lane owner; fence, then apply fallback predicate

Resume means a new attempt with a new ID, not mutation of a stopped attempt. The run must also carry forward the repository’s behavior model, file-ownership contract, named gates, and known-red list from docs/subagent-orchestration.md. Those are operating constraints, not optional background reading.

Metrics for future loops

Track the loop itself, not just the number of agents. Every metric needs a run ID, attempt ID, event source, time window, numerator, denominator, owner, and threshold:

• time to first checkpoint;
• time to materialized report;
• stale-lane rate;
• fallback rate;
• correction rate;
• independent-report coverage;
• percentage of article claims with raw evidence pointers;
• repeated-reading overlap across lanes;
• unresolved high-severity findings at each gate;
• parent-summary materialization time;
• monitor observations completed versus expected;
• false-stale interventions;
• late artifacts after stop or fallback;
• correction latency and time to fence;
• monitor-inconclusive outcomes;
• token and cost budget consumption;
• decision quality against the declared acceptance test.

Agent count is an explanatory variable, not an objective. A lower count may be better, but only if decision quality and evidence coverage remain above their declared thresholds.

The first rollout should publish formulas and thresholds before it starts. For example: checkpoint latency is checkpoint event time minus dispatch event time; independent-report coverage is accepted independent reports divided by required independent reports; stale rate is stale attempts divided by started attempts; late-artifact rate is quarantined late artifacts divided by terminal attempts; and claim coverage is claims with a validated manifest pointer divided by all material claims. The owner of each metric records the denominator window and the threshold; missing telemetry is unknown, not zero.

Keep, stop, add

Keep	Stop	Add
Bar before delegation	Treating dispatch as progress	Explicit state machine
Disjoint report ownership	Broad briefs with no early artifact	Evidence manifest at minute zero
Fact/inference/proposal labels	Endless waits for silent synthesis	Checkpoint deadlines
Independent lenses	Counting fallback as independence	Fallback authority label
Real-provider evidence boundary	Calling fixtures intelligence	Fail-closed readiness
Durable docs package	Manual-only ten-minute monitoring	Durable heartbeat/monitor
Correction loops	Copy-only “fixes”	Separate content/readiness/authorization verdicts

Final assessment

What I actually followed was most of the user’s requested architecture: branch, previous-study reading, three specialist roles, bars, two-agent brainstorming, three product-engineering lenses, nested orchestration, durable docs, and evidence retrieval. (evidence/original-request.md:15-29; evidence/source-snapshots/branch-state.md:5-12; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:7-11,36-47,96-119)

What I did not fully follow was equally important:

• the architecture specialist did not produce an independent report;
• the parent orchestrator did not produce its own summary;
• the ten-minute check was manual rather than automated;
• no initial evidence manifest is evidenced in the retained original artifacts;
• the final package remained system-unready because real experience evidence and several high-severity Tamoz fixes were still open. (evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:108-119; evidence/refresh-package/openclaw-chat-study-refresh/04-correction-log.md:74-119)

Editorial assessment: the result is therefore not a failure. It is a qualified success, not a measured product outcome:

The loop was good enough to discover real defects and produce a useful roadmap. It was not yet good enough to make every delegated result independently auditable or to prove the product experience itself. (evidence/refresh-package/openclaw-chat-study-refresh/03-evidence-index.md:15-30; evidence/refresh-package/openclaw-chat-study-refresh/product-engineering-reviews/00-orchestrator.md:16-20,108-119)

That is exactly the kind of result a serious loop should report.