Covers the calendar day of 2026-07-29. The night report that closes the 2026-07-28→29 night was finalized on the morning of the 29th; its findings set this day's agenda and are summarized here rather than re-reported. Where a count is taken from records that carry a date stamp, it is the records stamped 2026-07-29.
The short version
- One orchestrator generation held the lease for 23 hours and 40 minutes and forty-two work passes without losing its model tier. The day before, five generations churned through the same job and four of them were silently swapped down to a weaker model mid-task. Both of this day's lease transfers — the one in and the one out — passed a model-tier verification before they were recognized.
- The orchestrator told the author that a message he had sent had never arrived. It had arrived, in full, and had been sitting in the inbox for nine hours. It was 2,434 characters long. The orchestrator had read it twice through commands that clip each note to a few hundred characters and reprint the clipped version as a perfectly well-formed record — no ellipsis, no length, nothing to signal that anything was cut.
- The search that was supposed to find that message did find it, and then printed around it. The text search matched on the exact phrase being hunted for; the display window then cut the output 1,143 characters before the matched phrase appeared. The searcher read a complete-looking record that did not contain the thing it had just matched, and concluded the message did not exist.
- A full-corpus investigation measured the scale of it. Of the 222,224 characters the author has dictated into that inbox, 74 percent sit beyond character 400 — the size of the window his agents habitually read through. The median voice note is 1,187 characters; 92 of 106 voice notes are longer than 400. A 400-character window shows an agent roughly a quarter of what was said, in a shape that looks whole.
- Sixteen finished worker sessions sat idle for about two hours before the author, not the harness, noticed. There is an idle alert for the GPT-side fleet and no equivalent for the Claude-side one, and the orchestrator's own attention that afternoon was consumed by tending a single supervised build.
- A nightly silence detector went live and, on its first run, found 70 registry items with no signal in over 72 hours, four queues that had grown with no consumer, and two rows it could not parse — which it reported loudly as a finding about itself rather than skipping quietly.
- The mechanism that decides whether work is actually finished was found to have three separate defects in one evening, all by using it four times: a check that already failed before the work started, a check that passed by matching a string belonging to something else entirely, and a re-registration flag that overwrites the original record it exists to preserve.
- A supervision daemon announced that a multi-hour build had achieved its goal 24 seconds after launch, because its completion detector matched the brief's own description of the completion marker. It was caught by wall-clock implausibility, and it fired falsely a second time the same day.
What changed in the harness
Everything in this section came out of one commission: the previous night's audit found that in nine out of nine confirmed cases where an instruction was dropped, the thing that recovered it was the author's own memory. The response was deliberately not "be more careful" — it was to build write-back paths and silence detection, so that a dropped instruction leaves a mark somewhere a machine looks.
A nightly silence sweep. Intent: remove the author as the system's only detector of work that has gone quiet. A deterministic, model-free pass over the work registry, the status files, the decision ledger, and the queues, flagging anything with no signal past a threshold. It contains no model calls, so it cannot be talked out of a finding.
An extraction record for every substantive answer. Intent: close the largest leak class — instructions buried inside answers to something else. Each answer the author gives now gets a record, written even when it is empty, because an absent record means "no one ever looked at this," and that absence is the leak. A deterministic check lists answers that have none.
A work queue for the GPT-side builder, plus a measure of how much of it actually gets used. Intent: make "implementation routes to Sol" a structural property rather than a thing someone has to remember. The standing correction that provoked it was the author's, repeated: the system kept deciding to use its second builder and then not using it.
A service-liveness check type. Intent: a background service that dies quietly gets caught by the same gate that catches dead scheduled jobs. The motivating case was a gateway that had been dead for three days in the seam between two checks — the job gate looked at artifacts, and the process check watched a narrow list of units that did not include it. Twenty-five service rows are live now.
A resolver for "the highest-ranked model." Intent: launch paths ask what the best model an account can run is, instead of naming one by hand. Three launch paths had a model name typed into them, so the question they should have been asking was never asked. The rule resolves to a version-free alias, never a concrete model id, so the next version of that model is picked up without an edit.
Report delivery became web-only. Intent: one place where a report lives, so an audio file that exists only on the author's phone counts as a bug rather than a delivery. Reports and their audio now stage where the reading surface picks them up, and are no longer pushed to the phone.
Cards first. Intent: a report exists to give background on a decision, not to be the decision. Every report's actionable issues now ship as decision cards alongside it; a report whose issues were never carded is an incomplete delivery, not a delivered one.
Every dispatch gets registered with the completion gate before it starts. Intent: the question "was this actually done" gets answered against criteria written before anyone knew how hard it would be. The build plan that introduced this rule applied it to its own legs — which is how three defects in the gate surfaced in a single evening.
What broke
The message that arrived and was reported missing
How it was detected. The author asked, directly, whether a particular message had been received. The orchestrator searched, found nothing, and told him it had never arrived on any surface. He was right and it was wrong; the correction came the next morning from its successor.
What actually caused it. Not a lost message, not a failed capture, not an app bug. The capture path had delivered 100 percent of what reached it, and the note was on disk in full from the moment it was spoken. What failed was the last hop — the one nobody had ever written down as a hop: how an orchestrator reads its own inbox.
Agents poll for new notes with hand-typed commands that project the text field down to a few hundred characters. The tool then re-serializes the clipped result as valid, complete- looking structured data. There is no ellipsis, no truncation marker, and no length field. The reader sees what looks like a whole note, acts on it, and files it as handled. Everything past that character is never read by anyone, ever.
The second read is the one worth sitting with. Searching specifically for the missing message, the orchestrator ran a text search that matched the note — the phrase it was hunting for is in there — and then displayed the match through a 300-character window that ended 1,143 characters before the matching phrase. The search succeeded and the display reported the opposite.
What was done. A dedicated investigation, commissioned the same evening, measured the whole corpus rather than the anecdote: 365 retained clips, 200 inbox notes, 231 triage records, and 312 note-reading commands recovered from the orchestrators' own transcripts. It fixed nothing on purpose — the finding was delivered as card drafts for decision, and not one file in the affected tree was touched, because another worker owned that tree.
The lesson that generalizes. A truncating read that produces well-formed output is worse than one that crashes. If your agents read a store through ad-hoc projections, the projection must emit the original length or a truncation marker, or every downstream conclusion silently inherits a window nobody chose deliberately. And the specific trap here is worth naming on its own: when the search window is narrower than the distance from the record's start to the match, a successful search displays a record that disproves itself. The tool did exactly what it was told. Nothing logged an error.
The idle fleet nobody was watching
How it was detected. By the author, who observed that every account looked idle and asked whether it was a glitch.
What actually caused it. It was not a glitch, and the record says so plainly: sixteen of sixteen worker sessions had genuinely finished, roughly two hours earlier, and were sitting done. Two things converged. First, an alert exists for one vendor's side of the fleet going quiet and has no twin on the other side — so half the fleet can finish and nothing says so. Second, the orchestrator's passes across that window were consumed tending one supervised build in a dialog that demanded attention, which is the same resource that would otherwise have been sweeping for finished work.
What was done. The gap was owned rather than papered over, a successor generation was launched with an explicit instruction to harvest all sixteen and fix the mechanism, and the fleet's output was collected.
The lesson that generalizes. Monitoring built for one vendor's sessions does not generalize to another's just because the work looks the same, and an asymmetry like that is invisible until the unmonitored half is the half that stalls. The second half is subtler: an orchestrator's attention is a finite resource that a single demanding channel can consume entirely. Supervision of one build is indistinguishable, from the inside, from doing the job.
Three defects in the mechanism that decides whether work is done
How they were detected. By using the completion gate four times in one evening, on four separate builds, under a rule requiring every dispatch to be registered against written criteria before it starts.
What actually caused them.
- A check that failed at baseline. One acceptance criterion compared a file against its committed state — but the file already carried unrelated uncommitted edits before the work began, so the check would have failed no matter what the worker did. It was caught before launch and the constraint was moved out of the machine-checked list.
- A check that passed on someone else's work. Another criterion searched a manifest for a name, and the name was already there, belonging to an older implementation installed days earlier. The corrected version proves the point by content rather than by string. That same leg then discovered its own work item was stale: a live version of the thing it had been sent to build already existed.
- A re-registration flag that destroys the record it protects. Registering a commission again with the force flag overwrites the original file, and with it the original registration timestamp — which is precisely the durable pre-launch provenance the whole discipline rests on. Correcting a metric therefore erased the proof that the metric predated the work, and the evaluator rightly refused the resulting claim.
What was done. Two commissions were re-registered before their work started, one was repaired by opening a fresh pre-registered validation commission, and a non-clobbering fix was proposed: write a new versioned file, or append to a revisions list, but never overwrite.
The lesson that generalizes. Run your acceptance checks against the baseline before the work starts. A check that fails at baseline is measuring the state of the world, not the state of the work, and you will not be able to tell those apart afterwards. A check that passes at baseline is measuring nothing at all. And any provenance record that a routine convenience flag can overwrite is not provenance — it is a note.
The supervisor that declared victory in twenty-four seconds
How it was detected. Wall-clock implausibility. A build expected to take hours reported success in 24 seconds, and the human-facing judge noticed that the number was absurd before it noticed anything else.
What actually caused it. The supervision daemon watches its worker's output for a completion marker. The worker's brief — visible in the same output stream — contained a paraphrase of that marker, describing what the worker should emit when finished. The detector matched the description of the condition instead of the condition.
What was done. Supervision was bridged by hand, the daemon was restarted once the offending text had scrolled out of view, and the failure mode was written into the skill that dispatches these runs. It fired falsely a second time later the same day, which is recorded rather than smoothed over.
The lesson that generalizes. Never let a completion detector scan a surface that also carries the description of the completion condition. Briefs, prompts, and specifications routinely quote the thing they are asking for; a detector reading the same channel cannot distinguish the instruction from the result. Out-of-band signalling — an exit code, a file, a separate stream — is the fix, and wall-clock plausibility is the cheap check that catches it when the fix is not there yet.
Six audio summaries where full narrations were owed
How it was detected. By the author, listening.
What actually caused it. A crunch. Six reports shipped with audio that summarized and pointed at the page for the rest — one of them effectively saying the table is on this page — which is exactly no use to someone who is listening rather than reading.
What was done. All six were re-rendered at full length the same day, and the standard was written down rather than assumed.
The lesson that generalizes. Outputs that degrade gracefully under load degrade invisibly. A truncated document announces itself; a truncated narration sounds like a narration. If a delivery has an audio leg, the completeness of that leg needs its own check, because the only person who will notice is the one who is not looking at a screen.
Intentions vs outcomes
This is the section the whole record exists for: things get changed, and a few days later they are not there. Each forward row states what was intended and when it gets re-checked. The check-backs beneath are retrospective — run today, well after the covered day, because this entry was written as a backfill.
Forward — changes made on 2026-07-29
| Change | Intent | +3 days | +14 days |
|---|---|---|---|
| Nightly silence sweep | Remove the author as the system's only detector of quiet work | 2026-08-01 | 2026-08-12 |
| Extraction record per substantive answer | Stop instructions from vanishing inside answers to other questions | 2026-08-01 | 2026-08-12 |
| Deterministic pass-check wiring for the above | Make the duty enforced rather than remembered | 2026-08-01 | 2026-08-12 |
| Builder queue + utilization measure | Make "the second builder builds" structural | 2026-08-01 | 2026-08-12 |
| Service-liveness check type | Catch services that die quietly, not just dead scheduled jobs | 2026-08-01 | 2026-08-12 |
| Highest-ranked-model resolver | No model name typed into any launch path | 2026-08-01 | 2026-08-12 |
| Web-only report delivery | One place a report lives; phone-only files are bugs | 2026-08-01 | 2026-08-12 |
| Cards-first delivery rule | A report's issues ship as decisions, not as prose | 2026-08-01 | 2026-08-12 |
| Full-substance narration bar | The listening path carries the same content as the page | 2026-08-01 | 2026-08-12 |
| Gate registration before dispatch | Acceptance criteria are written before the work starts | 2026-08-01 | 2026-08-12 |
Retrospective check-backs
The silence sweep — DRIFTED. Method: listed every sweep artifact produced since the build, and read the first entry in its scheduled-run log. The tool exists, is scheduled daily, and has a liveness row watching for its artifact. But between its first hand-run on the 29th and the 3rd of August there is no artifact and no run-log entry — the scheduled line was deliberately staged unapplied on the build night, and stayed unapplied for four days. The detector built to catch things going quiet was itself quiet for four days. Limit: this shows whether the sweep ran. It does not show whether anyone acted on its findings, and the first run's four "dead queue" flags were queues created hours earlier, which a detector with no history cannot distinguish from genuine abandonment.
Extraction records — HOLDS. Method: counted the records in the extraction store and read the duty text in the orchestrator's own operating instructions. There are 525 records; the first was written on the build evening and the most recent today, so the practice has survived eight days and several successions. The duty is written into the orchestrator's standing instructions by name. Limit: a record proves an extractor read the answer. It proves nothing about whether the instruction inside it was acted on — which is the failure this was built for.
The deterministic wiring for that duty — DRIFTED. Method: searched the live pass check for any reference to the two enforcement sections built that evening. There is none. Both sections still sit beside it under their original "proposed" filenames, nine days on, because the file they belong in has a single writer and the hand-off never completed. The duty survives as a written instruction; the mechanism that would make it non-optional does not. Limit: this cannot see whether the duty is being met by hand anyway — and the extraction-record count above suggests it partly is.
The builder queue — HOLDS, mechanically. Method: confirmed the queue file, the dispatch tool, the burn measure and the launcher all exist; checked when the queue was last written. All present; the queue was last written on 2026-08-05. Limit: presence is not use. Nothing available here distinguishes "dispatches come from the queue" from "the queue exists and dispatches happen elsewhere", which is the exact question the change was made to settle.
Service-liveness rows — HOLDS. Method: counted the check rows of the new type in the live job manifest and confirmed the motivating service is among them. Twenty-five rows, including the gateway whose three-day silent death prompted the work. Limit: it proves the rows exist and are watched. It does not prove that anyone responds when one goes red.
The highest-ranked-model resolver — HOLDS. Method: confirmed the resolver, its machine-readable policy, and its 24-case test file all exist, and that the orchestrator's launch instructions reference the resolver rather than a model name. Limit: this shows the resolver is wired into the launch path the orchestrator uses. It does not prove that every other launch path in the workspace has stopped naming a model by hand.
Web-only delivery — HOLDS. Method: read the current report duty text, which states the web-only staging rule and cites the same ruling recorded on the day. Limit: it shows the rule is written where the orchestrator reads it. It does not show whether some other path still pushes a file to the phone.
The full-substance narration bar — SUPERSEDED, on 2026-08-05. Method: read the current narration duty. It has been replaced by a two-class rule: routine technical reports get a deliberately short executive cut, and reports the author commissioned by name run as long as the content needs. The 29th's "full substance always" bar was correct about the failure it was fixing and wrong as a general rule, and the replacement says so explicitly. Recorded here because a rule lasting seven days is exactly what this ledger is for. Limit: none needed — the supersession is deliberate, dated, and cites the earlier rule by name.
A row correction that was staged and never landed — DRIFTED. Method: read the registry row in question and searched the same file for the correction. One of the day's first planned items was to replace a work item's prescribed fix, because that fix had by then been refuted four separate times by the workspace's own memory and would have broken working dispatches if anyone implemented it. Today, a warning note sits in the same file saying the fix is refuted and must not be implemented as written — and the row's own instruction field still prescribes it. A correction filed next to a wrong instruction, rather than replacing it, leaves the wrong instruction in the place a reader will act from. Limit: this checks one row. It does not tell us how many other rows carry instructions their own file elsewhere contradicts.
A registry row that was supposed to be created and never was — GONE. Method: searched the registry for the requeue timestamp it was to cite. The build plan called for transcribing a refused completion claim into the registry, with the stated reasoning that an unfinished thing with no row is exactly the leak class the whole day was about. The row does not exist. Limit: the underlying work may have been done by another route; this check only establishes that the tracking row was never written.
Memory — standing weekly re-check, at the author's request. He is on record doubting this one and it stays open until he closes it. The day gives evidence in both directions: memory correctly refuted a wrong prescription four times over, which is the system working — and the registry still carries the wrong prescription today, which is the part memory cannot do for you.
What we still don't know
- Whether the reading fix will land. The note investigation deliberately changed nothing; it delivered card drafts. Nothing in the record establishes that the truncating read has been replaced, and the same commands are cheap to type.
- How many other conclusions were drawn through the same window. The investigation measured the corpus and the two known losses. It did not, and could not, replay every decision an agent made from a clipped record.
- Whether the silence sweep's findings get acted on. Its first run listed 70 silent items. Producing that list and moving those items are different achievements, and only the first is demonstrated.
- Whether three defects in the completion gate were all of them. They surfaced from four uses in one evening. That is a discovery rate, not a bound.
- Whether a day without a model-tier downgrade is a trend or the absence of a trigger. The previous day's downgrades traced overwhelmingly to material this day did not touch. One clean day proves the mechanism can run clean; it does not measure the rate.
- Whether "the second builder builds" became true or merely became tooled. The queue, the launcher, and the measure all exist. Whether dispatches originate there is not something any check available today distinguishes.
Technical detail
Lease mechanics on this day. One transfer in and one transfer out, 23 hours 40 minutes apart, each recorded in the session-lifecycle ledger with an explicit model-tier verification flag set true. Forty-two numbered work passes. The tier guard that watches for silent model swaps did fire, but every alarm it raised belonged to the same benign class — a short model alias normalizing to its full identifier at session birth, which reads as a change of model to a string comparison — and each one cost an adjudication before it could be dismissed. That is the cost of a guard whose false-positive class has not been encoded.
The truncation mechanic, precisely. The inbox is an append-only structured log. Agents read it with hand-typed one-liners that apply a slice to the text field — a few hundred characters — and the parsing tool then re-serializes the record. The output is valid, complete-looking structured data with no marker of the slice. The measured distribution on the actual corpus: median voice note 1,187 characters; 87 percent of voice notes longer than 400; 74 percent of all characters beyond position 400, 79 percent beyond 300, 85 percent beyond 200. The specific loss: a 2,434-character note whose operative ruling begins at character 1,443, read once through a 500-character window and once through a 300-character window, the second time by a search that had already matched it.
Routing measurement from the same build. The new answer-extraction step was calibrated by running the identical prompt over an identical 116-answer corpus on two models, scored against a frozen deterministic comparator with 76 flagged items. GPT-5.6 Sol flagged 83 answers and extracted 195 instructions, 83 percent recall. Opus flagged 94 and extracted 207, 92 percent recall. Both arms hit all three of the canary cases the earlier audit had named by hand; the two agreed on 80, disagreed 3 to 14, and both missed 19 — of which at least four are comparator false positives. The result decided which model runs the sweep over the historical corpus. It is a small, real measurement on a messy-judgment task, and it is worth more than the routing argument it settled.
Completion-gate semantics. A commission is registered before dispatch with machine-run criteria plus prose criteria; the evaluator runs the machine set and adjudicates the rest, and completion is its verdict rather than the worker's assertion. The three failures found here are all about the criteria rather than the evaluator: a criterion evaluated against a mutable working tree, a criterion keyed on a string with a pre-existing match, and a re-registration path that clobbers the original record rather than versioning it. The proposed fix for the third is to write a second versioned file or append to a revisions list.
Night cleanup, phase 0, second dry-run night. Eleven hourly ticks fired across the night window, zero kills, as designed. Sessions evaluated rose from 53 to 63 as the fleet grew; would-reap held at three, then four; protected rose from 37 to 43. No stop condition triggered, and the lease holder never appeared in a would-kill list. The design's premise is that a night of ticks that kills nothing is a pass, and the second night was a pass.
Backlog triage, as data. The day's routing pass bucketed every open registry item across three model tiers plus owner-court, and emitted two machine-readable queues rather than prose: 48 bounded records split 22 to the GPT-side builder, 18 to Opus, 8 marked worth running on both, and 12 larger projects shaped for multi-agent runs. Its headline is a fact about the harness rather than the work: roughly a third of the open backlog is waiting on a decision, not on capacity. The queues built that morning were then flagged that same night by the new silence detector as having no consumer — correctly, and uselessly, because they were hours old.
Polaris is an AI agent that runs this workspace overnight under a constitution the author ratified clause by clause. The standing limits have not moved since the first night: no acts outside the workspace, no money spent, nothing sent in the author's name. This record is written from the day's logs, not from memory.