Tracker: TT-035 carries the three-run contract evidence, not the discarded pass
The row quoted a single run of the pre-fix instrument (13/24 carryable, 9/12
foundation). It now carries the final three-runs-per-arm numbers: memory carryable
67/71/46% (mean 61.3) and foundation 33/33/83% (mean 49.7) against the summary's
75/54/79% (69.3) and 67/58/67% (64.2), stale 15 vs 16, with the note that the
defect is structural in the logs while its score impact is noisy.
Tracker: TT-035 — memory keeps an amended fact beside the original under a new key
The contract master-prompt run distilled mga/* in session 1 and the amendment
under msa/calder/* in session 2, with later sessions distilling 1/0/0/0 facts, so
both values stayed live and the model answered either. Evidence and the two
candidate fixes are in the row.
Tracker round 35: TT-020's upstream ask is answered
The gate is the webserver schema, not the CLI guard; an interface literal would
also need its address in resolveLanTrust's trustedHosts. Still upstream's call,
so the row stays Blocked, with the SSH/tunnel workaround named.
Tracker round 34: TT-018's catalogue half is done
PR #5396 merged 2026-09-19 by fkysly (merge commit 4d136c1). The row now says
what is left: the npm publish (operator), and an inert fork that needs the
delete_repo scope to remove.
Tracker: drop the Task numbers section
The numbering rule and the type/status/size legends were a second copy of what
`docs/task-table-standard.md` already defines, and the intro links it. The page
is now the table and nothing else, which is what a queue should be.
Tracker: adopt the one-table standard (Owner column, Blocked means external)
The table now matches `docs/task-table-standard.md`: same columns, plus Owner,
and the same status vocabulary. The only status that moved is TT-018, from Open
to Blocked -- under the standard an Open task is startable in this checkout, and
neither the catalogue merge (a maintainer) nor the npm publish (the operator) is.
Owner names who must act: `maintainer / operator` for TT-018, `upstream` for
TT-020. Nothing is actionable here right now, so the table is honestly two
blocked rows rather than a section marked Open.
Tracker: one task table with a status column
Open, Blocked and Parked were separate tables with three different column sets:
Blocked had no Size and no Next step, and a task changing state had to move
between sections. They are one `## Tasks` table now, with a Status column
carrying Open/Blocked/Parked, so state is a field on the task and every row
reads the same. A blocked row states its blocker in the next-step cell.
No status changed in the merge: TT-018 stays Open (a maintainer or the operator
can act) and TT-020 stays Blocked (upstream schema change), and both rows carry
their current evidence -- PR #5396 open and CLEAN, discussion #7111 unanswered.
Tracker round 33: TT-018's fork goes when the PR resolves
The `Pummelchen/awesome-dsh-plugin` fork is only PR #5396's head, so TT-018 now
carries its cleanup: delete the fork once the PR is merged or closed. Recorded
rather than acted on -- the PR is open, CLEAN and waiting on a maintainer, so
removing the fork now would close the very PR the task depends on.
Tracker round 31: TT-025 closed by measurement
Both quality instruments now agree. The twenty-prompt checkable suite is 18/20
against 18/20 for the promotion and its --no-promote control, and the paired
held-out perplexity A/B puts the 16 MB promotion 0.0097 +/- 0.0067 nats ahead
(t -1.46) and the whole-slot 8-bit build 0.0012 nats ahead (t -0.09) over 1,023
positions -- in precision's favour and below the instrument's ~0.013-nat
floor. The runtime half ships and is tested; the converter policy and the GDN
a/b kernel's int8 branch are not built, and the Notes now say so where someone
looking for a closed quantisation idea will find it.
The Open table is TT-018 alone, TT-020 is the only blocked item, and Parked is
empty.
Tracker round 30: TT-033's caller lands, TT-025's sharper check finds the same floor
TT-033: `MemoryRetrievalHinter` is T7's caller -- a background sweep that runs
only in the idle window and leaves a ranking hint for a later search, never a
request. The Notes record the design, its three bounds (64 facts a question,
16 questions tracked, a value fingerprint against staleness) and the seven
behaviours the unit suite pins. The row is closed and deleted from Parked,
which is now empty.
TT-025: `TinyTitanBench cpu35ppl` scores a fixed held-out text through the CPU
forward pass, and the paired comparison over 1,023 positions gives the 16 MB
k_proj/v_proj promotion 0.0097 +/- 0.0067 nats ahead of its --no-promote
control (t -1.46) and the whole-slot 8-bit build 0.0012 nats ahead (t -0.09).
Both point estimates favour precision and neither clears the instrument's
~0.013-nat floor, so the task stays open with that recorded; the Notes also say
what a paired t over correlated positions does not prove.
Also in this round: TT-009's side-engine model policy is written down (2B
unused, 4B 4-bit the default and verification instrument, 9B optional on
quality benchmark results), and TT-021, TT-022 and TT-023 are closed -- no
other machines for chip validation or ANE across generations, and no disk for
the ~360 GB bf16 reference long-context parity needs -- with the caveats they
existed for left standing in Blocked work.
Tracker round 29: TT-025's quality case is measured, and it is not there
The measured question was whether a per-tensor promotion inside a 4-bit install
buys anything end to end. On a twenty-prompt checkable suite: the 4B's own 16 MB
`k_proj`/`v_proj` promotion is 18/20 against its uniform control's 18/20 with
identical outputs; 4-bit vs 8-bit is 18/20 vs 17/20 on the 4B and 18/20 vs 18/20
on the 9B. The failures are reasoning, not precision.
The mechanism still ships (the runtime half), and the Engineering Notes entry
records the instrument, the controls and what a wash at this resolution does not
prove. What is left of the task has no measured justification, and the 125B that
would test the slot-reading tensors needs a 360 GB bf16 source this machine
cannot hold.
Tracker round 28: TT-033's lexical half is fixed; the remainder is semantic
The token ranking's failure was measurable and, it turns out, cheap to half-fix.
It was never failing on questions that use the store's words (10 of 10 at rank
1) — it failed on paraphrases (1 of 4), and by handing rank 1 to a common word:
"does it ever rain in this town?" matched `setting/town`'s key for 3 and the
rain rule's value for 1 while "town" appears in two facts and "rain" in one.
Weighting each term by its inverse document frequency, and a value match at two
rather than one, takes paraphrase recall@1 to 3 of 4 with no regression on the
mechanical set. The last miss shares no term in any form, which is the boundary
of what lexical scoring can do: from here it is an embedding scorer or T7.
The row now says that, rather than parking on price alone.
Tracker round 27: TT-025's runtime half ships — the three slot-reading families take a per-tensor width
The row said the runtime sizes every tensor in a slot and rejects an override.
That was true for exactly three families, and worse than the row claimed: the
loader never validated those tensors' widths at all, so an override on them
would have been *unguarded* as well as unhonoured — packed at one width, read at
another, no error.
They now resolve through the manifest's overrides (`hyperConnectionWeightBits`,
`pleKeyWeightBits`, `qsaIndexerWeightBits`), each with a role so a partial
promotion is refused, their pipelines are built, and the quant-support guard
checks the resolved width rather than the slot. That is what makes the ~10 MB
`precision_probe.py` flags affordable, against +2.10 GB for the whole attention
slot.
Left on the row: the converter policy (per tensor — the 8-bit indexer alone was
measured and rejected), the GDN a/b pair (int4-or-bf16, refused by name when
quantized), and an install carrying one of these overrides to verify on the 4B
and 9B. Both GDN points are the same gap seen from the two ends.
Tracker round 26: TT-025 revived by the operator; TT-018's merge is a permissions problem
TT-025 moves from Parked to Open on the operator's instruction. Its premise was
re-checked first and holds: the runtime sizes every tensor in a slot from
`manifest.quant.<slot>.weightBits` and picks one GEMV pipeline per slot, so a
per-tensor override is packed by the repacker and then rejected by the runtime.
The first step is choosing the tensor set that justifies the mechanism, because
the one motivation that was measured — the QSA indexer at 4-bit — was rejected.
TT-018 records what the merge attempt established rather than what was assumed:
the PR is CLEAN and mergeable, but `Pummelchen` has no write access to
`awesome-dsh-plugin`, so `MergePullRequest` is refused with a permissions error.
A ping is on the PR asking a maintainer to take it.
Tracker round 25: TT-024 closed — CPU co-execution is rejected by measurement
The parked row still argued from the idle GPU ("occupancy 39.5-48.5%, 53% of it
inter-command-buffer gaps"), but the plan document it cites reaches the opposite
conclusion two thirds of the way down: running the real CPU expert kernel as a
load generator during decode raises GPU-busy 44.9% (27.3 -> 39.6 ms) and costs
22.6% of throughput. At best the CPU absorbs 32% of the work and the GPU does
the rest at 0.69x, so no split ratio wins. The plan's own words are "dead, not
deferred". A streaming-read probe had supported the idea and was wrong about the
workload. The rejection and its numbers are now an Engineering Notes entry under
"Closed by measurement — do not re-propose", and the kernel stays in the tree
with the note that nothing may call it from the decode path.
TT-025 was checked the same way and is accurate, so it keeps its place — with the
evidence added: `prepare_qwen38.py`'s `quant_bits` documents the runtime
rejecting a per-tensor override ("in_proj_a.weight size 122880 does not match
expected 61440"), which is exactly the slot model the row describes.
Parked now holds TT-025 and TT-033; three of the five rows that were there at
the start of this audit (TT-024, TT-026, TT-027) are closed.
Tracker round 24: TT-027 closed — both models already stream shard by shard
The row said KAT-Coder and AgentWorld are built by downloading a ~70 GB
checkpoint and then converting it. They are not: both go through
`tools/prepare_agentworld.py --model {katcoder,agentworld}`, which pulls a
bounded number of shards through a three-way fetcher pool (`prefetch_shards`,
`FETCHERS = 3`), verifies each chunk against the shard's own header length,
converts shard by shard on the calling thread, and unlinks each one. Peak source
disk is ~11 GB, which is why `docs/adding-a-model.md`'s build table peaks at
~50 GB for a 4-bit build rather than ~90 GB.
The concurrent fetch landed in ff5047b (2026-09-13) and the verified chunking in
8b60741; the runbook measures the download as the remaining ceiling and records
what moved it (--http1.1: 214 KB/s -> 908 KB/s; a second connection +490 KB/s;
chunking) and what did not (relaying through a fast remote host).
Tracker round 23: TT-034 closed — both ends of the sharing path are pinned
The converter's PLE-constants gate has five cases
(`benchmark/test_prepare_qwen38.py`), and the Swift link decision now has four:
`linkPassthroughFile(named:from:into:)` takes two directories and no snapshot,
so one inode and two links, an absent optional table, a zero-length table
refused, and an existing destination replaced can all be asserted directly.
A `qwen38flash` fixture would still be needed to drive the whole repack, and it
is deliberately not required: the two decisions that can be wrong are the gate
and the link, and both are now tested without one.
Tracker: TT-034's converter half is tested; the Swift link path is what remains
The dangerous half had the worse coverage: the PLE-constants gate that refuses a
table addressed by different multipliers now lives in `reusable_table_path` and
is pinned one constant at a time by `benchmark/test_prepare_qwen38.py` (five
cases, plus the current contract that a directory with no sidecar is reused
unchecked, now deliberate rather than accidental). The Swift hardlink and size
check still has no test and needs a `qwen38flash` fixture.
Tracker round 22: TT-026 closed — the n-gram table sharing was implemented on 2026-09-01
The parked row was stale. Both halves are in the tree and were checked rather
than assumed: `TinyTitanRepack --share-ngram-table` keeps `ngram_table.bin` out
of the copy plan and hardlinks it after the partial directory exists, with a
size check and the same digest recorded for the receipt; and
`prepare_qwen38.py --reuse-ngram-table` refuses a table whose PLE constants
differ — the gate that matters, because the table is addressed by those
multipliers and nothing else would notice a mismatch — then skips the 128
shards that carry nothing else. `docs/ngram-table-sharing-plan.md` has said
"Implemented 2026-09-01" since the day it landed, and the live run it records
recovered 95 GiB and verified the two copies byte-identical first.
What the work left behind is a test, not a feature: neither the link path nor
the constants gate is exercised by any test, and the gate fails silently if it
is wrong. That is TT-034, opened as a chore.
Tracker round 21: TT-033 parked on price, not accuracy
The recall experiment shows the ranking is worth having — recall@1 4 of 4 against
the token match's 1 of 4, recall@3 4 of 4 against 3 of 4, the same at the 4B and
the 9B — so the task is not accuracy-blocked. It is price-blocked: every
question-shaped caller is a request the person is waiting on and a judgement is
15.2 s, so the port method was removed until a caller off that path exists. That
is a reason to revive, which is what Parked is for.
TT-018 also records that both CI checks are green and the PR is mergeable, so
what is left there is a maintainer's merge.
Tracker round 20: TT-032 closed — supersession finds its rule and holds the write
The rule is found by key rather than by a model call: `rules/<last segment of
the changed key>`, so `rules/eyes` governs `characters/marcus/eyes`, and only an
exact match counts because a wrong rule would block a real update. With a rule
found, a changed value under the same key is put to T4: `.conflict` stops the
change and `.update` changes nothing, and only a model-derived fact is asked
about, so the person can always overrule a rule.
Verified end to end on the 4B and the 9B. TT-033 (an affordable caller for
retrieval) is what is left of the memory work, with TT-018 still with the
catalogue's maintainers.
Tracker round 19: TT-009 closed — the resident side-engine ships and memory uses it
TT-009's deliverable is met. The engine is model-agnostic and verified on the 4B
and the 9B; the server builds it with `TINYTITAN_SIDE_ENGINE` (default 4B) and
the width from the coordinator's `generating` signal; and consolidation now asks
it three things inside a budget of six questions — durability first, then
near-duplicate suppression and advisory contradiction, over the session scope
and the shared workspace. Every remaining task is measured and explicitly
scoped, which is what the task asked for.
Two pieces of genuinely new work are recorded rather than dropped: TT-032, the
rule lookup supersession needs before it can be wired, and TT-033, an
affordable caller for retrieval. The reply check (T6) belongs to the shadow,
Part 2 of `docs/plan-memory-guard-and-shadow.md`, which is a separate decision.
Tracker: TT-009's durability and supersession prompts now decide
The third draft takes durability from 45% to 95% on the 4B and supersession
from 0 of 3 CONFLICT to 3 of 3 on each half at both sizes, once the stored rule
is supplied. Durability is a 4B task and the 9B is worse at it, 65%, which is
why the default install is the one that decides. Neither is wired yet: there is
no durability method on the port, and nothing looks up the rule supersession
needs. That, plus a caller for T7 that can afford a 15-second question, is what
is left.
Tracker: TT-009's consolidation checks are budgeted, cover the shared workspace, and ask in the right order
A judgement is a full CPU generation — 15.2 s on the 4B, 29.8 s on the 9B — so
one consolidation is now allowed four questions in total and two to any one
fact. Duplication and advisory contradiction run inside that budget over the
session scope and the shared workspace. Contradiction is logged, not acted on:
disagreement is not supersession and T4 is one-sided at every measured size.
The release-only end-to-end test found that the wiring asked T5 with the two
facts in the reverse order from the measured prompt, which the 4B answers NO to
— suppression would have stopped nothing. Fixed, asserted in the unit tests, and
re-verified on the 4B (30.5 s) and the 9B (58.2 s). T7 stays on the port:
`memory_search` is a tool call the client waits on, the wrong place for a
15-second question. Next is the durability/supersession prompt no size decides.
Tracker: TT-009's port, host and first wired judgement ship
The side-engine has a port in memory's vocabulary (`MemorySideEngine`, where
nil is "no decision"), a home in the server (`TINYTITAN_SIDE_ENGINE`, default
the 4B, width from the coordinator's `generating` signal), and one judgement
with a real effect: T5 near-duplicate suppression in consolidation. The main
benchmark's T5 cases pair the same key, which the deterministic check skips
before the engine is asked, so the wired case was measured separately — 4B 7/8,
9B 8/8, with the 4B's one miss keeping a redundant key rather than dropping a
fact. Next is T7 retrieval, advisory T3, the shared-workspace path, and the
durability/supersession prompt no size decides.
Tracker round 18: TT-019 closed (the upstream asks are posted), TT-018 resubmitted, TT-009 re-scoped by measurement
TT-019 said to post the two asks and add TT-020's. All three are now Discussions
in upstream's *Ideas* category — #7109 (honor `purpose` when an auxiliary call
names no reasoning level), #7110 (map pi-ai's usage into `reasoningTokens`), and
#7111 (TT-020's: bind a specific LAN interface). The row is deleted.
TT-018 is resubmitted as PR #5396; #5094 had been closed by this account with no
comment and its fork was deleted, so there was nothing to reopen. The row keeps
its place until the maintainers merge it.
TT-009's resident service and scheduler ship, and the engine is model-agnostic.
Re-verified on the 4B and then the 9B, the 2B being too limited to be the
instrument: contradiction, duplication and retrieval are good from the 4B, the
reply check needs the 9B, and durability and supersession are one-sided at every
size, so they are prompt problems and not ready. The next step is the wiring,
with the 4B as the floor.
Tracker: TT-009's resident service ships, and the tasks it may be trusted with are measured
`SideEngine` and its scheduler are in on `main` (`036f98c`), and the prompt
measurement is recorded (`03d79f7`, `docs/side-engine-tasks.md`). T3
(contradiction) and T7 (retrieval) pass both halves unchanged; T5
(duplication) goes from 0 of 4 identical pairs to 100% only when the facts
arrive as sentences, and that change is not yet separated from the prompt
rewrite. T2, T4 and T6 are one-sided in both drafts and do not decide. The
row's next step is now the wiring plus a decision on the three that fail.
Tracker round 18: TT-003 closed — the unrequested thought is prompt-dependent, not width-dependent
The restored 8-bit install (golden-verified) let the single-prompt observation be
re-run across prompts, and it does not survive. At `--reasoning off`, greedy, 128-token
cap, both widths:
Capital of Paris 8-bit 477 reasoning (empty answer) 4-bit 0 (answered)
What is the capital of Paris? 8-bit 470 4-bit 471
Who is the president of Paris? 8-bit 0 4-bit 0
How many capitals does Paris have? 8-bit 487 4-bit 504
What is the capital of France? 8-bit 0 4-bit 0
Name the capital city of Japan. 8-bit 0 4-bit 0
Both widths reopen a closed `<think>` on different false-premise prompts — the 4-bit
thinks on two of the four, and not on the one the original row used — so this is a
property of the prompt and the family's weak closed-block cue, not of the 8-bit width.
`--reasoning on` changes the thought's content rather than deciding whether there is
one, so the level is a request, not a gate.
Catalogue decision: advertise nothing differently. `off` describes what the server
asks for, and it does ask; special-casing one width would encode a single-prompt
artefact, and dropping `off` from the family would be wrong because it does not gate
the behaviour in either width. C90's split and its `thinking off, but the model wrote
N characters` log line (which fired on all five thinking runs) are the honest surface.
Engineering Notes carries the matrix and the decision; the Capital-of-Paris page's
"its 4-bit sibling never does it" is corrected there too.
Tracker: TT-003 unblocked — the AgentWorld 8-bit install is restored
The conversion the operator asked for finished (36.9 GB snapshot) and the repack
produced models/qwen-agentworld_35B_A3B_8Bit (34 GB, receipt written); a one-token run
loads it with the 8-bit row's profile (`budget=12288MiB prefetch=1 keep_wired=true`).
The stored `qwen-agentworld-35b-a3b-8bit` golden is being checked against it.
TT-003 moves from Blocked back to Open at the head of the queue — reproduce the think
block through the server at `--reasoning off`, compare it with the 4-bit sibling, and
decide what `/v1/models` should advertise for that install. The template, the request
path and C90 are already ruled out and recorded in Engineering Notes.
Tracker round 17: TT-010 closed by measurement — the QSA-on-GPU ceiling is 2.75%
The prefill QSA selection is a host computation behind a barrier, and the decode half
of the same idea already shipped as an opt-in and measured a wash. `TINYTITAN_QSA_SELECT_TRACE=1`
now times the prefill selection per layer per chunk on qwen3.8-flash-next 4-bit:
prompt 2,410 tok prefill 95.64 s selection 185.7 ms -> 0.19%
prompt 11,948 tok prefill 864.90 s selection 23,748.7 ms -> 2.75%
It is superlinear (first chunk 1,775 ms, second 9,222, third 12,752) because rows past
the ~2,051-key exactness window pay a block sort plus an O(visible) compaction. Both
runs shared the machine with a model conversion, so those are upper bounds.
Rejected on the ceiling: a GPU prefill path needs a multi-row mask kernel and GPU
compaction the decode path does not have, could recover at most 2.75% on one family's
longest prompts, and any tie-break difference changes which keys are attended. The
trace switch stays so the number can be re-taken. Recorded under "Closed by
measurement — do not re-propose"; TT-010 removed from Open.