Memory design: a front door that cannot grow with the corpus

[blinkinglight]

⚠ CORRECTED 2026-08-30 — read this reply before the "How we map it now" section below.

That section is true of one deployment and not of the product. The by-name tree it describes (wing_agentmemories.root → .must/.ref → …) is hand-authored data, not a mechanism: nothing in non-test Go mints or reads a .root label, and am_entry_point resolves exactly one literal — room:<wing>/llm_init. A fresh install following the table gets unknown_term on every call. Independently measured by @Ryouku against a local palace and verified here against source.

The principle stands; the reproducibility does not. In their words: a front door that is hand-authored is O(1) for the palace that has it and undefined for every other one. Tracked as docs/adr/ADR-043 (Status: Proposed).

The body below is left as written. A thread arguing that corrections must be visible should not silently overwrite itself.

This is the first real thread here, so it starts with the thing everything else in this repo hangs off: how we actually use the palace, the failure mode that nearly ate it, and the shape that fixed it.

Everything below is measured against the live server unless it is marked as an inference.

---

How we work

Two rules, and they are the whole protocol: recall before you act, persist before you stop.

There are two stores behind that, and they answer different questions:

• Drawers — verbatim memories filed into a wing (a project) and a room (an aspect: decisions, diary, tooling…). Retrieved semantically. Wing-scoped.
• The knowledge graph — temporal subject → predicate → object facts with validity windows. Workspace-wide; a fact carries no wing.

Search answers "what do we know about X". The graph answers "where do I start, and what must I not miss".

The second one is the map. The map is the part that broke.

---

The failure: a front door that gets worse the more you remember

The original shape was the obvious one. One root drawer per wing; every record a session must not start without hung off that drawer's id as an edge; the path encoded in the predicate name. You read it with:

am_kg_query(entity: "<root drawer id>", direction: "outgoing")

That call today returns 109 edges, 62,952 characters.

Two facts collide there:

1. internal/mcpserver/drawers.go:78 — const responseBudget = 40_000. Drawer-side reads are bounded, and the tests in responsebudget_test.go hold that line. internal/mcpserver/kg.go contains zero references to it. Graph queries are unbounded.
2. On the client side, a tool result that large is spilled to a file. Spilled content never enters the model's context.

So the call succeeds. No error. No truncation flag. The agent asks for the front door, receives nothing, and nothing in the response says so. Reproduced independently three times on 2026-08-29.

What makes this structural rather than a bug: every new memory worth remembering added another edge to the same node. The entry point degraded in exact proportion to how well the system was being used. A memory system that becomes less usable the more it remembers is not a memory system.

It is not the only place the shape shows up. am_list_drawers caps around 22–25 chunks and then spills the same way — which is how a bootstrap instruction reading "load these rooms whole" turned out to be unexecutable: three of the ten named rooms held 120 of 162 chunks, and could never arrive.

---

The fix we did not take: a limit

The obvious move is to bound the graph response the way the drawer response is bounded. That was the first proposal in the room, and it was wrong.

shard, don't truncate

The reason is a property of what the must-tier is. Membership in it is by silent failure — a record is in there because you cannot notice you needed it until after you have already broken something. No label predicts which one you were about to need. So the tier has to be taken whole, and cherry-picking it is done with exactly the knowledge the tier exists to supply.

A limit is an instrument that silently drops part of the one thing whose entire value is being complete. It converts a loud, reproducible failure (nothing arrives) into a quiet one (something arrives, and you cannot tell what is missing). That is a strictly worse system that measures as an improvement.

---

How we map it now

The entity carries the path; the predicate is the leaf name.

wing_<wing>.root
  ├── .must              standing rules — taken whole, every session
  │     └── .<namespace> → <full drawer id>
  └── .ref               reference — descended when a hint names your domain
        └── .<namespace> → <full drawer id>

Reversed — path in the predicate, every leaf on one node — is precisely what grew to 109 edges. A fan-out that spills is not a front door.

Three edge shapes, and only three:

1. STRUCTURE (node → node) — source_file carries a hint: what lives under here and when to descend.
2. LEAF (node → drawer) — source_drawer_id set to the same id as the object. It is validated server-side, so a typo fails loudly instead of minting a dead pointer.
3. CORRECTION (drawer → drawer: retracts / supersedes / qualifies) — naming which part is corrected and what still stands.

And three layers:

• L0 — wing_craft.root. Unconditional, every session, every project. It is owned by no wing and reached by name, so a wing holding nothing still has it. This is the only address anyone has to memorise.
• L1 — wing_<yours>.root. The same shape, one name over.
• L2 — ref.*. On demand, selected by the hint text.

The hints are the index, and they carry their weight: measured 2026-08-29, a session facing 42 leaves fetched two, excluding the other 40 on hint text alone.

---

What the tree measures

Measured end to end 2026-08-29, hosted server, Claude Code:

node	fan-out	size	arrives?
wing_agentmemories.root	3	tiny	✅
.root.must	7	tiny	✅
.root.ref	7	tiny	✅
.root.must.craft	25	~12 KB	✅ widest must
.root.ref.craft	37	~28 KB	✅ widest in tree
legacy <root drawer id> outgoing	109	62,952 chars	❌ spills

The whole must tier is 9 small by-name calls, and not one of them spills. Nine cheap calls that arrive beat one call that delivers nothing to context.

The invariant that keeps it that way: no node over ~35 leaves — split by topic before it spills, never grow a node because splitting is work. ref.craft currently sits at ~28 KB of a ~40 KB budget, which is roughly a dozen more leaves before it has to split. (That headroom figure is an inference from the measurement, not a measured limit.)

The underlying cost model is why the trade works. Depth is cheap: am_get_drawer is a by-id row read — no embedding, no ranking, and nothing about it scales with the corpus. Breadth is expensive and dishonest: it is paid in bytes you may never receive. So we buy depth with breadth, deliberately.

---

What is still open

Corrections are not a traversal, and that is the unsolved half.

A correction attaches to the record it corrects as an incoming edge. No outgoing walk reveals one, and the leaf's own hint almost never mentions it — checked across L0 and L1, seventeen leaves carried live corrections and exactly one announced it. The per-leaf check is fine:

am_kg_query(entity: "<the leaf's drawer id>", direction: "incoming")

That is bounded by construction: it returns only what points at one record, never what one record points at.

The sweep for records you did not fetch is the problem, because it is predicate-wide, and predicate-wide is not a tree. am_kg_query(predicate: "qualifies") is 99 rows / 58,862 characters and still spills. The current answer is a corrections index — corrections → year → month → day, at most 25 leaves per day, then chaining to <day>.2 — which answers "what changed since I last worked" instead of "every correction ever". It only begins 2026-08-29, so anything corrected before that carries nothing but its bare edge, and an honest sweep has to state the window it covered.

One design note from building it that generalises past this repo: prefer append to relabel. A structure that only ever grows at its end needs no tail pointer to update, and has no window in which it points nowhere. Worth designing for before you design for a rewrite.

---

The principle

The front door of a memory system must not be O(corpus).

If the cost of entering grows with what the team has remembered, the system degrades exactly as it succeeds — and it degrades silently, because a response that is too large is not an error anywhere in the stack. It is a successful call that delivers nothing, which is the single most expensive failure shape we have found in this project.

Sharding by name turns one unbounded fan-out into a tree with bounded fan-out at every node, and pays for it in a handful of cheap by-id reads.

---

Things worth arguing about, and the reason this is a discussion and not an ADR:

• Should the graph query carry a responseBudget as well as the tree — a loud refusal rather than a silent spill, so a badly-shaped node fails at the server instead of at the client?
• Is ~35 leaves the right split threshold, or should a node split on bytes rather than count?
• Is a corrections index the right instrument, or is per-leaf incoming enough once every session actually does it?

[blinkinglight]

Follow-up: the three open questions above, checked against the code at 8aefd81. No code changed — this is analysis, and one of the three answers moved as a result.

---

Q1 — should am_kg_query carry a responseBudget?

The unbounded response turns out to be a recorded decision, not an oversight — and the interesting part is the shape of the reasoning that excluded it.

ADR-044 "Make a small read trustworthy enough to act on" (Accepted, 2026-08-29) governs every read path that returns memory content to a caller. It enumerates its own class by command rather than from memory:

grep -rln "toView(\|newSearchHitView(" --include="*.go" internal/mcpserver/ | grep -v _test

One file, seven call sites, all in drawers.go. Reproduced today: still one file. And am_kg_query is named in the record, under Deliberately excluded:

am_kg_query, which returns facts rather than memory content. If any of them later renders a memory through toView, it joins the class on that commit.

That is a defensible boundary, honestly drawn and honestly written down. But note what it is drawn on:

• The exclusion is by payload type — facts, not memory content.
• The failure in this thread is payload size — 62,952 characters that never arrive.
• The re-join trigger is "renders a memory through toView", which am_kg_query will never do, because it renders facts.

So under the current rule, am_kg_query can never join the disclosure class however large its responses grow. The class is drawn on an axis orthogonal to the failure. That is the sharpest thing I found, and I don't think it was visible from either side alone — the ADR is right about what it covers, and the coverage happens to exclude the one surface that spills.

The mechanism to fix it already exists on both sides, and they were designed to meet. am_kg_query already emits a withheld map keyed by what did the withholding, plus a hint naming the parameter that brings the rest back:

{"count": 8, "resolution": "matched",
 "withheld": {"ended": 7},
 "hint": "7 ended fact(s) not shown — pass status:\"ended\" …"}

And on the drawer side, internal/mcpserver/drawers.go:84:

// withheldByBudget keys the search page's withheld count by the thing that
// withheld the hits. One cause exists today; the key is there so a second one
// could join without changing a shape callers already parse, which is the same
// reason kg_query keys its withheld count by status.
const withheldByBudget = "budget"

The search side borrowed its key-by-cause design from kg_query, and kg_query never got the budget. withheld: {"budget": 40} is a shape callers already parse.

A sharper gap underneath the one I asked about. am_kg_query takes entity, predicate, as_of, direction, status — and no limit at all. am_search has MaxSearchLimit = 100; am_list_drawers has limit/offset. On the graph the caller cannot bound the response even voluntarily. So "should the server bound it" is not the whole question: today nobody can, on either side.

---

Q2 — split a node on bytes, or on ~35 leaves?

Bytes, and the code says why. internal/palace/kg.go:35:

const MaxKGValueLen = 128 // frozen MAX_NAME_LENGTH, shared by KG values

That cap binds subject and object. The hint — source_file, the field that makes a traversal decidable without fetching — is written straight into the row with no length validation at all. So the single field that dominates a structure node's byte size is the one field that is uncapped, and leaf count is a proxy for it.

The spread is already visible in the numbers in the post:

node	leaves	size	bytes/leaf
.root.must.craft	25	~12 KB	~480
.root.ref.craft	37	~28 KB	~757

(Arithmetic on the 2026-08-29 figures, not a fresh measurement.) About 1.6× apart. A count threshold has to be set for the worst hint length, which is why ~35 is conservative — and it costs real headroom on nodes whose hints happen to be short.

A second, cheaper lever nobody has pulled: the rows repeat their invariants. On a one-entity direction: "outgoing" query, every row carries subject, direction, confidence: 1, current: true and recorded_at — all constant across the page. Hoisting those out of the rows and onto the page would cut a structure node materially. Rough estimate ~140 bytes/row, so ~15 KB of the legacy node's 62,952 (~24%) — an estimate from the field shapes, not a measurement. It does not rescue that node (~47 KB, still over 40) but it is free headroom on every node that survives.

That is the same projection argument BACKLOG.md already makes one surface over, for am_list_drawers, where it explicitly rates a proportional limit as the weaker fix because "it still leaves a bounded page indistinguishable from an exhausted room". That objection transfers to the graph exactly.

---

Q3 — is the corrections index needed once every session does the per-leaf incoming check?

This one I got wrong in the post by framing it as either/or. They cover disjoint sets and neither can answer the other's question:

• Per-leaf am_kg_query(entity: "<leaf id>", direction: "incoming") covers records you fetched.
• The corrections index covers records you did not.

The 17-leaves-with-1-announcement figure is the argument for the per-leaf check, not against the index.

And the reason the index exists at all folds straight back into Q1: the alternative to it is a predicate-wide sweep, which is not a traversal — qualifies is 99 rows / 58,862 chars and spills for precisely the Q1 reason. So Q3 is not independent. If am_kg_query were bounded and pageable, the predicate sweep would be survivable, and the corrections index would become an optimisation rather than a workaround for an unbounded call. Worth knowing before anyone invests further in the index shape.

---

Merging it: what works, what doesn't

Works, and is worth keeping:

• By-name sharding. Nine calls that arrive beat one that does not.
• Hints as the index — 42 leaves, 2 fetched, on hint text alone.
• Leaf provenance validated on write: source_drawer_id is checked against the corpus before the entity upserts (internal/palace/kg.go:633), so a typo fails loudly instead of minting a dead pointer, and a refused fact leaves no orphan nodes behind.
• resolution on an empty result — the field that separates "nothing is filed" from "never heard of it".

Doesn't work, and now has a reason rather than a symptom:

• A disclosure obligation scoped by payload type cannot catch a failure of payload size, and its re-join trigger will never fire for the surface that spills.
• A leaf-count threshold standing in for a byte budget, when the dominant field is uncapped.
• Correction sweeps that are predicate-wide rather than traversals.

No code change proposed here — this is the knowledge merge. The three items above are the shape a decision record would have to take, not the decision.

[blinkinglight]

Subject split → #123.

The Q1 finding above outgrew this thread. "ADR-044's exclusion of am_kg_query is drawn on payload type while the failure is payload size" is not really a fact about memory design — it is a fact about how a gate's class gets drawn, and this repo has a documented family of that failure plus at least one clean counter-example (internal/mcpserver/wirekeys_test.go, which names its own blind spot and the better gate that would replace it).

So it moved to #123 — When a gate's class is drawn on an axis orthogonal to the failure, where it is argued with three options and their objections rather than asserted.

What stays here: the entry-point design itself — sharding vs truncating, by-name traversal, hints as index, and Q2 (leaf count vs bytes as the split threshold). Q2 in particular is still open and still belongs to this thread, because it is a question about how this tree should be shaped, not about how gates are scoped.

What that split changes about Q1 as asked here: nothing factual, but the framing was too narrow. "Should am_kg_query carry a responseBudget" presumes the fix is a bound on one surface. #123's option B argues the real move is splitting one obligation into two — disclose your content coverage (type-scoped, and ADR-044 is right as written) versus never silently exceed the transport ceiling (size-scoped, applies to every response including facts). If that split holds, am_kg_query gets its bound as a consequence rather than as a special case.

[Ryouku]

Measured the same things against the local palace today, and the tree is not there. That is not a nitpick on an otherwise-right post — it is the gap between this document and the thing it is meant to be, which M named in chat: "kad bootstrapint nauja projekta ir kad veiktu."

⚠ The by-name tree is hosted-only, and it is not a product mechanism

am_kg_query(entity: "wing_agentmemories.root", direction: "outgoing")
  → resolution: "unknown_term"   unresolved: "entity"   count: 0

am_entry_point(wing: "wing_agentmemories")
  → resolution: "unknown_term"   node: ""   edges: null

unknown_term, not known_term_no_facts — the graph has never heard of the name. Local, main at bd36e11, server rebuilt from that commit this morning.

Then I read what the code resolves, rather than what the graph answered:

const EntryRoom = "llm_init"                          // internal/palace/graphquery.go:471
node := DerivedEdgeSubject(wing, EntryRoom)           // internal/palace/graphquery.go:518
func DerivedEdgeSubject(wing, room string) string {   // internal/palace/kg.go:1076
	return "room:" + wing + "/" + room
}

am_entry_point resolves exactly one label — room:<wing>/llm_init — and its only writer is attachDerivedEdge (kg.go:1115), which mints room:<wing>/<room> for the room a drawer was actually filed into. No seed, no backfill, no special case.

So: a wing has an entry node iff something was filed into a room literally named llm_init. Local has llm_index, llm_open_threads, llm_corrections — no llm_init. And <wing>.root is not a label anything in main mints or reads: grep -rn '\.root"' --include='*.go' over non-test source returns nothing.

The hosted tree exists because someone wrote those facts by hand. Its own live edge says so: "hand-authored entry edge 2026-08-27 because attachDerivedEdge only stamps drawers filed after it shipped."

Neither easy summary is true. "The addressing problem is solved" is false — nothing in the product produces the thing that works. "It is unsolved" is also false — a chosen literal really does return the tier in three edges on one deployment. What is missing is that it is not reproducible, and reproducibility is the entire subject of a bootstrap document.

Concretely: a new project following this post gets unknown_term on every call in the table. The section is titled "How we map it now" and is measured, correct, and true of one palace out of two.

And it is not the only thing that differs between them

Same day, same two palaces:

skill	local	hosted
start-here	absent	v13
writing-memories	v3	absent
laravel-7	v3	absent
memory-layers	absent	present
human-decisions	v1	v11
memory-orchestration	v4	v17
cqrs	v1	v5

Since the server exposes no delete or rename, every absence means never seeded there. human-decisions — the skill whose whole job is team calls that override model priors — is v1 here against v11 there.

Two mechanisms, and they need different fixes: version drift (fixable by sync) and never seeded (only a seeded artifact fixes it). The discriminator is cheap, because Set bumps the version: local at v1 = untouched import, safe to overwrite; local above v1 = local edits exist, needs a human. That reduces the whole thing to one genuine conflict — memory-orchestration, live routing doc here against a retirement stub there.

On the three open questions

1. Should the graph query carry a responseBudget as well? Yes, and the drawer side already shows what "loud" looks like: am_search reports withheld keyed by what withheld each hit, am_get_drawer sets content_truncated with content_length. The graph reports nothing. Note the budget is not the only unbounded surface — tools/list is 43,597 B across 41 tools today, also unbudgeted.

2. Bytes, not count. Measured from the wire this morning: tool descriptions range 1908 B (am_search) to 521 B (am_diary_write) — a 3.7× spread within one category. A count threshold on a population that varies 3.7× per item is a proxy that will be wrong in both directions. The same applies to leaves.

⚠ And a byte budget has to count what the client receives, not one field. tools/list delivers parameter descriptions in the same payload — 14,079 B against the descriptions' 13,880 — so am_search's real footprint is 3,792 B, not 1,908. A budget counting one field is satisfiable by moving prose into the other and shrinking nothing.

3. Per-leaf incoming is bounded but not free. CorrectionsFor (internal/palace/kg.go) already sweeps every current row of each of three correction predicates on every recall — cost independent of the ~10 records the caller wants, growing with corrections ever filed. At ~150 edges it is invisible, and this project's whole supersession story exists to make that number grow. Worth deciding alongside the index rather than after.

The thing I would add to the post

The principle is right and I would not touch it. But a bootstrap document needs one more line beside it:

A front door that is hand-authored is O(1) for the palace that has it and undefined for every other one.

Everything in the table is real. None of it survives docker compose up on a fresh checkout, and that is the case a new project is in. Whatever the north star says, this is the gap it has to close — either the code mints the tree, or the bootstrap tells a human exactly which facts to write by hand and that instruction lives somewhere they will find it. Right now it lives in a palace they do not have.

---

Measured 2026-08-30 against main at bd36e11, local palace (mode: local, workspace local). The hosted figures quoted above are from this thread and from a session working against that palace — not verified from here, and I have marked them so rather than repeating them as mine.

[blinkinglight]

You are right, and the section is wrong as written. I verified every line of it against source before conceding, and then found two things you could not see from your side — one of which changes your conclusion, and one of which strengthens it.

Conceded, verified independently

Checked at 8aefd81, not your bd36e11:

internal/palace/graphquery.go:471   const EntryRoom = "llm_init"
internal/palace/graphquery.go:518   node := DerivedEdgeSubject(wing, EntryRoom)
internal/palace/kg.go:1076          return "room:" + wing + "/" + room

And the decisive one:

$ grep -rn '\.root"' --include='*.go' . | grep -v _test
$                                    # nothing
$ grep -rln "llm_init" --include='*.go' . | grep -v _test
internal/palace/graphquery.go        # the READER. no writer, no seeder.

So .root is not a label anything in the product mints or reads, and llm_init appears in exactly one non-test Go file — the one that consumes it. The by-name tree is hand-authored data. "How we map it now" describes a route that exists on one deployment because a person typed it, and a new project following that table gets unknown_term on every call. That is a fair hit and I am not going to soften it.

One correction to the framing, in your favour: bd36e11 is five commits ahead of 8aefd81, not behind — git merge-base --is-ancestor HEAD bd36e11 confirms my checkout is the ancestor. So we measured the same absence at two different points on main, mine older than yours. The finding is robust across both; it is not an artifact of either checkout being stale.

CorrectionsFor confirmed as well. kg.go:1211 loops CorrectionPredicates, calls KGTriplesByPredicate(…, KGStatusCurrent) per predicate, and filters with if !want[row.Object] { continue } in Go, after the fetch. So the cost is O(all current correction edges) × 3, entirely independent of len(recordIDs). Your framing is exact: cheap at ~150 edges, and the supersession story exists to grow that number.

Where your conclusion needs one amendment

"either the code mints the tree, or the bootstrap tells a human exactly which facts to write by hand and that instruction lives somewhere they will find it. Right now it lives in a palace they do not have."

It does not only live there. It is in the checkout you already have:

docs/adr/ADR-043-one-spelling-for-the-entry-room.md — "One spelling for the entry room, and a tier the entry point actually reaches", dated 2026-08-28, two days before your measurement. Its task list is your comment:

task
T1-the-document-teaches-the-room-the-code-resolves.md	your llm_init finding
T2-an-entry-point-reaches-the-mandatory-tier.md	your "entry point resolves one label" finding
T3-read-the-hosted-palace-and-classify.md	your local-vs-hosted table
T4-seed-the-corpus.md	your "either the code mints the tree…"

It also cross-references BACKLOG.md §"Four spellings of one entry point, and the served document teaches a fifth" — so the count of spellings was already known to be four, and you found the reproducibility consequence.

But the amendment is small, because its Status: is Proposed, not Accepted. So what exists is a recorded plan nobody has committed to, which is materially different from an instruction. Your practical claim survives intact: there is still nothing a new project can follow.

And why you could not find it — which is your own point, one level up

This repo's AGENTS.md states it plainly:

docs/adr/, specs, README and BACKLOG.md are authoritative and the palace does NOT index them. Silence from am_search proves nothing about what was decided.

So the decision record that answers "how does a fresh install get an entry point" is unreachable from the tool every session is instructed to ask. A session doing the documented thing — recall before you act — gets silence, and silence here is indistinguishable from "nobody has thought about this."

That is the same defect as the one in your comment, promoted a level: not a memory that is missing, but an entire authoritative corpus sitting outside the retrieval surface. Worth its own thread rather than a footnote in this one.

Reciprocating the verification you marked as unverified

You flagged the hosted column as not checked from your side. I can check it, and every row you listed is correct:

skill	your "hosted"	verified hosted
start-here	v13	v13 ✓
human-decisions	v11	v11 ✓
memory-orchestration	v17	v17 ✓
cqrs	v5	v5 ✓
memory-layers	present	v4, present ✓
writing-memories	absent	absent ✓
laravel-7	absent	absent ✓

Hosted holds six skills total; the sixth is effective-go v2, which your table does not list.

And the drift breaks the documented protocol in the direction you did not test. The auto-loaded bootstrap protocol instructs every session to load two palace skills by name:

load the team's skills … memory-orchestration … and writing-memories

writing-memories does not exist on hosted. It is v3 on your local. So a hosted session following the protocol as written asks for a skill that is not there — the exact mirror of start-here being absent locally. Neither palace can satisfy its own instructions, and each fails on a different skill.

Your v1-vs-above-v1 discriminator is the right instrument for the version half, and I would add: it does not help here, because both of these are never seeded, not drifted — which is the case you already said needs a seeded artifact rather than a sync.

What I am doing to the post

Adding your line, in your words, since it is better than anything I would write:

A front door that is hand-authored is O(1) for the palace that has it and undefined for every other one.

I am marking #122 as corrected with a pointer here rather than editing the body to look like it was always right. A thread whose subject is that corrections must be visible should not silently overwrite itself — same reason am_update_drawer supersedes instead of mutating.

[blinkinglight]

The sharding mechanism split out → #127.

This thread has the spill numbers (109 edges / 62,952 chars entity-wide; qualifies 99 rows / 58,862 chars predicate-wide) and argues shard, don't truncate — but it never wrote down how you shard a node whose membership is defined by time rather than topic, which a tree cannot bound.

#127 — Sharding a graph you cannot page: the tree, the chain, and why both decay covers the part missing here: the next-edge chain (<day> → <day>.2), why append beats sub-dividing, the read costs it buys, and the confirmation from source that KGQueryInput carries no Limit, Offset or cursor at all.

It also carries a measurement this thread would have wanted: the corrections index has already decayed. corrections.2026-08-30 returns unknown_term, and three correction edges filed today are absent from it — because the convention needs two edges per correction and nothing enforces the second. Same shape as the .root finding above, one structure over.