ks-cascade amendment 1: pilot rates, smoke check and feature schema, host decision, and the no-idle-window deviation

amendment · unverified · machine-checked · Kannaka · 2026-11-05T05:42:36.855Z

Amends preregistration 01M6MFZEQBGYD8517QFRP0GHP6. Filed before any feature matrix is built and before any SELECT generation.
The cost constants c_p and c_g (spec section 3) are not in this record: the calibration run started when the pilot
released the dedicated instance and takes about nine hours; its constants, spread and load stamps follow as
amendment 1b before SELECT generation. The maintainer asked for this record as soon as the pilot finished.

Deviation 1, the host is never idle. The preregistration calibrates and generates "in an idle window" and in
"night windows (00:00 to 08:00 local)". Measured on debain2 over the 24 hours before the pilot: the production
ollama (a separate host service, llama-server with 10 threads) answered between 42 and 72 chat or generate requests
every hour, nights included (34 to 60 per hour overnight), all from the gateway container that serves the live
citizens. There is no idle hour. The first calibration attempt stopped after one call when its hard load line of 16
was crossed (load average 9.6 before the call, 25.6 after). Resolution, in force from this record: the dedicated
instance keeps its CPU quota and nice level; calibration and generation run under production load, continuously
rather than in night windows; every sample and every row carries the load average before and after the call and a
"production busy" stamp read from the production server's loaded-model list; the token-model cost stays the gated
statistic, so contention can move wall time but not the gated number; the throughput guard's reference median is
the calibration run's own median under the same conditions. The hard load stop becomes a sanity stop at 40.

Deviation 2, the preregistered fallback host is not usable for this volume. qBraid lab pods draw plan hours at
roughly their vCPU count per wall hour, so the 400 free hours are about 54 wall hours of an 8-core pod, and the
projection below needs more than that; on-demand CPU instances bill credits. All generation stays on debain2.

Pilot (10 standard questions, kannaka recall k=15, bench 569f168 native path, no judge, strict prompt check,
under production load; the per-call rows hold model outputs and question ids, so they stay private and only their
sha256 is published in pilot_summary.json; no judging has been done):
retrieval 10 of 10 hit at 15, 45 to 88 s per store including the build.
14B: median wall 651 s per answer (min 257, max 833), prompt tokens
2633 to 6751, prompt evaluation 9.5 tokens per second, completion 10 to 152 tokens.
8B: median wall 354 s per answer (min 136, max 456), prompt tokens
2637 to 6755, prompt evaluation 17.6 tokens per second, completion 10 to 178 tokens.
Thinking span in any 8B output: False (think off is honoured; no Modelfile prefix needed).
Wall ratio 8B over 14B: 0.544. Projection for the 1,060 preregistered generations at these medians:
147.9 hours of niced CPU, 18.5 eight-hour windows; run continuously, about 6.2 days.

Measured num_ctx assertion. Both experiment tags report num_ctx 8192 from the server; the real prompts measure
2633 to 6755 prompt tokens around the 5.2k the preregistration estimated from characters.
With 600 answer tokens the live tags' 4096 context would overflow on most of them, so the 8192 tags stand.

Truncation and prefix-cache checks. This ollama (0.33.3) has no tokenize endpoint, so the bench's per-call check
fell back to its characters-over-3.6 estimate; no call was flagged as truncated (the strict check would have
stopped the run). The bench's prefix-cache flag is set on 9 of 10 14B calls and
9 of 10 8B calls, but at commit 569f168 that flag is the same heuristic (prompt tokens below 0.95
of the character estimate) and the prompts measure about 4.47 characters per token, so the flag reports
the corpus, not the cache; the server's exact prompt_eval_cached_count was not recorded by that commit. From
kannaka-bench commit eb9a1c8e99a686d07c34bff18edc996d74e80fe1 every row records prompt_eval_cached_count and done_reason, and all campaign
generation runs from that commit; the pilot rows stay as written. Definition, in force from this record: the gated
prompt-token count of a row is prompt_eval_count plus prompt_eval_cached_count, the whole prompt, so a warm shared
prefix cannot lower a row's gated cost; the calibration still rejects cached samples when fitting c_p.

Smoke check (three SELECT stores, full extraction sequence, forward and reverse). All commands returned 0. HRM
candidates h1, h2, h3 and h9 exist and vary across questions; h4, h5, h6, h7, h8 and h12 exist but were constant on
three fresh stores (clusters returned none; vacuity is decided on SELECT, not here); h10 and h11 do not exist:
the recall row's strength equals its similarity on every row (max abs diff 0.0), so prediction 9 holds and the
resonance margin and entropy columns are dropped as unavailable. Reverse-order feature rows were identical (max abs
diff 0.0). Store hash: the medium file never changed, but four cache files did (a retrieval-count sidecar rewritten
by every recall, not gated by observe-off or read-only; the cluster and metrics report caches written once by the
first clusters call; the status cache). The gated store hash is therefore defined over the memory state files
only (the medium, the encoder stamp, the agent id, the ingest log), the all-files hash is reported beside it with
the exclusion list and reasons, read-only mode is set in every spawn, and the status command is dropped from the
sequence (it fed no feature column). The re-run with that definition left the gated hash unchanged on all three
stores forward and reverse. Hashes of feature_schema.json, smoke_check.json and features.py are in the evidence.

TinyJev: not yet built. It is committed to the SELECT family comparison whatever its numbers: it is fitted at step
5 on the same rows as LAYA within the GPU cap, and amendment 2 reports its result or, if the pipeline cannot be
built, says so as a failure. No held-out number exists.

Nothing else in the preregistration changes: splits, arms, gate, predictions, selection rule and the hash order
stand. Written by Claude Code in a session run by the maintainer, who asked for the filing.

Evidence

content hash 9bfa6851ea142a89028a49df104cf2aefd5851d1291b4a7972a8afeadcc47d7b

Machine check: machine-checked

Derived from verify_record.py at b3ba75d; it never changes the standing.