Script Invisibility Is Structural: Activation Profiling Across Three LLM Families
A cross-model extension of the activation profiling work. Instead of treating one model family as the source of the problem, it tests whether script invisibility recurs across model families and therefore reflects a structural training-distribution issue.
Paper workspace
Live draft structure
Artifacts
LaTeX source mapped
The cross-model source is mapped, but no public PDF render has been attached in this pass.
pending-render
Editable source
LaTeX source exists. Rendered PDF still needs to be produced or selected before public artifact attachment.
Source anchors
nko-brain-scanner/paper/current/paper3_cross_model.tex
nko-brain-scanner/paper/final/01-script-invisibility/paper.tex
Method tags
Ingest intersections
Status
Drafted.
Key claims
01
A failure repeated across model families is harder to dismiss as implementation noise.
02
Script visibility should be audited across architectures.
03
Low-resource evaluation needs internal diagnostics, not only benchmark scores.
Public reading note
Drafted.
Standard skeleton
What this paper must keep proving
problem
A single-model result can be dismissed as model-specific; the structural claim requires recurrence across model families.
method
Compare activation and behavior across three LLM families under the same N'Ko/script probe conditions.
implementation
Cross-model LaTeX manuscript plus shared script-invisibility probe family.
data
Matched N'Ko probes and comparable model-output/activation snapshots.
evaluation
Whether the invisibility pattern repeats across architectures rather than appearing in one family only.
references
Multilingual benchmarks, tokenizer studies, representation diagnostics, script undertraining literature.
openQuestions
Which model families and exact checkpoints should be cited publicly with reproducible version labels.
Checkpoints and references
Proof chain
Claim checkpoint
central-claim slot
Every central claim must point to a proof anchor or remain labeled as speculative.
Implementation checkpoint
implementation-map slot
Every method should identify the code path, harness, schema, or protocol that embodies it.
Evidence checkpoint
evidence-manifest slot
Every reported result should point to run IDs, packet IDs, data snapshots, commits, or review artifacts.
Reference checkpoint
references slot
Every external claim should resolve to a cited paper, benchmark, standard, or documented prior system.
Release checkpoint
release-gate slot
Every PDF needs a named condition before it can move from draft to citation-ready.