2026–08–17
Nobody needs a micro-close.
A wish from a simulated user became a better ritual — by deleting the feature the user asked for.
FRACTAL sessions end with a close: a checklist walked over the living documents, two machine checkers, a handover for the next session, and — when decisions were made — a protocol recording the reasoning. It is the ritual that makes project memory trustworthy. And it has a price, sized for sessions where real decisions land.
During a simulation program, a synthetic user — a content creator running many small sessions — hit exactly that price: for a five-minute session, the full ritual felt absurd. The wish was recorded faithfully: give us a micro-close. A lighter tier, fewer steps, for small sessions.
The obvious cure is a second ritual. The better question, asked by the founder, was: could the close automatically touch only what needs renewal, so that a small session’s close turns out to be a micro-close by itself?
The close was conditional all along
Reading the ritual closely: every row of the closing checklist already carries a refresh trigger; the protocol rule already contains an escape (“or a recorded reason none was issued”); the store checker only fires when the store was touched. The design was adaptive from birth. What made every close cost the same was two manual habits sitting on top: verifying that nothing changed costs as much as changing, and the narrative artifacts default to full size.
Under these rules there is no micro-close to build — and nothing to choose. A small session’s close emits the small shape; a decision-heavy session gets the full ritual it deserves. One mechanism, scale-invariant. The feature request was cured by deletion.
The boundary that stays: a close of any size ends its conversation — adaptivity changes the close’s cost, never its meaning. And the judgment on rows that did change stays human; the mechanization program drew that line deliberately.
Of record: decision C-112, riding the diet program’s mechanization slate (C-110). The micro-close wish: finding RF1, refinement simulation, 2026–08–17.
2026–08–17
Put the memory on a diet — then prove the pointers hold.
Living documents accrete. The cure is eviction to pointers — adopted only after a blind experiment showed agents actually follow them.
A project memory has two tiers: a frozen record (protocols, dated reports — append-only, complete) and a living tier the agent reads at session start. The living tier accretes: histories re-narrate what the frozen record already holds, ledger rows grow annotations, one decision re-tells itself across six surfaces. Measured on FRACTAL’s own corpus: one register grew 19 KB to 200 KB in five days; one paragraph was growing 460 words a day.
The instinct — write everything compactly from day one — is wrong. Early in a project, rich clustered prose is what lets an agent interpret anything at all. The correct model is a cache: accretion is the default mode at every age, and a diet is the callable eviction pass — cold entries compact down to pointers into the frozen record. Nothing is deleted; the trade is ambient availability for efficiency.
The experiment: do agents follow pointers?
Eviction is provably lossless on disk. The open question was behaviour: does an agent reading a compacted row follow the pointer into the frozen record when depth is needed — or does it stop at the pointer and improvise? So before adopting, the compaction was gated on a blind two-arm test: identical corpora, one with the evictions applied; twelve gold-answer questions across three depth classes; six agents, told nothing of the design, answering from whichever corpus they got; every answer scored for correctness and for whether the frozen evidence was actually opened.
The two failure modes the experiment surfaced became the standard’s two gates. The pointer grammar: every compacted row names the concrete file holding its narration, and index tables declare themselves index-only — a row that says what without flagging that the why lives elsewhere invites being treated as the answer. The fact-presence gate: before any row compacts, verify the target actually holds the narration — the adversarial verifier caught one row whose content existed nowhere else; file-existence checks pass exactly this defect. Content born in a living row relocates into the frozen record first, or the row keeps its prose: eviction waits, never forces.
The phase answer falls out of the same gate: a young project has almost no frozen record, so almost nothing may be evicted — rich prose is protected structurally, and the pointer form becomes reachable region by region as the record matures. No mode switch; the gates simply become satisfiable.
Of record: Fractal_Diet_Procedure_v0.1 (decision C-111), distilled from the diet measurement flight (DF1) and the compaction-behaviour experiment (CB1), adversarially verified before ratification — 22 findings, all cured in draft.
2026–08–17
The Scan: hunting what the machines can’t see.
Checkers guard what they were built to guard. Drift lives in their declared blind spots — so a commissioned review hunts exactly there.
A governed project runs mechanical checkers — but a checker only guards claims someone taught it. What about contradictions between documents, present-tense claims that quietly became false, mechanisms relied upon but never defined? For that, FRACTAL runs Scans: whole-project adversarial reviews for loose ends not explicitly stated.
- Commissioned, never scheduled. Every Scan is fired by an explicit request, with a recorded mandate. No calendar — a watched date is itself the kind of ritual that silently rots.
- Frozen at issue. A Scan is a dated observation of the project at one commit; it is never revised. Corrections land in later records — destroying what a review said would destroy the ability to learn from it.
- Findings, not fixes. Every finding carries a stable id, severity, file-and-line evidence, and — where a checker exists — the reason the machine missed it. Fixes are proposals until the commissioner adopts them; each adopted catch tends to become a new mechanical rule, moving the frontier of what the machines guard.
- Non-findings are recorded. What was checked and found sound is stated as precisely as the defects — a review that only lists problems can’t tell you what it covered.
Across four Scans the finding count fell 26 → 24 → 8 → 7 while the corpus tripled — the trajectory of drift being converted, catch by catch, into mechanical guarantees.
And the standard holds itself to the discipline it preaches. In FRACTAL, a standard ships in two halves: the prose and the checker — a standard without a checker is a norm, not a gate. When the prose is ready before the machine half, that is said honestly (prose-first) and the checker's build trigger is armed as a hard condition: the Scan standard shipped with the rule that the next Scan cannot close until its conformance checker exists — a tool that mechanically validates the report's grammar, its evidence block, and that every finding actually landed in the project's ledger with a disposition. Until that trigger fires, the obligation sits visibly in the queue; it cannot be quietly forgotten, because forgetting it is exactly the drift a Scan exists to hunt. The standard refuses to become its own blind spot.
Of record: Fractal_Scan_Procedure_v0.1 (decision C-108), distilled from the four executed Scans of 2026–08; the checker gate is its §12.
2026–08–17
Multi-agent work under a contract.
Dozens of agents are cheap. Ungoverned, so are their mistakes. The flight protocol makes the swarm accountable to one commissioning contract.
Modern agent tooling will happily launch a fleet — parallel readers, adversarial verifiers, judge panels. The failure mode isn’t capability; it’s governance: programs that launch before anyone agreed what they may touch, scopes that grow silently mid-run, results that arrive as assertions nobody can audit. FRACTAL runs multi-agent programs as ultracode flights under a ratified protocol:
- The commissioning contract, declared before launch: scope, phases, agent structure, per-phase effort, the verification tier, and what the landing may claim — all stated to the commissioner first.
- A fixed launch sequence: game plan proposed → agreement → an explicit arming step — the next go starts the flight — with effort locked at launch. Changing effort mid-flight is prohibited; the contract is sized for the hardest phase before anything flies.
- Verification is a declared choice, and it caps the claims. A single-pass work-over may not claim what only an adversarial multi-agent verification earns. The strongest results here paired every finder with independent skeptics prompted to refute.
- Landings are proposal-only. A flight lands a frozen, dated record; findings enter the ledger; nothing in canon moves without the commissioner’s adoption.
The procedures on this page compose with it: a Scan, a diet, a behaviour experiment can each run standalone — or plug into a flight when the job needs a fleet. The protocol itself was distilled from the programs that preceded it, frictions included: it exists because an early program launched undeclared, and the record of that friction is cited in the standard.
Of record: Fractal_Ultracode_Flight_Protocol_v0.1 (decision C-108), distilled from the flight programs of 2026–08 — including a 67-agent adversarially verified capture program and the experiments described above.