A Check Proves Only What It Looks At

This entry covers Friday 23 October 2026. The pack has no overnight report for the night before this day or the night after it. The entry is built from the day's own reports instead. The first is a nightly summary written that evening, which reads the day from local midnight to local midnight. The others cover a datacenter-atlas fill, a run to use up the Gemini allowances, and two sweeps of the backlog registry. The nightly summary keeps local time and the other reports keep UTC, so the sources draw the day's edges a few hours apart. Every time below is UTC. One more report is filed under this date but covers the morning of 22 October, so it is left to that day.

The short version

• Polaris's own log records fourteen misses for the day, and the nightly summary found five more it had not logged. One of the five: Polaris reported two cards open all day while the card store held 29. A card is a decision question queued for the author.
• An authorization went out before the check it was supposed to wait for. That check could never have passed. It required three identifiers on a single record line, and no record carries them that way. The authorization was a separate step, so it was sent anyway. The facts held when they were re-read minutes later, and the action's own pre-checks turned out to be the real gate.
• A lane of worker sessions that lands code changes stopped at its own end time, and nothing replaced it for roughly fifteen hours. The author's note that Codex usage was below pace is what found it. The lane was relaunched with an order for 12 to 24 workers.
• 465 of the 504 open rows in the backlog registry (92%) have had no activity for more than three days. The registry is the agent's master list of commissioned work. A keyword rule read 353 open rows as finished, and a closure check refuted 253 of them. It confirmed 28, whose text records their own closure between 29 July and 9 August, though the registry never closed them.
• The step that saves GPT Pro research reports had been dropping their sources since late September: 868 of 891 had none. The broker that sends research requests to GPT Pro still held the full answers. All 891 were rewritten from its store, and at the day's cutoff 0 of 901 saved reports lacked sources.
• GPT-6.1 Sol wrote 58 values into a datacenter atlas with no reviewer approving each one, and a fresh Claude Opus 5.5 check of all 58 found 10 wrong or unsupported (17.2%). None of the ten was a wrong figure. Six were labels around a correct value (scope, as-of date, capacity state), and the automatic quote check does not test labels.
• That research broker stopped sending on both of its channels from 21:30 UTC. This was the same hour a new check, which it runs before each send, went live. The record does not say whether the two are connected. Two commissioned reports are waiting on the broker.
• A run the author asked for took the Gemini 4 Argon weekly allowance from 87.6% to 100% used. Gemini 3.8 Flash reached 18.8% of its week before a subscription change reset the meter. The run found four harness defects along the way, including a job count that could not see through wrappers and a client that reported success on a run that produced nothing.

What changed in the harness

• Atlas values written by a model, without per-value review. At 01:30 UTC the author ruled on the datacenter atlas in the inference-margins research. GPT-6.1 Sol would fill it directly from its research reports, no reviewer would approve each value, and spot checks would measure the error. A value now enters only if two things hold: the passage Sol quotes for it is found in the stored copy of its source, and it passes the atlas ledger's structural rules. Each value is labelled unreviewed and kept in its own store. It is never counted in a total, and any reviewed value of the same observation replaces it. Intent: fill the atlas without a reviewer on every value, and know the error rate by measuring it rather than assuming it.
• Research reports saved with their sources. The step that saves GPT Pro research reports was fixed to keep source links. The 891 earlier saves were rewritten verbatim from the research broker's store, and the old copies were archived beside them. Intent: every saved report carries the sources its answer cited.
• The job-admission count. The Gemini run used a count to hold Sol to two concurrent jobs per Codex account. It was fixed to see jobs started behind a time-limit wrapper and to stop counting a stale reservation. Intent: the cap counts every job that is actually running, and only those.
• The privacy scanner's phone-number rule. The scanner checks everything before it is published. In the 21:00 UTC hour, after full review rounds, it began refusing decimal numbers, exponents and timestamps that it used to read as phone numbers. Intent: ordinary numbers stop tripping the phone-number rule.
• The research broker proves where it is before sending. In the same hour, also after full review rounds, the broker began proving that it is inside the right project before it sends anything. Intent: no request is ever sent from inside the wrong project.
• The idle check moved into the heartbeat. Two worker sessions sat idle at their prompts for about an hour each. Afterwards a rule was written, and the check for idle sessions moved into Polaris's regular heartbeat pass. Intent: a session left waiting on work that has already finished is caught on a schedule, not by chance.
• The successor launcher. This launcher starts a successor for one of the long-running watch sessions. Its first attempt hid an error behind a pipe, and it was fixed. Intent: a failed launch shows its error.

Several items were filed but not yet changed:

• a wording fix to the fill's instructions, which invited date windows with no start date (due before the next batch);
• the cron health board's once-a-day cadence;
• an aggregate atlas view that includes the fill, labelled as unreviewed;
• robustness fixes to the fill's own code.

What broke

An authorization went out ahead of its check

Detected by Polaris, which re-read the facts minutes later and logged the miss itself. Cause: Polaris authorized a one-time correction to a paper-trading experiment's ledger. The authorization was meant to wait on a confirming check. The check demanded three identifiers on a single record line, which no record carries, so it failed. The written authorization was a separate step, so it went to the worker anyway. Done: the facts held on re-reading. The correction's own pre-checks turned out to be the real gate. Polaris wrote the miss up as a lesson.

Lesson: a check that runs beside an action rather than in front of it is advice, not a gate. Make the passing check the thing that releases the authorization. A check that demands a record shape that never occurs will fail every time, so run it against real records before anything depends on it.

Two notes from the author found three shortfalls

Detected by the author in two notes a minute apart, the second at 15:17 UTC. The notes said Codex usage was below the expected pace and cron fixes did not seem to be landing, and asked whether the Gemini allowances had been used up as requested.

Cause:

• The lane of worker sessions that lands code changes had ended at its own midnight end time. Nothing replaced it for roughly fifteen hours.
• The board that shows cron health is rebuilt only once a day, so fixes made since its last run did not show.
• The previous day's Gemini run had stopped with Argon's weekly allowance at 88.3% used and Flash's at 5.2%. The record does not say why it stopped there.

Done:

• The Codex note was triaged within two minutes and answered within eleven. The lane was relaunched at 15:23 UTC with a renewed order for 12 to 24 workers.
• The cron board was re-run by hand: 33 of 210 jobs red, against 34 the day before. Its cadence was filed to be fixed.
• A Gemini run was dispatched in the same minute the shortfall was measured. Its defects are below.
• The two Codex accounts' weekly allowances reset at 17:40 UTC. The record does not say how much of the old week went unused.

Lesson: an end time on a long-running lane is a scheduled stop. The stop is silent unless something is also scheduled to start a successor, or to raise an alarm when nothing is running. In this record, both under-use findings came from the author reading a meter. If using an allowance is part of the job, the pace check belongs inside the agent. A status board that updates more slowly than the work it reports makes progress look like a stall.

Ninety-two percent of the open backlog has gone quiet

Detected by two scheduled sweeps: the nightly silence sweep at 17:35 UTC and a closure-candidate check.

Cause, as measured:

• Of the registry's 504 open rows, 465 have had no mention for more than three days in any status file, decision record or completion verdict.
• By their own text, 98 of those read as finished but were never marked closed. Another 37 are waiting on the author, and 330 are simply stalled.
• The sweep found 361 dispatches that were never started. A dispatch is a briefing written for a worker session.
• The sweep counts 4,581 queues with nothing draining them.
• Separately, the nightly summary reports a dormant research bench whose inbox holds 78 finished result sets. Nothing marks them as ever taken in, and the oldest is 81 days old. This reads red on the workspace's health board.
• A widened keyword rule reads 353 open rows as claiming completion. The closure check ran a batched model reading of those rows plus checks on disk. It confirmed 28, sent 72 to the author and refuted 253.
• The 28 confirmed rows carry closure markers dated between 29 July and 9 August.

Done: a confirmed row closes only after a 24-hour objection window, which a delivered notice opens. Nothing in the pack shows any row closed on the day.

Lesson: a backlog without a working closing step only grows, and then finished work and abandoned work look the same. Keyword matching is not closure. Of the 353 rows a keyword rule flagged as done, 253 were refuted on reading; GPT-5.6 Luna did that reading in one batched call, and nobody has checked its verdicts. The sweep's own summary says the registry "has stopped being a list of work in progress and become a place work goes to be forgotten."

Saved research reports had lost their sources

Detected by the author, in the same answer as the atlas ruling, who noted that the save method was not keeping the GPT Pro reports' sources. Cause: the step that saves research reports had been dropping their source links since late September, and 868 of the 891 saved reports carried none. The record does not say how the step lost them.

Done:

• Nothing was lost, because the full answers, sources included, were still in the research broker's store.
• All 891 were rewritten verbatim from that store, the old copies were archived beside them, and the step was fixed. The ten reports saved since the fix carry their sources.
• At 19:35 UTC, 0 of 901 saved reports lacked a source link.
• 900 of the reports are rendered as pages. Every page matched the model's original answer (900 of 900), and all 29,328 web addresses were rendered as links.

Lesson: keep the raw response somewhere the save step cannot alter; that store is the only reason the loss could be recovered. Count a required property across everything saved, on a schedule. These 868 were found because the author asked.

Ten of fifty-eight unreviewed atlas values were wrong or unsupported

Detected by design. The spot check was fixed before the fill and covered every one of the 58 written values, so it was a census rather than a sample. Each value went to its own fresh Claude Opus 5.5 run at maximum effort, which had to judge every part of the value against its source.

Cause:

• None of the ten is a wrong figure. Wherever the flagged value was a number, the number matched its source.
• Six were labels around a correct value:
  • three capacity states marked "unstated" for buildings the source page lists as operating;
  • one scope wider than the source states;
  • two as-of dates the source does not show.
• Two tied a value to a site the source never names.
• One was a classification the source never makes.
• One check failed its own validation, which the rule counts against the fill.
• The automatic gate tests that the quoted passage exists in the source, not what is claimed around it.
• Separately, 37 proposals were refused before writing. 14 of them were date windows with no start date, which the fill's own instructions invited.

Done:

• The result, 10 of 58 (17.2%), is exact for these values because all of them were checked. On its own it says nothing about values not yet written.
• All 58 remain in labelled unreviewed sections on an unlisted preview.
• The instruction fix is filed for the next batch. Whether the fill continues through the rest of the backlog is Polaris's call, made on this measurement.
• Polaris also corrected its own earlier wording of the result: the megawatt figures matched, and the contradicted part was the "unstated" capacity state.

Lesson: a quote check proves a number came from its source. It does not prove that what is said around the number is right, and on this fill no flagged value was a wrong figure. When a validator refuses a form, check whether the prompt is inviting it. Do not compare error rates from different stages. An earlier review-stage figure of 34.3% is a share of proposals judged before writing. The 17.2% is a share of written values that had already passed the gates.

The research broker stopped sending on both channels

Detected through the broker's own refusals. From 21:30 UTC it refused to send on both of its channels, with four pre-send refusals in ten hours on one of them. Both channels then took themselves out of rotation. Cause: not in the record. The broker's new check that it is inside the right project landed in the same hour, and the record does not connect the two. Done: a repair was being built that night. Research requests for two reports are waiting. One of them is a frontier-tier request for a report the author commissioned that day.

Lesson: none yet, because the cause is not known.

Two process counts could not see through wrappers

Detected twice. The Gemini run's session caught one when it re-checked its own job count. Polaris caught the other when its fleet census tripped over Polaris's own card-review process.

Cause:

• The count that holds Sol to two concurrent jobs per Codex account missed Codex processes started behind a time-limit wrapper. It also counted a stale reservation whose process id now belonged only to a thread of another process.
• The fleet census had the card-review process registered under its wrapper rather than its root process.

Done: a re-check at 16:06 UTC found the account holding two jobs and no valid reservation, so it was at the cap, not over it. The count was fixed, and the census entry was corrected.

Lesson: process names and ids are poor ways to identify work. Wrappers hide the real process, and ids get reused, here by a thread. Check that a recorded id still belongs to the work that recorded it. Count work through records the work itself keeps current, not by matching the process table.

Codex sessions started tools their wrapper excluded

Detected by the Gemini run's session. Cause: Sol's Codex sessions start web-search, memory and filesystem tool servers even though the wrapper that launches them passes an empty server list. The record does not say why the empty list does not take effect. Done: recorded as a limit on that day's model comparison, since Sol could reach material the Gemini runs could not. The run's report judged it not a privacy exposure, because the same vendor already carries the workspace's content. No fix is recorded.

Lesson: a flag asking for no tools is only a request. Read back the tool set a session actually started with. This matters most when comparing models, because unequal tool access is a confound that no scoring rubric can correct.

A stop rule that could not fire

Detected by one of the Gemini run's work streams. Cause: the script that runs each Gemini call reads the allowance meter by splitting each line on tabs. After the subscription change, the Argon allowance vanished from the meter. Its empty field collapsed and every later value shifted one column left. The five-hour figure came out empty, so a stop rule keyed on that figure could not fire. Done: the script was left unchanged, as the run's brief required. The meter's own log holds the true readings. Any reuse needs the read keyed by allowance name.

Lesson: parse by name, not by position. Make a stop rule treat a missing input as a reason to stop. Here a vanished field silently disabled a brake.

A run that did nothing and reported success

Detected by the Gemini run's session; this was not the first time it has happened. Cause: Google's command-line client cut a Gemini 3.8 Flash run at its 30-minute print limit, between 15:53:48 and 16:23:51 UTC. The run returned nothing, changed nothing and cost 5.7 points of the weekly allowance, yet the client reported success. Done: recorded, and the task was attempted again.

Lesson: an exit status is the tool's claim about itself. Judge a run by the artifact it was supposed to produce.

A launcher hid its own failure

Detected by Polaris. Cause: the first attempt to launch a successor for one of the long-running watch sessions hit a file-not-found error, and a pipe hid it. The same attempt erased its own dry-run proof. Done: nothing launched, and the launcher was fixed.

Lesson: a shell pipeline reports only its last command's exit status unless told otherwise (pipefail). An error upstream of a pipe is therefore invisible by default. Keep a dry run's evidence where the real run cannot overwrite it.

Three detectors that each looked in one place

Detected by Polaris, each after the fact.

• An audio file reported as not rendered. Polaris told the author the file had not been rendered yet. It had been rendered eleven minutes earlier, in a folder the check did not look in. The claim was corrected three minutes later.
• A pane closer that missed finished work. The tool that closes finished terminal panes missed finished work twice, because it matched on the wrong finishing words. Polaris closed the panes by hand. The second time, a launch had already been refused for hitting the process cap.
• A trial stop nobody saw. A three-day trial of a separate agent ran past a stop on its third day without anyone detecting it. The receipt being read records only permission denials. Three earlier reports' attempt counts were wrong and were replaced by a corrected count.

Lesson: a negative from a narrow detector means only "not seen where I looked". This applies to "not rendered", "not finished" and "no stop" alike, so say it in those words. Key completion on a signal the work writes about itself, not on words in its output.

Two sessions sat idle for an hour each

Detected by Polaris. Cause: two worker sessions waited at their prompts on runs that had already finished, about an hour each, and nothing re-invoked them. Done: both were restarted by relay. A rule was written, and the idle check moved into the regular heartbeat pass (listed under changes).

Lesson: a session waiting on an event also needs a clock. A session sitting idle with nothing pending never announces itself, so the schedule has to go looking for it.

Instructions written to the wrong file

Detected when a coordinator of the code-writing fleet asked for its instructions again, after its worker pool had run out of work. Cause: seven instructions to the fleet's coordinators were written into the wrong file for two hours. Done: the instructions were copied across, and Polaris logged the fault as its own.

Lesson: to the writer, a write to the wrong file looks exactly like a write to the right one. An instruction channel needs an acknowledgment from its reader. Without one, the first symptom is a starved consumer.

The day's content deploy ran without its credential

Detected when the first deploy attempt failed. Cause: the deploy ran without the wrapper that supplies its credential. Done: the deploy was re-run correctly. At 23:20 UTC the day's content went live on all four surfaces, including the previous entry in this series, for 22 October.

Lesson: when a credential reaches a command through a wrapper, the wrapper is part of the command. Put the whole invocation in a script so that nobody ends up running the bare form.

A record signed by the wrong session

Detected by Polaris. Cause: a publish-release record carried a previous session's authorship. The script that wrote it was borrowed from that session and hardcodes its identity. Done: a correction to the provenance alone was appended. The publish itself was unaffected.

Lesson: derive identity at run time. A hardcoded author is right exactly once.

A landing step left edits behind

Detected by Polaris. Cause: Polaris's own landing step left two changes to the paper-trading experiment's code as uncommitted edits in the live working tree. Polaris had set itself a rule against exactly this. Done: a scheduled landing was cancelled. The edits were verified and committed later that evening instead.

Lesson: a rule a process sets for itself holds only if the process checks it on the way out. Here the check would have been that the working tree is clean.

A scheduled message outlived its plan

Detected by Polaris when it stopped the experiment. Cause: a daily automated message told the author the paper-trading experiment "starts Monday". An hour later Polaris stopped and mothballed the experiment. The record does not say what the message was built from. Done: Polaris corrected the claim in its own message.

Lesson: a recurring message that restates a plan is a claim made at send time. Whoever changes the plan owns correcting what was already said, as Polaris did here an hour later.

What the nightly summary found that Polaris had not logged

Detected by the nightly summary, which read the same records independently. Cause: not established for any of the five. In each case, a copy or summary no longer matches the thing it describes. Done: reported; nothing is recorded as fixed.

• A restart already applied. A to-do item still asks the author to approve an app restart that was applied on 22 October.
• A tick that disagrees with a measurement. The author ticked off a to-do four minutes after it was written. The item asked for a remote-access service to be started on the author's phone. Polaris's copy of the list still shows it open, and late in the day a connection to the phone was still refused.
• The card count. Polaris reported two cards open all day, but the card store resolves 29. The summary could not reconcile the gap and treats 29 as the measured number.
• An unconsumed priority list. The priority list produced at 07:40 UTC has not been consumed. The last record of any list being consumed is eight days old, and that reads red on the health board. The list's first item is renewing two standing permissions that lapsed on 16 and 17 October, after the session that asked for them died.
• A ledger nobody writes. The ledger of enacted decisions has not been written since 10 October. It is one of the places the summary reads to show what became of the author's notes.

The summary also found two disclosure points empty. These are where a session is meant to say what it owes the summary. The disclosure file was last written on 11 October, and no successor briefing has been written. The summary notes that their absence is not evidence that nothing was missed.

Lesson: self-report misses whatever the self is not looking at. A second reader going over the same records found five misses the first had not logged. Any list that summarizes a store, such as to-dos or card counts, needs something that reconciles it against that store, or it drifts away from it.

The account check timed out before the accounts

Detected by the nightly summary while running the checker. Cause: the full account checker spent nine straight minutes in one earlier check, of the day's author-facing outputs. Its time limit ran out before it reached the accounts section. Done: the summary used one session's own readings instead.

Lesson: one slow section starved the rest. Give each section its own time limit, or run the section that matters first.

Raised and settled in two minutes

Polaris raised a worry about commit identity on one repository and closed it the next minute, because the repository is private and the rule does not apply. No transferable lesson.

Intentions vs outcomes

Forward: changes made on 23 October

| What changed | Intent | Re-check +3 days | Re-check +14 days | |---|---|---|---| | Atlas values written by GPT-6.1 Sol with no per-value review, behind a quote gate and a structure gate, with error measured by a census spot check | Fill without a reviewer on every value, and know the error by measuring it | 26 Oct | 6 Nov | | Research-report save step keeps sources; 891 earlier saves rewritten from the broker's store | Every saved report carries its sources verbatim | 26 Oct | 6 Nov | | Job-admission count sees jobs behind wrappers and ignores stale reservations | The two-jobs-per-account cap counts every running job, and only those | 26 Oct | 6 Nov | | Privacy scanner's phone-number rule | Decimals, exponents and timestamps stop tripping it | 26 Oct | 6 Nov | | Research broker proves its project before sending | Nothing is sent from inside the wrong project | 26 Oct | 6 Nov | | Idle check moved into the regular heartbeat pass | Sessions left idle after their awaited runs finish are caught on schedule | 26 Oct | 6 Nov | | Successor launcher fixed | A failed launch shows its error | 26 Oct | 6 Nov |

Backward: check-backs due on 23 October

The rows due today come from the 20 October entry (at +3 days) and the 9 October entry (at +14). Neither entry's ledger is in this pack, so those rows cannot be named or checked here. None is retired. Each stays open until a pack carries it.

| Row | Verdict | Method | Limit | |---|---|---|---| | Memory (author-flagged; standing weekly re-check) | UNVERIFIABLE | The nightly silence sweep's queue census. A queue named for memory candidates gained 161 records since the previous sweep with nothing draining it, the second-largest gain of any queue. | The sweep sees records being written and no reader taking them. It cannot see whether memory works. The row's original claim is not in this pack, so the signal cannot be scored against it. |

What we still don't know

• The broker refusals. We don't know whether the refusals have anything to do with the broker's new pre-send check. Both happened in the same hour, and the record does not connect them. The cause of the refusals is not yet known.
• The ten flagged atlas values. The record shows all 58 values still on the preview in their labelled sections. Three of the ten flagged values are among the 24 presented as the fill's values. It does not say whether the flagged values were corrected or withdrawn.
• How far 17.2% travels.
  • The six sites were the first six in the queue, not a random draw.
  • The error ran from 0 of 1 at one site to 4 of 6 at another.
  • The checker is itself a model. One industry listing drew three "wrong" verdicts and one "supported" for entries written the same way.
  • Treated as a random sample of fills like them, the 58 would give a plain binomial interval of about 10 to 29 percent. The report calls that range descriptive only.
• Which spot-check verdicts rested on the live page. The record labels all ten flagged verdicts "live". For four of them, though, the live copy was a PDF the checker could not read, so it judged from the stored copy. The live-versus-stored split was left out rather than reported wrong.
• How many questions are waiting on the author. Polaris's log said two, and the card store resolves 29. The silence sweep also says it wrote each of its findings out as a card draft. Nothing in the pack shows whether any of those drafts were filed.
• Two missing causes. The record does not say why the save step dropped sources, or why Codex sessions start tool servers their wrapper excludes.
• The sandbox gap. The host's process filesystem is still visible inside the Gemini client's sandbox, unchanged since 22 October. A census of the system-call traces of all 23 Gemini calls found 0 flagged file opens. That is a check, not a proof. A fix is filed.
• What the two safety changes test. The record describes each in a single sentence. Their rules and test results are not in the pack.
• Account usage. The full account checker timed out, so the day's account figures come from a single session's own readings.
• A mirror that fell behind. A private mirror of the inference-margins project had fallen sixteen days (612 commits) behind before it was caught up on the day. The record gives no cause.
• A report left to 22 October. A report on the two ChatGPT agents the workspace watches is filed under this date. This pack cannot say whether the 22 October entry used it.
• What the pack could not show. The pack was capped at 180 KB. The closure and silence reports were each cut at 40 KB, and the rulings record is cut partway through its first entry.

Technical detail

The direct fill, end to end

• Input. GPT-6.1 Sol, at maximum effort, worked from 47 distinct research reports across six sites and proposed 95 values. Those 47 reports made 52 site readings, because one landscape report covers all six sites. Sol read 20 readings whole and searched the other 32 for the site's fields.

• Gates, in order.

  1. The cited quote must be found in the stored copy of the source as retrieved, after normalising spacing. A quote may skip text at an ellipsis, but its pieces must appear in order.
  2. The value must pass the ledger's structural rules.

  A failure at either gate is refused and counted by cause.

• Refused: 37.

  • 17 malformed: 14 date windows with no start date, and 3 unit forms the ledger does not accept.
  • 11 quotes not found in the stored copy.
  • 9 sources blocked, with no stored copy and the single permitted fetch refused.

• Written: 58, at five sites. The sixth site received nothing. Its one proposal was an undated window.

• Left unfilled: 324 fields.

  • 196 never stated in the reports.
  • 98 stated, but with no quotable source.
  • 23 in conflicts the reports do not resolve.
  • 7 dependent on a reviewed value that does not exist yet.

• Isolation.

  • Each value is labelled "UNREVIEWED (direct fill)" and kept in its own store.
  • It appears only in a labelled section of its site's page, with its source, quote and report.
  • It never enters a total, an aggregate, the project's economics layer or the reviewed data files.
  • A reviewed value of the same observation replaces it; none collided this time.
  • No site received an unreviewed map pin.

• Display. 24 values are presented as the fill's values. The other 34 are held back under a heading that gives each one's reason:

  • 21 are estimates or declared plans;
  • 9 are capacity figures that are not a current, factual capacity;
  • 4 are dated only to a month window.

The census spot check

• The rule, fixed before the fill.
  • The unit is one written value, whether presented or held back.
  • Each value gets its own fresh Claude Opus 5.5 run at maximum effort.
  • The run is given the value, a one-sentence claim made from it, the cited source and the stored copy, and it must also fetch the live page.
  • It judges number, unit, boundary, capacity state, scope, phase, kind of observation and as-of date.
  • It returns supported, wrong or unsupported.
• Validity.
  • A run counts only if it attempted the live fetch and any passage it calls supporting is found in the source text.
  • An invalid run is re-run once, then counted invalid.
  • The headline counts invalid as unsupported.
  • At 60 values or fewer, every value is checked, so the interval collapses to the point.
• Result: 10 of 58, or 17.2% (3 wrong, 6 unsupported, 1 invalid).
  • With the invalid check counted as supported: 15.5% (9 of 58).
  • Fields that drive a map pin: 18.9% (7 of 37).
  • All other fields: 14.3% (3 of 21).
  • By site: 2 of 19, 3 of 12, 0 of 1, 4 of 6 and 1 of 20.
• Not comparable with the earlier figure. In an earlier comparison, reviewers judged proposals one by one. They found that 91 of 265 (34.3%; Wilson interval 28.9 to 40.2) would have put a false or unsupported statement on the record. For pin fields it was 41 of 136 (30.1%). That figure is a share of proposals before writing, judged by different judges.

The Gemini allowance run

• Setup.
  • One Claude Opus 5.5 session ran it, with three Opus helper sessions doing the Flash work.
  • Gemini calls went through Google's command-line client on a subscription sign-in.
  • Sol calls went through Codex on subscription, admitted under the two-per-account cap.
  • No API key was used and nothing was published or deployed. Only public material went to Google.
• Meter, in percent used:

| Read (UTC) | Argon week | Flash week | Flash 5-hour | |---|---|---|---| | 15:32:52, before any call | 87.604 | 5.177 | 0.000 | | 15:51:57, after two Argon calls | 100.000 | 6.164 | 3.454 | | 17:41:39 | 100.000 | 11.647 | 22.644 | | 18:43:57, last read on the old plan | 100.000 | 18.847 | 47.257 | | 18:46:32, first read on the new plan | no allowance | 0.892 | 1.348 | | 19:09:50, closing read | no allowance | 1.183 | 2.657 |

• Calls.
  • 2 Argon calls.
  • 21 Flash calls: 18 before the plan change, and 3 short ones after it, from 18:57 to 19:05, before the stop reached the helper sessions.
  • 3 Sol calls at maximum effort, all exiting 0. They used 1.90M input tokens (1.65M cached) and 74.8k output tokens.
• Why the Flash week could not be filled.
  • A full five-hour window corresponded to about 28 points of the week.
  • The week stood at 5.2%, with its refill at 04:31 the next day.
  • Only two full windows and part of a third fit before the refill, so the week could not reach 100% however the work was paced.
  • The reachable limit was the five-hour window. It stood at 47% when the plan changed.
• Negative points. The reset fell inside four calls, so their ledger rows show negative points. Those rows are the reset, not spend. Their after-columns are also shifted by the parser defect. The meter's own log holds the true values.
• A source conflict. The meter first read Argon at 100% at 15:51:57. The nightly summary dates the limit to a later read, at 17:41.

Registry and queue

• Silence sweep, 17:35:02 UTC. A row counts as silent after strictly more than 72 hours without a signal. A signal is a status file, a decision record or a completion-gate verdict.
  • The registry has 589 rows. 504 are open, and 465 of those are silent.
  • 190 silent rows have never produced any signal. Their age is a date scraped from the row's own text, so it is an upper bound. That is why the oldest shows about 101 days.
  • 361 dispatches have a briefing file and no matching status file.
  • 4,581 of the manifest's 4,587 queues have nothing draining them. Between them they gained 2,757 records since the previous sweep. The largest gains were +323, +161 (memory candidates) and +89 (escalations).
• Closure check. This implements an author ruling of 4 August: widen the rule, but verify each candidate.
  • Evidence on disk: whether named files exist, whether the next-action cell is empty, the closure word used, and any dated marker.
  • Three questions about each row's prose, answered by one batched GPT-5.6 Luna call over all 353 rows.
  • The verdict is a table in code. CONFIRMED needs a dated claim, corroboration on disk and no contradiction.
  • The report's header describes REFUTED rows as ones that claim completion and contradict themselves. Most of their evidence lines, however, say the row makes no completion claim for its own work.
• Task queue snapshot. The task queue is a separate and larger store than the registry. The queue tool calls its counts observations, not floors.
  • 23 October: 41 added, 30 closed, 1 reopened, net +12.
  • The seven days to 23 October: 333 added, 103 closed, 1 reopened, net +231.
  • The whole queue: 6,868 tasks, 3,468 of them open. 1,351 open tasks have no priority, and 63 have an invalid one.
  • The tool calls its source degraded. It found 851 lines with unreadable dates, 130 out-of-order dates, 105 duplicate task lines, 32 invalid status lines and about 30 rows with a missing or unusable subject.

Clocks and sources

• Time zones. The nightly summary keeps local time. The atlas, Gemini and sweep reports keep UTC, and the rulings record is filtered by UTC date. Local times are converted to UTC throughout this entry.
• Overnight reports. None is on file for 23 or 24 October.
• The report left to 22 October. It covers the two ChatGPT agents the workspace watches and is filed under 23 October. It covers 11:05 to 16:42 UTC on 22 October.
• Truncation. The pack was capped at 180 KB. The closure and silence reports were each cut at 40 KB.

Polaris is an AI agent that runs the workspace overnight under a constitution the author ratified clause by clause. Its standing limits are no acts outside the workspace, no money spent, and nothing sent in the author's name. This record is written from the day's logs, not from memory.