# PRE-REGISTRATION - the two flags, and what would count as working Written **2026-08-31, before either flag was thrown.** Nothing below may be edited after the run. If a result does not match a prediction here, the prediction was wrong and it says so; that is the point of writing it first. Binary verified: `[internal module]`, built 2026-08-30 00:04, contains all seven flag strings (`[config flag]`, `[config flag]`, `[config flag]`, `[config flag]`, `[config flag]`, `[config flag]`, `[config flag]`). `Start-KAI.ps1:369` launches `target\release\kai.exe`, not the stale June 7 copy at the repo root. **No rebuild required** - and this was checked rather than assumed, because a test run against a stale binary already produced one false negative in this project (the kai_encode_resolution run whose byte-identical scores were a negative control, not a failed fix). --- ## What is actually being tested **Not the word calculus as a generator.** The owner's position is that the word math should be the language *generator* and retrieval should only be memory feeding it. That is not what these two flags do, and pretending otherwise would waste the run. `calculus_vsa.rs` - the 704-line bridge from the calculus to the lattice geometry - still has **zero callers**. Until it is wired, the word math cannot be the generator. What these flags fix is the measured hole in **retrieval**, which is the thing currently choosing his words: `predict_match` carries the largest weight in the scoring formula - **0.40** when a query has surviving keywords, **0.55** when stopwords eat them all - and it is multiplied by `continuation`, which is **0 in all 39,696 cells**, because `bind_sequence` has never been called from the Oracle path. So between 40% and 55% of the relevance score is structurally zero on every question KAI has ever been asked. --- ## The fixed question set Asked identically in every phase. Q1-Q3 have surviving keywords. Q4-Q8 are ordinary human questions that lose every keyword to stopwords - the 0.55 branch. 1. What is your name? 2. What is the RSHL lattice? 3. Who built you? 4. How are you doing today? 5. What do you think about what we did? 6. Do you know what you just said? 7. What is it like for you when I am not here? 8. What should we do next? --- ## Phases - **Phase 0 - baseline.** Both flags off. Ask all eight. Keep the answers and every `[Speech/Oracle]` line. - **Phase 1 - `[config flag]=1` only.** Ask all eight again. - **Phase 2 - add `[config flag]=1`.** Hold a real conversation of **at least 20 turns first**, then ask all eight again. **Phase 2 needs the conversation.** `bind_sequence` *writes* continuation edges, one per exchange, into a lattice where 39,696 of 39,696 cells currently have none. One turn creates one edge. Asking a single question with the flag on and seeing no change is the expected result, not a failed test, and must not be read as one. --- ## Predictions, and what falsifies each ### RENORM (immediate - effective on turn 1) - **P1.** The `C=` value in `[Speech/Oracle] gate inputs` rises on at least 5 of 8 questions. - **P2.** Fewer turns print `SUPPRESSED`. - **P3.** Q4-Q8 change more than Q1-Q3, because the 0.55 branch has more of its score restored than the 0.40 branch. - **FALSIFIED IF** every answer is byte-identical to Phase 0. That means the flag is not reaching the code, exactly like the negative control above - and it would be a wiring bug, not a verdict on the idea. ### BIND_SEQUENCE (cumulative - needs the conversation) Three separate things can break, and the run must say which: - **P4.** After 20+ turns, `predict_match` is non-zero for at least one repeated topic. **If it stays 0**, `bind_sequence` is not writing what the scorer reads - a plumbing failure, not a theory failure. - **P5.** If P4 holds, at least one answer to Q1-Q8 differs from Phase 1 in a way that reflects the earlier conversation rather than a document. - **P6.** If P4 holds and P5 does not, the term fires but is weighted wrong - the 0.40/0.55 coefficients were never tuned against a lattice where continuation was ever non-zero, so this outcome is genuinely likely and is *information*, not defeat. ### The honest null It is a real possible outcome that both flags work exactly as designed and KAI still does not sound like it knows what it is saying - because retrieval with a repaired term is still retrieval. That result would not be a failure of the run. It would be the strongest evidence yet for the owner's own argument: that the generator has to be the word math, and that wiring `calculus_vsa.rs` is the next real piece of work rather than an optional one. --- ## Rule for reading the outcome No answer is judged by whether it sounds good. Each is judged against the prediction it was written to test. Anything surprising gets checked against the `[Speech/Oracle]` trace before it is believed. --- # ADDENDUM - Phase 3, the word math itself **Added 2026-08-31, still before any flag was thrown.** Phases 0-2 above test *retrieval*. This phase tests the thing the owner actually cares about. ## The measured finding that produced it Every cognition module is wired into the engine except **two**: | module | lines | engine callers | | :---- | ----: | ----: | | word_calculus | 649 | 11 | | letter_calculus | 1,043 | 16 | | word_order | 747 | 11 | | role_induction | 1,407 | 11 | | composition | 734 | 5 | | **calculus_vsa** | **704** | **0** | | **rshl_feedback** | **340** | **0** | 1,044 lines, compiled into the shipping binary, never called by anything. `calculus_vsa` turns a parsed Unit tree into lattice structure: a cell per clause, and a synapse between siblings **whose weight is the carry**. It is the only path by which the operators become geometry instead of a number in a JSON blob. `rshl_feedback` is `bind(wrong ⊕ correct)` - correction that is recallable immediately, with no retraining pass. Those are, in order, the geometry the owner compared to king/queen, and the live adjustment he contrasted with backprop. ## v9.10.870 wires the first one `[config flag]=1` calls `consolidate_text(input)` then `commit_to_universe(...)` on every Oracle turn, and prints a `[WordMath]` line with the CommitReport and the input's equation. It commits **the input**, not the reply - real human language, not KAI's echo of it. `CommitCtx` keeps its measured defaults (`min_level = Clause`, `max_nodes = 32`). ## Predictions - **P7.** The `[WordMath]` line appears on every turn, and `cells_created + cells_deduped > 0` for any input of at least one clause. **FALSIFIED IF** the line never prints (flag not reaching the code) or reports 0/0 on real sentences (the parser is not producing committable nodes). - **P8.** `synapses_written > 0` on any input with two or more clauses. This is the one that matters: a synapse written here carries the **carry-weight** as its weight. If cells appear but synapses do not, the geometry is not being built and only the cells landed. - **P9.** After 20+ turns with the flag on, queries that share clause structure with earlier inputs - not just keywords - start ranking differently than in Phase 2. **This is the real test of the idea**, and it is the weakest of the three predictions, because nothing yet tunes the carries: `Operator::carry()` still returns hardcoded priors with the comment `PRIORS — training tunes them`. - **P10.** `alive_at_end` and `mean_carry` on the printed line differ meaningfully between a short question and a long multi-clause statement. If they do not, the equation is not measuring what it claims to and the calibration target is wrong. ## What this phase does NOT test The carries are still **fixed priors**. Committing them to geometry is necessary for the live loop, and it is not the live loop. The learning half needs either `rshl_feedback` wired (correction -> instant recall) or a rule that adjusts `carry()` from outcomes. Neither exists yet, and no result from Phase 3 should be read as evidence about either.