Lines of inquiry — A named line of the record’s own argument, so that a line can be set aside as a whole and what depends on it can be found. Retracting a line is a status change on its members, never a deletion (ADR-032).
Nucleating an argument — how an argument developed across stateless sessions settles into stable, addressable structure, and what a project memory contributes — the record itself as the case.
12 of 191 CASE documents. Back to the full index.
| # | Title | Summary | Status |
|---|---|---|---|
| CASE-082 | The sufficient posterior without its history: a Bayesian agent that keeps only its current posterior updates as well as one that keeps everything, and cannot say how it got there | A6’s fourth case, which A6 called “probably the most important counterexample in the set”. It grounds the redundancy half of CLAIM-300 and one of CLAIM-299’s separations. A6’s reserve case, revising the model class, is where it stops holding, and CASE-087 is that case. | Active |
| CASE-084 | The perfectly accountable false theory: a community whose record traces every commitment and whose vocabulary leaves out the right explanation | A6’s third case. Accountability without correctness, one of CLAIM-299’s three separations, and A6’s “direct companion to CLAIM-181 and CLAIM-190”. | Active |
| CASE-086 | The retracted finding and its descendants: an experiment fails to replicate years after three conclusions were built on it | A7’s sixth case, filed at the owner’s U7 as an illustration and not a test (“one or two of those might be handy to keep on hand too”). Tracing descendants of a defeated premise, which CLAIM-295 says a record of dependencies supports. | Active |
| 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-089 | The compensating evidence problem: two records with the same support graph in which discounting one support leaves odds of 20:1 or of 1.1:1 | A6’s second case. It grounds CLAIM-293: the same edges E₁ → H ← E₂, different Bayes factors for E₂, different revisions when E₁ fails. | Active |
| CASE-090 | The rehabilitated hypothesis: an objection that displaced a hypothesis turns out to rest on a faulty measurement, and the hypothesis can be reopened because its defeat was recorded | A7’s seventh case, the companion to CASE-086 and filed with it. Reopening an alternative when its defeater is defeated. A12’s “defeat of a defeater” is the same case and is held here, as A12 itself proposed. | 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-093 | Same marginal, different updates: two joint distributions over a hypothesis and a condition that agree on the hypothesis and disagree on how to revise it | A6’s first case, made exact at A8. It grounds CLAIM-294. | 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 |