Trial notes — cold run of analyse-agentic-system on sequentialthinking

Trial apparatus. Not part of the instruction's logical result. Run AGS-2026-08-21-SEQTHINK, executed 2026-08-21 against /home/zby/llm/servers @ 2ecb382a.

Cold-trial conditions honoured: no file under trials/ other than this run's own directory was read; no other workshop file was read; no kb/ file was read except candidate.md and the epistemic instruction it invokes at step 7. Both lens workers were spawned with the same prohibitions in their prompts.

---

1. Lens-scoping reasoning, and how depth was decided

The instruction gives one rule for depth — "warranted depth follows the evidence; rich trigger evidence warrants a full pass, thin or degenerate evidence warrants a brief one" — and one floor. It does not say how to weigh triggers of different kinds against each other, so the reasoning below is mine.

Memory/context → brief. The decisive move was applying the run's own read-back definition literally. The server retains every thought forever (process-lifetime) and returns, on each call, Object.keys(branches) and thoughtHistory.length. Under a naive reading that is "just current-run state in a long-lived process" and there would be no read-back at all. Under the instruction's definition — consumer-invocation boundary, derived values count, label sets count — it plainly is read-back. The definition is written to make read-back easy to trigger and says so. So the honest scoping is: read-back present, and degenerate. Present rules out brief because nothing is there; degenerate rules out a full pass. The tell was the read side: two reads of retained state exist in the whole file, and neither touches content. There is nothing for items like selection signal, budget, targeting, consolidation, decay, or promotion to bite on — a full pass would produce eight rows of "none, and here is the line number proving none". Brief, with the prevented-conclusion pairing intact, carries the same information.

Epistemic → full. Two triggers, and the second is what decided it. (a) Truth-apt content really does cross the boundary: thought strings are propositions the artifact acquires, retains, and reshapes. On its own that is thin — acquisition plus storage plus display. (b) The artifact makes an explicit knowledge-production and warrant claim: the tool description's "Key features" list states that the tool "Verifies the hypothesis based on the Chain of Thought steps" and "Provides a correct answer". Step 5 names exactly this as epistemic trigger evidence — "any consequential knowledge-production or warrant claim the system makes — including where the eventual finding is failure or absence." A verification-and-correct-answer claim sitting next to zero evaluators is the decision-relevant finding of the whole run, and establishing it properly needs the route ledger and the claim-comparison table, not a bounded confirmation of thinness. Cost also mattered: the artifact is 279 lines, so "full" is cheap.

The asymmetry (brief memory, full epistemic) felt right and is supported by the text, but I had to reason it out rather than read it off. The instruction would be stronger with one sentence saying that a claim can warrant depth that the routes alone would not.

2. Friction points

Recorded as required. Ordered roughly by how much they cost.

F1 — The direct-adaptation exception collides with the invoked procedure. Step 5's exception says a route with no truth-apt object "stays in the runtime account, and the scoping record names it for the orchestrator rather than handing it to the epistemic lens to analyse as an epistemic route." But the epistemic instruction invoked at step 7 has, in its own step 4 and its content/update relation vocabulary, an explicit class for exactly these: non-truth-apt policy/content update: <description>, and it instructs the analyst to classify every content-changing edge it encounters. So the wrapper says "don't hand it over" and the invoked method says "classify it when you see it." The candidate here was RTE-4 (raise totalThoughts to thoughtNumber on overshoot). I resolved it by handing RTE-4 to the lens labelled as classify-only-as-non-truth-apt, not to be analysed for warrant, and told the worker that concluding otherwise must come back as a correction rather than a silent scope expansion. That preserved both rules but required improvisation. The wrapper should say which of the two governs.

F2 — Two forward dependencies force a two-pass write. Step 2.4 says freeze sources at step 2 but assemble the packet after step 4; step 3 says the evidence tier is judged over the loops "recorded in the step-4 runtime baseline"; and step 9 orders the tier as logical record 2 while the runtime account is record 5. All three are individually reasonable and the instruction is visibly aware of the first one (it spells out the 2.1–2.3 → step 3 → step 4 → assemble sequence). The net effect is still that a first-time executor reads steps 2, 3, and 9 twice before writing anything. Cost: real but bounded; no wrong output resulted.

F3 — "Consume only the prepared evidence packet" versus the step-7 invocation. Step 3's worker-topology rule says fresh workers consume "only the prepared evidence packet and the frozen read-only boundary." Step 7.1 requires the epistemic lens to run the method in kb/instructions/analyse-external-system-epistemic-architecture.md, which is neither. I read "only" as constraining evidence sources rather than method documents, and authorized that one file explicitly in the worker prompt. Worth a clarifying clause, especially because the cold-trial prohibition on reading kb/ made the exception load-bearing.

F4 — ABS-* versus ordinary design facts. An ABS-* record is "a finding whose status is absent, carrying the named, recorded search boundary." That is clear for things like "no evaluator of thought content." It is less clear for facts that are absences only under a framing the analyst chose — e.g. "no per-connection state isolation" (registered as ABS-5) or "no downward adjustment of totalThoughts" (ABS-8). Both are genuinely not-found-within-boundary, so I registered them; but nothing in the instruction stops an analyst from inflating the absence register indefinitely, since for any system infinitely many things are absent. What disciplines it in practice is the requirement that each absence name the conclusion it prevents or supports — an absence that prevents nothing has no reason to exist. That discipline is implicit; making it explicit ("register an absence only when it bounds a conclusion someone would otherwise draw") would help.

F5 — Recording a crossing loop risks looking like a conclusion about it. Step 4.2 requires the full field record for each material loop; the complete artifact, partial loop boundary kind means one material loop (LOOP-C, the advertised thinking loop) has its next-step owner outside the boundary. Filling in fields like "decision policy", "context selection", and "persistence" for a loop I am forbidden to conclude about reads uncomfortably close to describing external behavior. I handled it by filling the fields with what the artifact contributes to each, marking the rest as owned by the named external participant, and appending an explicit limitation line. The instruction does not say how to record a crossing loop's fields without over-reaching; a sentence would help.

F6 — "generic identity, form, substrate" is underspecified. The canonical-records table gives CMP-*/OBJ-* ownership as "Orchestrator/runtime owns generic identity, form, substrate". "Generic identity" is not defined anywhere. I read it as: the orchestrator fixes what the thing is and what it is made of, and lenses add lens-specific fields by ID. That reading worked, but it was a guess.

F7 — The implemented collision is real and the mitigation is manual. Step 3 is explicit that this run's conclusion status implemented and the epistemic method's architectural status implemented are different fields that must never be merged. Good warning — but the enforcement is entirely the executor's discipline, and the two vocabularies meet inside a single worker's output where the pull toward collapsing them is strongest. I restated the collision at length in the worker prompt. It is the one place in this instruction where I would expect an unassisted run to fail quietly.

F8 — Old-but-clean boundary. The checkout is at a December 2024 commit, ~20 months before the analysis cutoff. Step 2.2 allows this ("a stable but old or partial boundary is allowed with an explicit published limitation"), and the harness forbade refreshing, so the rule applied cleanly. Noted only because every conclusion in the result is pinned to a revision that is almost certainly not upstream's current state, and a reader skimming the synthesis could easily miss that.

F9 — Minor: step 1.1 says "allocate one run/result ID before any analysis" but gives no format guidance. I minted AGS-2026-08-21-SEQTHINK. No cost, but two runs by different executors will not have comparable identities.

F10 — The correction branch is the instruction's strongest mechanism, and it needed no improvisation. Recorded as a positive because it is the clearest signal in the trial. Both lens workers found my prepared packet defective in ways I had not seen, and the instruction's rule — return the correction with its evidence anchor instead of re-inventorying — routed both cleanly. The epistemic lens's OBJ-5/c1 is the case that matters: I had registered the tool description as "54 lines of instruction addressed to the model in the second person", which is misclassified by the very criterion my own record stated. Left standing it would have licensed the conclusion that the description cannot mislead, because directives have no truth value. It is roughly half third-person assertion, and the assertive half carries the run's headline finding. The instruction's definition of "defective" — false, misclassified by its own stated criterion, or accurate but misleading at the scope stated — named this case exactly. Without the middle clause I would probably have rejected the correction as a matter of emphasis. The "reruns only the work that relied on it" rule also resolved cleanly: no rerun was needed, and the instruction distinguishes this branch from targeted-read invalidation clearly enough that I did not have to guess.

F11 — The invoked epistemic instruction's early branches overlap, and Branch 2 ends with "Then stop". Surfaced by the epistemic worker, and I flagged the overlap in its prompt because I expected it. The two step-3 branches both partially fit this system: the inventory is dominated by storage and serving (Branch 1's first condition), and the system makes an explicit knowledge-production claim (which defeats Branch 1's second condition and triggers Branch 2). The worker resolved it correctly on Branch 1's conjunctive wording. The harder problem was Branch 2's closing "Then stop", which read literally would have discarded the implemented routes the material-route rule had already admitted — including the artifact's only real truth-apt edges. The worker reasoned past it, on the grounds that Branch 2 prescribes what to do about the claim and does not retract the inventory. I agree, and the reasoning is recorded in its output. But this is the one place in the run where a worker had to override an instruction's literal text to get the right answer, and it is in the invoked procedure rather than the wrapper. Worth fixing upstream.

F12 — Mild redundancy between step 7.4 and the canonical-records table. Step 7.1 forbids copying or restating the invoked procedure's method; step 7.4 then enumerates the returns it must produce, which restates a good deal of that method's shape (transformation class, architectural status, the three authorities, checking/acceptance/retention separation). The two rules are not in conflict — 7.4 specifies the interface, 7.1 forbids duplicating the procedure — but the boundary between them is fuzzy enough that I spent time deciding how much of 7.4 to put in the worker prompt. I erred toward including it, since the worker could not otherwise know what the orchestrator would check.

F13 — Physical layout is deliberately unfixed, and the "one canonical location per record" rule carried the weight. Step 9's separation of logical order from physical layout worked: I distributed the eleven records over five files with an index table, and the rule that each record names one canonical location made the choice mechanical rather than aesthetic. The only real decision was whether the evidence packet — which exists as worker input — could also be the canonical home for records 1–5. It can, and doing so avoided duplicating the registers into a second file where they would drift.

F14 — Apparatus race: I edited the packet while a worker was still reading it. After the memory lens returned I registered its corrections into evidence-packet.md while the epistemic worker was still running. The epistemic worker therefore saw the pre-correction ABS-2 and OBJ-3 rows. No harm resulted — it derived its branch-route findings directly from the source lines rather than from my enumeration, so nothing it concluded rested on the defective text — but the instruction does not say whether the frozen packet is immutable for the duration of the run or amendable as returns arrive. I chose amendable and verified afterwards that no finding depended on the superseded text. A rule either way would remove the need for that check.

3. Things I could not do

• No observed run, no causal experiment. There are no tests, fixtures, logs, or traces anywhere in the subtree, and the harness forbade executing anything or fetching dependencies. Every finding in the run is therefore capped at conclusion status implemented / architectural status implemented. This is recorded as ABS-4 and as a limitation in the result, not treated as a gap I worked around.
• The MCP SDK is uninspected. node_modules is absent from the checkout and I was forbidden to fetch. So the protocol dispatch half of LOOP-A rests on the registration surface only. Declared as external dependency EXT-1 with its prevented conclusions.
• No publication. The harness declared no authorized target; per the instruction's publication rule the logical result is retained under the staging identity and the blocker is recorded as logical record 11.
• No deterministic validation. Step 10.3's branch for "no authorized target contract" applies: no deterministic validation applicable, semantic checklist run instead. I did not adopt an unrelated contract to manufacture a validation path.

4. Execution notes

• Both lenses ran in fresh spawned workers (the instruction's preferred topology), in parallel, each given only the evidence packet, its own scoping record, the read-only source boundary, and — for the epistemic worker — the invoked method document. The sequential fallback was not needed. Neither worker terminated early, so the "written artifact is authoritative over the self-report" rule was not exercised.
• The orchestrator held the canonical ID namespace throughout; workers proposed under MEM-n / EPI-n tags and neither minted a canonical ID. Registration outcomes are in result.md §8.1. One convergent proposal — both lenses independently found the RTE-6 truthiness defect — was merged into one amendment rather than issued two IDs, which is the behavior the proposal-tag rule is designed to produce.
• The orchestrator independently re-verified the run's headline finding against source (index.ts:148–157, :177–188, :192–195) before accepting it, rather than registering a worker conclusion unchecked. The feature/instruction one-to-one mapping and the stripped "ideally" hedge both hold.

5. What the trial says about the instruction

Separable from the friction list, and the reason the run is worth keeping.

• The scoping step did real work. Forcing an explicit depth decision with named trigger evidence, before any worker saw the material, produced an asymmetry (brief memory, full epistemic) that a uniform pass would have gotten wrong in both directions — over-analysing a degenerate memory path and under-analysing a claim mismatch.
• The read-back definition's deliberate looseness paid off. Its explicit note that easy triggering is intended, and that a degenerate finding is itself the finding, is what stopped me recording "no memory here" for a system that does return accumulated caller-authored text. The precise version — retention total, retrieval nil, branch labels the only returning authored text — is more useful than either rounding.
• The three-way authority separation is what made the headline finding statable. Because behavioral, epistemic, and operational authority are kept apart, "the artifact grants no epistemic authority over any thought's content, while shipping an unsupported verification claim on its strongest behavioral channel" comes out as one clean sentence rather than a muddle about influence.
• The weakest enforcement point is the implemented collision (F7). It is the one rule whose violation would be silent, invisible in the output, and fatal to the result's meaning, and its only defense is executor discipline restated in a worker prompt.