Topics — What a work is about. Nucleation holds whatever reading the owner files here, whether or not an Anthology of the SOTA topic could also hold it; instruction for ML practice belongs to the anthology (ADR-048). The words are seeded from the clusters the reading-time triage of 2026-09-25 found, and grow by decision.
Design rationale — recording the reasoning behind a design or decision as it is made — issues, positions and arguments, options and criteria (IBIS, gIBIS, QOC and their successors) — and why such capture systems are or are not used: who bears the cost of capture and who gets the benefit, premature formalization, cognitive overhead, and the groupware adoption problems behind them (ADR-030).
6 of 191 CASE documents. Back to the full index.
| # | Title | Summary | Status |
|---|---|---|---|
| CASE-088 | The repeated objection and the argument nobody reuses: filing pays for itself after a few recurrences in one case, and never in the other | A11’s CASE B and CASE A, the arithmetic of CLAIM-303. | Active |
| CASE-091 | A memory ablation for revision: synthetic inquiries with known ground truth, run under six kinds of persistent memory, with information and token budget controlled separately | A6’s fifth case, refined from A3, A4 §4 and A5. The design QUESTION-108 asks for. Not run. | Active |
| CASE-131 | The graph that asserted an inference nobody made: filing one claim as supporting another made the record’s link fixer write that the other rested on it, and the record answered by adding a relation | The record’s own history, as A18 of the exchange of 2026-10-22 read it at the owner’s prompting (U18): “the pre-existing representation didn’t merely omit information; it positively misrepresented an inference”. It is a move the grammar could not hold, caught and answered by amending the grammar. Not shown: that such moves are always caught. | Active |
| CASE-178 v3 | How the record’s grammar grows: after its scaffold, this record filed documents on all 32 days, added vocabulary terms on 18, fields or relations to schemes on 8, whole vocabularies on 3, schemes on 1 and a remote project on 1, so the owner’s ordering of levels holds by frequency; but each refinement came in the same pull request as the documents that needed it and, nine times in ten, an ADR, so the levels are rarer events of one loop of work, not slower processes of their own, and the grammar’s rates fell while filing rose | Run on 2026-10-27 at the owner’s direction, after CASE-180: “some of the most important rates are when and how schema refinement happens”, with the ordering documents, vocabularies, scheme fields, schemes, projects. scratch/formal/schema_rates.py reads every change to luria.yaml in this record, in luria’s own and in strata-g’s. The ordering holds by days with an event. How the refinement happens: on demand, by decision, and nested, the rarer level arriving with the commoner ones in one pull request. | Active |
| CASE-180 v2 | The record’s own rates: over its first fifty days, measured from git, an entry’s prose is revised about once in 22 days once drafting is over, its status once in 128, an authored relation gained or lost once in 132 and an authored relation retracted once in about 600, while no relation type has been redeclared; the layers’ event rates are ordered as the exchange guessed, but only after the first day, when all of them change together, and the grammar is slow to revise without being slow to grow | Run on 2026-10-27 at the owner’s request (“run your measurements against the record”), for the rate reading A12 and A13 gave luria’s layers and that CLAIM-476 left untested. Every non-merge commit to this record, read by scratch/formal/record_rates.py at commit a357048. The ordering (prose, then standing, then relations, then the grammar’s types) holds in aggregate rates, by one to two orders of magnitude. It does not hold in the first day after filing, or for every scheme, and the machine’s validation runs at the rate of the edits it follows, not on a scale of its own. | Active |
| CASE-183 | The anchoring measures: inbound references per code and turns per filed entry, counted in the record’s own grammar | The two measures the nucleating-argument line proposes for its claims, filed as a design so that an argument can start from them. Inbound references per code would tell an anchor from a structure that only persists (QUESTION-038). Turns per filed entry would be set against the drift the workbench records (CLAIM-186). Both are counted in codes, relations and statuses. Neither has been computed. | Active |