Talwrn foundation: stable current decisions without treating status as acceptance

Original operator account: Giles Edwards-Alexander, “Talwrn: Laying the foundation,” August 30, 2026, 13-minute first-person construction and planning record. His earlier workshop account appeared on his site August 29 and was republished by Fowler September 2. Thus this follow-up predates Fowler’s publication even if it looks downstream in search results. It lays foundations for a proposed agent coordination system after a Barcelona practice workshop; the article ends before implementing, shipping or trialling that system with another project. See comparison brief and planning hub.

Owner decisions and delegation. The author gives Claude one initial prompt to generate an overview and agent-facing index, then asks the agent to interview him before choosing architecture and tech. Three rounds produce, among other choices, a git-first drop-in board, per-writer append-only JSONL tuples, a separate orphan branch, debounced synchronization and no task-control layer in the first version. He does not ask the model to proceed directly from a general goal to implementation; he reads proposed plans and changes them. In this particular project he requires an accepted plan to be committed and pushed before implementation so other agents can see it. That is an implementation coordination rule, not a claim that a discovery prototype should turn into production code.

Cost and fidelity of memory. Previously, immutable architectural-decision records proliferated under agents, multiple workers claimed the same next ID, and an accepted obsolete choice required another document to supersede it. He chooses a directory of short current decisions with stable IDs and dependency links; a reader can navigate a single index rather than replay the entire discussion. This helps agents find prevailing choices but could hide why a human reversed one unless the prior reasoning remains retrievable elsewhere. He spots a stale invariant table reference after adding a tuple schema, and says six documentation-writing failures had been caught only by a person reading files; that motivates deterministic document checks. He proposes formal Alloy/TLA+ models and trace conformance, and asks tests to break on the old implementation before they pass on a changed one. These are planned safeguards, not a reported deployed/independent oracle. For the prototype’s threat boundary he chooses to trust repository write access, a scope assumption not transferable to multi-party product/support work.

Open test. Wait for a public Talwrn version and a second team's real task. Record who changes an ID when requirements reverse, how agents learn the corrected decision, whether the board adds human triage minutes or saves CI load, and which independent requester/device/browser check overrules a coherent but wrong plan. The essay explicitly ends with deployment planning still to do; do not treat a proposed self-hosting milestone or formal specification as a proven release gate. This is a weekend long read if the shorter blackboard post engages Dru or if a later Talwrn deployment appears.