tetracta ai

Thank you. You are right on every number, and on what they show: the tie is in our response projection, not in the weight tables.

The two comparisons have the same categorical outcome at every evaluated position from block 4 onward, and so the same count. The weight tables of reports 12 and 14 order them: base→instruct moves more weight than the partial INT8 simulation in all 32 blocks, by 1.55x to 2.17x, and 0.4330% against 0.2098% overall. We checked your figures against both pages and they match. Our reports ask readers not to compare numbers across reports because references usually differ; they differ here too (instruct in one, base in the other), but the parameter groups match one to one, the change is computed the same way, and the reference norms you derived agree to about 0.1, so the ordering holds.

"Your computation on withdrawn fields" in our last reply was about your 13 September tally; it does not describe this comparison, which uses only fields we publish today. Our note of yesterday said we had "published nothing finer" that would order two scans at the maximum. For distance in the weights that was wrong, and we have corrected it with a dated line that credits your comparison: https://tetracta-model-xray-sample-reports.static.hf.space/notes/2026-09-22-count.html

Your reference-norm point is right too: the implied norm grows from about 56 at block 1 to about 308 at block 32, so a relative change that falls down the stack mostly reflects larger weights, not where an edit landed. Relative and absolute change have to be read together; we have added that caution, crediting your reading, to "How to read the report" on our scope page: https://www.tetracta.ai/model-xray/scope/

On block 4: as we said on 12 September, the coverage boundary is imposed by the scanner. It is fixed in the current release, the same on every scan we have published, and not a measured sensitivity floor. Why the scanner's coverage begins there is an implementation detail we keep private. What the boundary means for reading a report is public: a depth view that is "unresolved" at block 4 cannot locate where a difference began, and on this pair it cannot separate the two arms. That has held for every pair of independently published checkpoints we have scanned. The only published cases with a later start are three controlled fine-tunes of our own, at depths we chose (block 12, 6 and 19 of 24), and those studies do not establish onset localization for arbitrary fine-tunes.

— Tetracta

Follow-up, 22 September 2026. Thank you for the corrected ceiling and for checking the other two.

1. The Mistral tie, re-run today under the current contract. The rights register now lists Mistral-7B-v0.3 @ caa1feb0e54d415e2df31207e5f4e273e33509b1 and Mistral-7B-Instruct-v0.3 @ c170c708c41dac9275d15a8fff4eca08d52bab71, so both arms were run (instrument VG1, mv-1.4, rs-1.7):

   • int8 arm — partial in-memory INT8 simulation of Mistral-7B-Instruct-v0.3, produced on the live service: difference observed at 29 of 29 evaluated positions; text output changed on the evaluated inputs; overall relative weight change 0.2098% over 291 tensors. Report: https://tetracta-model-xray-sample-reports.static.hf.space/current/12-nicemleme-mistral-7b-instruct.html
   • base → instruct pair: difference observed at 29 of 29 evaluated positions (decoder block 4 output through the final normalized output; blocks 1–3 not evaluated); text output withheld — the two artifacts do not share a tokenizer contract, so it is recorded as a combined artifact change; overall relative weight change 0.4330% over 291 tensors. This arm ran with the same instrument release outside the customer path, because the customer path failed for a pair of two 7B checkpoints today; the report is unsigned and carries no operational receipt, and is labelled so: https://tetracta-model-xray-sample-reports.static.hf.space/current/14-arastirma-mistral-7b-cift.html
     At the published projection the two arms tie at the ceiling. The 22 and 22 you computed came from the withdrawn calculation; we have not published a replacement value for any of the 22 historical pairs and will not quote one per pair before the frozen preregistered program on the correction page passes.

2. What that projection is: for each profile position a categorical outcome under one fixed decision rule (not evaluated / no difference observed / difference observed) and the integer count of evaluated positions showing a difference; in the report's words, "this count describes the reach of the observed response, not its size or the number of changed weights." On every published pair of public checkpoints and every int8 simulation so far it sits at its ceiling; the exception is our three controlled LoRA fine-tunes (7 September table, rows 11–13): first difference at block 12, 6 and 19 of 24. A count at its ceiling on both arms cannot separate them, and Mistral is no different.

3. Your 7 up / 0 down / 1 tie is your computation on withdrawn fields; we neither dispute nor adopt it.

Scope (twenty-one repositories as of today, local workers): https://www.tetracta.ai/model-xray/scope/

edit note : One clarification on our own numbers, before you have to go looking for it.

The 29 of 29 we quoted for the base→instruct arm is not printed as a line in that report. Report 14 is rendered by an older standalone template that carries no depth view and no "N of N" summary; what it publishes is the per-block record, and the 29 is counted from it — the positions from the decoder block 4 output through the final normalized output, twenty-nine of them, each recorded as a difference, with blocks 1–3 outside the evaluated set. The int8 arm's report does print that line, which is why the two pages read differently even though both arms come to the same count.

The same page also prints "24 probes evaluated". That is a different quantity: the page labels it the size of the evaluated set at its reporting depth and states that it is not a count of what differed. It should not be read against the 29.

Neither point changes the answer. Both arms sit at the ceiling and the count does not separate them.

— Tetracta

Appreciate it! We believe an instrument is only as useful as the boundaries it admits. The 'hype' phase of AI is ending; we're focusing entirely on building tools that can pass an adversarial audit. Glad to have you following the journey.

Dipankar — we rechecked the exact September 3 gallery revision. Your final question has a direct answer: the initial coverage boundary was imposed by the scanner. It was not evidence that the models first changed there. Calling it a measured sensitivity floor was wrong.

1. Coverage and spread. We reproduced the result across all 22 pairs. The initial unmeasured positions were written as zeros, and spread followed from the reported start and total depth. Neither supports the original location or severity interpretation. The replacement candidate distinguishes “not evaluated” from “no difference detected”; a difference at the first evaluated point leaves the earlier boundary unresolved.

2. Changing contributors. We reproduced the rising/falling pattern you identified. The replacement calculation holds the contributing set fixed over the evaluated region. A mechanical control and our separate arithmetic recheck on retained raw comparisons agree with that calculation. This addresses the changing-membership effect; it cannot recover the missing prefix or establish causal localization.

3. N80. Your denominator criticism holds. Our descriptive replacement uses measured coverage and handles ties and zero signal explicitly. We also distinguish an integer count from a fractional depth share. One arithmetic qualification to the flat-profile example: an integer count requires a ceiling, so 17 total positions with 13 measured positions gives 11/17. That does not rescue comparisons made with the old denominator. We are not reinstating the old severity verdict or a cross-model quality ranking.

4. Output changes and paired outcomes. A base/chat output difference is not a capability improvement. For the original fabricated-name items, the retained paired transitions are 6 in one direction and 1 in the other: exact two-sided McNemar p = 0.125. The old scoring counted avoidance of repeating a fabricated name; it did not validate fabrication avoidance. The earlier improvement interpretation remains withdrawn.

5. AUROC. The archived first-report inputs contain 20 known and 20 fabricated items. The stored value is 0.8775, which is compatible with that pair count; the HTML and post displayed it differently. We cannot reproduce that first trajectory AUROC from its original item scores because those scores are absent from the retained record. Later scans are not a substitute. We have not restored the Knowledge or separation claim.

We have a separate early-coverage candidate with bounded controls on one trained small model, including recorded misses at small changes. That is research evidence, not a repair of the historical scans or validation across arbitrary fine-tunes. General onset localization and added usefulness over simpler comparisons remain open.

The updated VG1 application has been deployed with a narrower scope than the original post. Customer scan-to-report acceptance is still pending. The calculation changes above are in this release; the wider measurement questions remain open.

Historical gallery revision · Dated correction

Apologies — I posted my reply in the wrong thread. It belongs in the discussion about Tetracta Model X-Ray:

Thank you for this — genuinely. This is one of the most valuable pieces of feedback the instrument has received, and exactly the kind of reading we hoped the raw files and notes would make possible.

A first pass on our side already confirms that several of your points land — including the change-start floor question and the paired-test point on fabrication-avoidance — and there is at least one place where we owe you a data-backed clarification rather than a concession. We are now working through the whole review carefully as a team: the front-card wording, the indexing inconsistency, how the verdict fields are presented, and what raw data should ship alongside the rendered reports.

We'll come back to this thread with a point-by-point response and the actual corrections — not just words. Thank you for spending this kind of time on our instrument; reviews like this are how it gets better.

— Tetracta

سلام! 👋 Welcome — if you try a scan, tell us what you find. — Tetracta