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:

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.