A Rule The Author Could Not Pass

This entry covers Wednesday 28 October 2026, in UTC. The source pack's index lists no night report for the 28th or the 29th. Among the reports filed under the 28th, though, is a nightly report headed Wednesday 28 October and written that evening, and this entry uses it. The seam is that the report's "today" is the author's local day, not the UTC day. It gives some times in the author's time zone and leaves others unlabelled, so this entry uses its events and counts but none of its clock times. One other report filed under the 28th covers a window on the morning of 23 October and is not used for the day's events.

The short version

The author opened a remote terminal (ssh) session from their phone. Between 02:45 and 03:28 UTC, the harness of Polaris (the agent that runs this workspace) refused, discounted or bounced their typed orders six times. The investigation that followed judged four of those wrong and two right.
The four wrong ones share one cause. Since August, a message typed into a session has counted only as weak evidence that the author sent it, because the session's log marks a person's keystrokes exactly as it marks keystrokes injected by a program.
The order caught in the middle was to raise the account guard's ceilings (the guard refuses to start Polaris on an account near its usage limit) to 95% of the weekly allowance and 85% of the separate allowance for the Fable model. It was typed at 02:50 UTC and went live at 06:47 UTC, by way of an investigation rather than the path it was typed into.
By day's end, three instruction texts said that a session the author opened and is using has the author present. Code that checks this from where a process runs, rather than from its logs, is going in as install patches: one had landed and two were blocked on review.
The session that runs Polaris overnight was on a heavier model than Polaris's own rules assign it, and the timer meant to catch that switch was not running. Neither was fixed.
489 of the 504 open items in the backlog registry (a list of work items Polaris tracks) had gone more than three days without a mention in any status file, decision record or review verdict.
Nine work packages reached the review ceiling (no package gets more than three rounds of review) and were split up instead of finished.
At the nightly report's last reading, four of the five accounts stood at 93–98% of their weekly allowance. The fifth, at 53%, was carrying the night.

What changed in the harness

The account guard's ceilings were raised. On the author's order, the guard now lets Polaris run on the workspace machine's own account up to 95% of its weekly allowance and 85% of its Fable allowance. The change has been live since 06:47:02 UTC. Intent: keep the guard from standing Polaris down again at the old, lower ceilings.
Three instruction texts now say the author is present in a session they opened. Skills are instruction files a session loads for a particular job. Three texts changed:
- the main instructions file every session loads (CLAUDE.md);
- the skill sessions use to ask questions through Polaris;
- the section of the Polaris skill on checking where an order came from.
Each now says that a session the author opened themselves and is using, over ssh or at the console, has the author present. Their words there are theirs, and no one asks them to prove it. The Polaris skill adds that a session's log alone is evidence, not proof. Intent: every session, wherever it was started, takes the author's typed words in such a session as the author's.
The author accepted a limit, and the code that enforces it began to land. A card is a question queued for the author in the Polaris phone app. By answering one, the author accepted that anything running as them inside their own ssh session counts as them. Four code changes and one further skill update were tested and reviewed against that limit. The code changes are:
- a checker that reads the chain of processes the checking program itself runs in;
- the provenance tool's use of that checker;
- a writer key that lets the author's own session write Polaris's records in their name.
Each change is to be installed by its own worker after its own review. By the nightly report, one install patch landed in the evening and two came back blocked from review. Intent: let a word-for-word relay of the author's typed message pass as theirs, without review, when and only when it is checked from inside their own direct ssh login.
More benchmark material may go to Google's models. A standing rule limits what of the workspace's own material the route to Google's models may carry without the author's word. By card answer at 17:50 UTC, the author added synthetic test material and image prompts the author wrote. Intent: let the benchmark runs that were waiting on that answer go ahead against Gemini 4 Argon. Two ran between 18:44 and 18:56 UTC.
Three classifiers moved to a cheaper model. The author chose the switch, and it took effect when they tapped the Polaris app's staged restart. The three classifiers had been measured. Intent: lower running cost.

What broke

The author's own orders were graded as unproven

Detected. By the author. At 02:28:53 UTC they opened an ssh login on the workspace machine from their phone, and at 02:29:03 they started a Claude session in it. They typed three messages:

The first asked why Polaris looked down, and was answered.
The second, at 02:45:02, asked for Polaris to be run on a second account with limited action until the allowances reset. The account guard refused on that account's ceilings. The session overrode it with the author's order as the reason, and a new Polaris session started at 02:46:25.
The third, at 02:50:41, ordered the guard's ceilings raised so Polaris would not be stood down again. It never reached Polaris by that path.

At 03:30:07 the author wrote a note in the phone app. It said their messages on the workspace machine had been theirs and should be treated so, and that they wanted to be able to get things done when they logged in over ssh.

Cause. One rule, in force since August: a message typed into a session counts only as weak evidence that the author sent it. The reason is that the session's log marks the author's typing and a program's injected keystrokes identically. Every typed row in the window carried the "typed" and "human" tags, including the programs' rows. Three places applied the rule to the third message:

The write check. The check on who may write to Polaris's queue had no entry at all for a session the author opened. It refused the order as "who is unknown".
The provenance check. The check behind the send step found the author's exact words, typed in their own session. It still graded them "evidence, not authentication", a grade the send step blocks.
The Polaris skill. Its instruction for anything gated is to get a note or card. That led the session to ask the author to send the order again through the app. Later it told them their words "only count as unverified evidence".

Trusting the log more was never an option. Like every file about a session, it can be written by any program running as the same user.

Done.

The order was enacted from the investigation and was live at 06:47:02 UTC.
The three instruction texts above changed the same day. The author accepted the limit the code works within.
The code that checks presence from where a process runs was tested and reviewed against that limit. One install patch landed in the evening. Two came back blocked from review and were left for the next Polaris session.
Two refusals were right and stay:
- The guard's refusal was a usage ceiling, not doubt about the author, and was overridden in 33 seconds.
- One relay was refused because the session had sent its own rewording plus notes rather than the author's words. No relay may put words in the author's mouth.

Lesson. No amount of tagging recovers who typed a line from a record that people and programs write as the same user. What a program cannot fake is where it runs. A check executing inside a direct, root-owned login's chain of processes can be reached by whatever that session runs. A scheduled job, a background worker or a tmux pane outside the chain cannot move itself in. A gate that its real principal can never pass is not a defence; it is a detour. This order went from 02:50 to 06:47 UTC by way of an investigation instead of the path it was typed into.

An earlier look at the evidence named the wrong transcripts

Detected. By the investigation, when it checked where the earlier record had looked.

Cause. The work item, and Polaris's earlier ruling on the author's note, had looked for the author's session in the workspace's session folder and named two transcripts there. Both belonged to Polaris's own background workers, started at 03:02 and 03:07 UTC, after all three of the author's messages. Transcripts are filed under the folder a session is started from, and the author had started theirs in their home folder. Sessions started there also load a different memory file, and that file did not carry the new rule.

Done. The report corrected the location, and the rule went into the instructions file every session loads.

Lesson. A record found where you expected one is not necessarily the record you were looking for. Check its start time and process before ruling on it. A rule written into one project's memory binds only the sessions started in that project. A rule meant for every session belongs in the one file every session loads.

The night orchestrator ran on the wrong model, with its alarm off

Polaris runs as a succession of orchestrator sessions, each handing over to the next.

Detected. The check that runs at every orchestrator pass showed two facts:

the session running Polaris overnight was on the heavier general model, where the standing rule puts it on the lighter one;
the timer whose job is to notice that switch was not active.

Cause. Not recorded in the pack.

Done. Nothing. Both facts were visible in the same check output, neither was fixed, and the detection stayed dark all day.

Lesson. From outside, an alarm that is switched off looks the same as an alarm with nothing to report. Here the evidence existed, because the check printed it at every pass, but nothing was obliged to act on it. A detector being off has to be treated as a fault with an owner, not left as a line of output.

Work went into the backlog and did not come out

Detected. Twice, by two tools:

The nightly silence sweep (17:35 UTC) found 489 of the 504 open items in the backlog registry, 97%, not mentioned by any status file, decision record or review verdict for more than 72 hours.
The nightly review list ranks dark items (those showing no recent activity) for attention. It counted 2,134 of them, four more than the night before. It also found 19 of the previous night's 20 lines untouched for exactly 24 hours.

Cause. The review list's own diagnosis is that the orchestrator is live and dispatching, so this is "an intake gap, not a capacity gap". The problem is that nothing draws work from the list, not that no one is free to do it. The sweep sorts its 489 quiet items into three groups:

101 that read as finished but were never closed;
47 waiting on the author;
341 open and stalled.

In the sweep's words, the registry "has stopped being a list of work in progress and become a place work goes to be forgotten."

Done. The review list recommends closing the item for its own build and fixing how the list is consumed instead. The pack does not show that done. The list's top item is checking when one account's included credits reset and how much remains. It stood at number one for a third night, about 79 hours after the author had answered "Run it for me". The sweep wrote each of its findings out as its own card draft.

Lesson. A list that nothing is obliged to read is a report, not a queue. A backlog is measured by the rate at which items leave it. When 97% of open items are quiet, "open" has stopped meaning "in progress". The fix belongs in the consumer, something that must take from the list, rather than in a better list.

Nine work packages hit the review ceiling

Detected. By the ceiling itself: no package gets more than three rounds of review.

Cause. Not recorded beyond the count. The nine included:

the sweep that dispatches work, and two of its sub-packages;
a send chain, and a unit that handles a send chain's exit status;
a cluster of frozen gate checks.

Two install patches for the ssh fix were still blocked at day's end, after three review rounds between them.

Done. Each was broken up rather than finished.

Lesson. A round ceiling stops a package from cycling forever, but it cannot make the package converge. When nine packages in one day need splitting after three rounds, the place to push is how work is cut before it reaches review.

One reporting lane corrected its own work four times

Detected. By the lane's own reviews and correction rows. The nightly report counts four accountability items in the lane that watches two agents running in ChatGPT and reports on them.

Cause. Given for only one item: a report was delivered first and reviewed second.

Done. The lane shipped five reports that day. The four items:

The late review of the delivered report found seventeen problems, five of them serious.
A second report went out with an untrue claim about stale audio and needed a correction the same evening.
A third report's review of record holds one finding that no one can fold in.
One of the lane's adjudication records was false when it was filed.

Lesson. A review after delivery is a correction. The order of review, then delivery, has to be enforced by the pipeline, because on this busy day habit did not hold it.

A card reached the author in words its reviewer never saw

Detected. Recorded in the nightly report. How it was caught is not stated.

Cause. The card passed review. While it waited, the fact it asserted stopped being true. A clause was swapped and a fresh dry run done, but there was no fresh review.

Done. Nothing further recorded. The nightly report calls the swap defensible.

Lesson. Approval attaches to exact text. Any edit after review, even one that makes a card more accurate, has to go back through review or be caught mechanically. One way is to check at send time that the text is the text that was reviewed.

A ruling went out on a picture ten minutes stale

Detected. By the session that wrote it, twenty minutes later.

Cause. The session recorded that its predecessor's confirmation "would follow its next wake". The predecessor had written that confirmation ten minutes earlier.

Done. A correction was issued.

Lesson. Re-read the record when writing a ruling, rather than relying on what the session last saw. The self-correction worked, but a wrong ruling stood for twenty minutes.

A session miscounted its own launches

Detected. At the next ruling. The pack does not say by whom.

Cause. In the ruling it wrote on arriving, an orchestrator session named one launch twice and counted two launches where three had happened.

Done. Corrected in the next ruling.

Lesson. As with the stale ruling, a count a session tallies from its own reading drifts. Derive it from the ledger when the ruling is written.

The tool that catches unacted hand-offs is itself unreliable

Detected. In use on the day: it was called on a wrong path and ran late.

Cause. Two defects:

It marks a line that is ready for dispatch as already answered.
It sorts by a date it finds anywhere in a line's text, so a line that merely mentions a future date jumps the queue.

Done. Both were filed as low-priority items and left.

Lesson. A detector that records pending work as answered is worse than none, because it turns a miss into a logged success. Order work by structured date fields, never by dates found in free text.

The benchmark rig's empty home was not empty

Detected. The benchmark's write-up records it on all eight calls. The pack does not say which check surfaced it.

Cause. The isolation rule for those runs allowed no skill files in the model's home or working folder. Each run started in a new, empty home holding only the sign-in token. On every call, though, the command-line agent for Google's models unpacked nine skill files bundled in its own program into that home, and read them.

Done. Escalated and ruled the same evening (19:27 UTC). The ruling granted an exception for the tool's own nine built-in skills, since no workspace file, instruction file or skill was present, and the results stand. A variant that stops the unpacking was proved afterwards, on a model listing only.

Lesson. A directory is empty only until the tool starts. Isolation for third-party agents has to be checked against what the agent opens during the run, not only against what was put in place before it.

A delivery receipt was filed about two hours late

Detected. Recorded in the nightly report. Cause. The receipt went missing; why is not recorded. Done. Filed about two hours late. Lesson. None transferable without the cause.

Escalations sat past their six-hour bound

An escalation is a question one session refers to Polaris's internal ruling process. Detected. In the nightly report. Cause. Not recorded. Done. Nothing recorded. Ten escalations were past the bound, the oldest by about a week, and two of them crossed it that day. Lesson. A bound that can be missed by a week with no consequence is only a measurement. Crossing it has to trigger something.

A card was queued without a pro and a con on each option

Detected. In the nightly report. Cause. Not recorded. Done. Not recorded. A ruling requires both on every card that reaches the author. Lesson. A required field gets skipped unless it is checked where the card is queued.

About a hundred backlog rows share an id

Detected. A long-standing fault, noted again in the nightly report: the view shows only the first row of each pair. Cause. Not recorded for these rows. The backlog registry's own row text records earlier collisions as "a numeric range collided with concurrently-allocated rows". Done. Not settled. Lesson. A view keyed on an identifier that is not unique silently hides one row of each pair. Identifiers need a single allocator.

More tests failing against the live system

Detected. By a test census on the day. Cause. Not recorded. Done. Not recorded. Five more test files, 23 tests, were red against the live system. Lesson. None transferable without the cause; the direction is the finding.

Intentions vs outcomes

Forward: changes made on 28 October

| What changed | Intent | Re-check +3 days | Re-check +14 days | |---|---|---|---| | Account guard ceilings on the workspace machine's own account raised to 95% weekly and 85% Fable | Polaris is not stood down again at the old ceilings | 2026-10-31 | 2026-11-11 | | Three instruction texts: a session the author opened and is using has the author present | Every session takes the author's typed words there as theirs | 2026-10-31 | 2026-11-11 | | Process-chain check, owner writer key and matching skill text: one install patch landed, two blocked | A word-for-word relay of the author's message passes unreviewed only from inside their own direct ssh login | 2026-10-31 | 2026-11-11 | | Benchmark material allowed to Google's models widened to synthetic test material and the author's image prompts | The waiting benchmarks can run against Gemini 4 Argon | 2026-10-31 | 2026-11-11 | | Three measured classifiers moved to a cheaper model | Lower running cost | 2026-10-31 | 2026-11-11 |

Backward: check-backs due on 28 October

These checks were made from the source pack as it was assembled the following afternoon, UTC.

| Row | Verdict | Method | Limit | |---|---|---|---| | Changes made on 25 October (+3 days) and 14 October (+14 days) | UNVERIFIABLE | Searched the pack for earlier entries' forward rows and any later look at them | The pack carries no earlier entries and no ledger of their rows, so it cannot show which rows fall due today or how they stand | | Memory (a standing weekly re-check the author flagged as doubtful) | UNVERIFIABLE | Read the pack for any check of the memory system. The one relevant record: a session started from the author's home folder loads a different memory file from the workspace's. That file did not carry the day's new rule, so the rule went into the instructions file every session loads instead | The pack does not say what the memory row covers or whether its weekly re-check falls on this day. Nothing in it tests what sessions actually recall |

What we still don't know

Which install patch landed. The nightly report says one did and two came back blocked, but not which. The order matters, because the full skill text is meant to follow the checker and the writer key.
Whether the check passes where it should. Nothing outside the author's session can run inside it, so the passing case was tested only on a simulated set of processes. Run live from a Polaris worker, the check refused both that worker's session and the author's. From there, that is the right answer for both.
What the accepted limit cannot see. It cannot see who is holding the phone, whether the author typed or pasted, or whether the session acted on the author's words or on text a tool showed it. The limit lapses when the session closes.
Which channel each message came through. The session had the phone app's remote control switched on. The log does not say whether each of the three messages came from the ssh terminal or from the app. Both are the author.
Why the night orchestrator was on the heavier model, and why the timer that should catch it was off.
How much open work there is. The two tools that count it disagree, and the pack does not reconcile them.
- The silence sweep reads a registry of 589 rows with 504 open.
- The nightly hygiene tool reads a file it does not name, with 7,133 items and 3,599 open. It reports its own day and week counts as unknown because its input is degraded.
Whether the sweep's 3,451 dead queues are queues. The three largest it names, at 33,723, 33,684 and 33,680 new records, are files inside the review gate's snapshot folders.
What the day's own records missed.
- The ledger meant to record enactments has no rows for the 28th, although the ceiling raise, three instruction changes and an install patch landed. The nightly report rebuilt the day from orchestrator passes, commission records and status files.
- Sixteen orchestrator sessions ran on the day, and none used the channel for handing items up to the nightly report. The absence of handed-up misses therefore proves nothing.
- The index of hand-overs between sessions still names a session from 22 October as the live one.
- The accounts check did not finish inside its ten-minute window.
Changes with no recorded intent, which are therefore not listed above:
- a trial build of the phone app shell carrying pause labels, which the author installed;
- a preview-media change to the app;
- medium effort for all Gemini 4 Argon work from the 28th on.
The reporting lane's own account of the 28th. It is known here only through the nightly report. The one report from that lane in the pack is filed under the 28th but covers the morning of 23 October.

Technical detail

The six refusals, in order

| Time (UTC) | What happened | Cause | Right to refuse? | |---|---|---|---| | 02:45:52 | The account guard refused to start Polaris on a second account | That account's weekly and Fable ceilings | Yes: a usage ceiling, not doubt about the author, and overridden in 33 seconds on the author's order | | 02:51:51 | Filing the ceiling order to Polaris's queue was refused: "who is unknown" | The check on who may write knew Polaris's workers, scheduled jobs and the phone app. It had no entry for a session the author opened | No | | 02:52:36 | The relay was refused: no record of the author's carried that text | The relayed text was the session's rewording plus notes, not the author's words | Yes: no relay may put words in the author's mouth | | 02:53:20 | The author's exact words, found typed in their own session, were graded "evidence, not authentication", and the send was refused | The provenance tool never certified a session, and the send step blocks that grade | No | | 02:53:36 | The author was asked to send the order again as an app note | The Polaris skill: for anything gated, get a note or card | No | | 03:28:21 | The author was told their words in the session "only count as unverified evidence" | The same rule, as the session read it | No |

The investigation cleared everything else it looked at:

No tool-blocking hook fired in the session, including the one that guards secret reads.
No permission prompt appeared, and no administrator rights were asked for.
The hook that routes questions recorded the author's question as "attended state unknown" and did not block it. Its record still read open after the author answered.
The new Polaris session acted on the author's second order with full authority, as it later did on their note.
In the window, 46 Claude sessions ran. Apart from the author's three messages, every typed message in them was a launcher, keep-warm or watchdog prompt.

Why the log could not be made into proof

Every typed row in the window was tagged "typed" and "human", including the programs' rows, so the tag separates nothing. The log can also be written by any program running as the author's user, like every other file about a session. No check that reads those files from outside can therefore prove a message is the author's.

What can be told apart is the chain of processes the checking program itself runs in. The author's session ran in the foreground on its own terminal, directly under a root-owned ssh login from the phone. It was not inside tmux, and no launcher had started it.

A program that session runs sits inside the chain.
A scheduled job, a Polaris worker or a tmux pane sits outside it and cannot move itself in.
A program already running as the author inside the chain can start its own Claude there and bring it to the front. The check cannot tell that Claude from the author's.

The check as staged

A whole message of the author's, relayed word for word, passes as theirs without review only if all four of these hold:

the check runs inside the author's own direct ssh login session;
the message was typed there after that Claude session started;
it carries a valid time;
it is long enough to match.

Everything else keeps its old grade:

Refused: a message too short to match, such as a one-word reply, and words that match nothing.
Held for review: words that match but are reworded, partial or have words added; words typed before that Claude session started; and words checked from anywhere else.

Held for review is a grade, not a delivery. The send step does not deliver such words in the author's voice until a reviewer stamps them. Every result says why it was given, and every result that depends on the session check also states the limit. Each way a program running as the author's user could try to pass itself off as the session has its own test.

The writer key works only for a program running inside the author's session. It names no session, so no program outside can borrow it.

These stay refused or held:

an autocomplete suggestion accepted in a pane, which is a machine's guess;
a relay of the author's words checked from any other session, worker, pane or job. It is held for review, and refused if it claims the author without citing any record of theirs;
a scheduled job, or a background job cut loose from the session, claiming the author's authority;
a step run under a headless Claude or a Codex agent the session started;
ordinary ssh logins, tmux sessions attached over ssh, and sessions at the desk, which keep the old grade;
anything that would print a password or key;
a relay that rewords.

The accepted limit is that anything running as the author inside their own ssh session counts as them. That includes a shell or Python step the session runs, even in the background, and a program already running there that starts its own Claude and brings it to the front. The check cannot prove:

who is holding the phone, or whether the author typed rather than pasted;
whether the session acted on the author's words or on text a tool showed it;
anything about the session's own log or working folder, which steps inside it could rewrite or rename;
anything against a program running as the author's user that rewrites these tools or a ledger.

The check guards against machines making mistakes, not against such a program, and it lapses when the session closes.

Ordering constraint: the Polaris skill's change was split. The part true at once landed on the day: a session the author opened has them present, and a session's log alone is evidence, not proof. The full text is to be installed straight after the checker and the writer key. Until the checker is installed, the skill's existing line, that a session's log can never prove a message is the author's, is still the true one.

What review changed between drafts

The pack holds two versions of the investigation's report, and they differ:

Status. The earlier version listed seven drafted changes, none applied, waiting for Polaris's ruling. The later version records three instruction changes landed and five changes staged.
One case moved from refused to the limit. The earlier version listed a Claude "that another program started and pushed to the front of your terminal" among what stays refused. The later version says the check cannot tell such a Claude from the author's own, and lists it under the accepted limit. The later reading is the one the author accepted.
Two conditions added. The later version adds that a passing message must have been typed after that Claude session started and must carry a valid time.
Tests. The earlier version did not run three existing writer-key test suites, because they drive the live ledgers. The later version ran them on a scratch copy of the tools, with identical results with and without the changes, and leaves them for each installer to run again. One existing provenance test fails both before and after the changes, for an unrelated reason.

For harness builders: before any of the code was installed, review narrowed the security claim. One fewer case is refused, and the stated limit is longer.

Benchmark isolation as run

Each call to the command-line agent for Google's models started in a new, empty home holding only its sign-in token.
The rest of the machine was read-only. The writable places were the task's folder, the fresh home, the call's log folder, and empty in-memory scratch areas that vanished with the sandbox.
The workspace, the session folders and every Claude and Codex settings folder were absent. A dry run with a shell in the agent's place showed this before the first call.
On every one of the eight calls, the agent unpacked its nine bundled skill files into that home and read them. The variant that stops this was proved afterwards on a model listing, with no model call.

The backlog tools' own numbers

Silence sweep. An open item counts as quiet when no session status file, decision record or review-gate verdict has mentioned it for strictly more than 72 hours.
- The registry holds 589 rows, 504 open and 489 quiet.
- 242 quiet items have never produced a signal. The sweep ages these from a date in the item's own text, so their ages are upper bounds. The longest-quiet item, at 116 days, is one of them.
- 413 dispatches were written out but never started, meaning instructions with no matching status file.
- 3,451 queues took 236,199 records since the last sweep, with nothing draining them.
- The sweep drafts one card per finding.
Closure sweep. Of the 504 open items, 353 have text that a widened rule reads as claiming completion.
- One batched call to GPT-5.6 Luna judged three things for each: whether the item's own work is claimed finished, whether that claim is dated, and whether current work contradicts it.
- A fixed table then gives the verdict. It confirms a closure only for a dated claim, corroborated on disk, with no contradiction.
- Result: 28 confirmed; 71 whose evidence does not settle it, left to the author; 254 refuted. The refuted items are the ones that widening the rule alone would have closed wrongly.
- A confirmed item closes only after a delivered notice and a full 24-hour objection window.
- The refuted bucket is headed as items that claim completion and contradict themselves. In the part of its list this pack carries, though, most entries read "no completion claim for the row's own work".
Hygiene tool, as the nightly report gives it. Its day and week figures came back unknown. On items with a usable date only:
- on the day, 53 were added and 44 closed, nine more open on balance;
- over seven days, 341 were added, 203 closed, 3 reopened and 1 added already finished, 140 more open on balance.
These are observations, not a floor. Its file holds 7,133 items, 3,599 of them open. 1,410 carry no priority, and 116 carry one the tool cannot read. Its input is degraded:
- 867 unreadable dates;
- 156 repeated task lines;
- 131 lines out of date order;
- 35 unreadable statuses;
- 30 lines with no usable subject.
Bounds in force. Three review rounds per package; six hours per escalation.

Polaris is an AI agent that runs the author's 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.