Back to Language as Infrastructure
working paper2026Controlled comparison manuscript

Does Script Design Matter? Phonetic Transparency and CTC Decoding for N'Ko

This controlled-comparison paper asks whether script design changes CTC decoding behavior. The point is not that one script is culturally preferable, but that phonetic transparency can change what a recognizer can align and learn.

Paper workspace

Live draft structure

working-draft

Artifacts

Draft PDF

Controlled-comparison draft for script design and CTC decoding.

Open artifact

Final split-paper render

Final split-paper artifact for phonemic evaluation and script-aware measurement.

Open artifact

Editable source

Draft PDF exists. The comparison framing should stay editable as the flagship paper evolves.

Source anchors

nko-brain-scanner/paper/current/paper4_script_advantage.tex

nko-brain-scanner/paper/final/02-phonemic-evaluation/paper.tex

Method tags

phonetic transparencyCTCcontrolled comparison

Ingest intersections

ctcorthographyscriptphonemicevaluation

Status

Drafted.

Key claims

01

Orthographic design affects the learning problem faced by a decoder.

02

Phonetic transparency can make some error classes more interpretable.

03

Script-aware evaluation should be part of low-resource ASR methodology.

Public reading note

Drafted.

Standard skeleton

What this paper must keep proving

Schema

problem

A metric can change meaning when the writing system changes what each symbol carries.

method

Compare decoding behavior under script representations with different phonetic transparency.

implementation

CTC heads, controlled script targets, shared audio conditions, error-class analysis.

data

Matched speech/text examples where script representation can be varied without changing the acoustic input.

evaluation

CER plus interpretable error decomposition, not only aggregate score.

references

CTC alignment, orthographic depth, phoneme-grapheme mapping, low-resource evaluation.

openQuestions

How to isolate script transparency from data availability and tokenizer prior effects.

Checkpoints and references

Proof chain

paperpending

Claim checkpoint

central-claim slot

Every central claim must point to a proof anchor or remain labeled as speculative.

implementationpending

Implementation checkpoint

implementation-map slot

Every method should identify the code path, harness, schema, or protocol that embodies it.

experimentpending

Evidence checkpoint

evidence-manifest slot

Every reported result should point to run IDs, packet IDs, data snapshots, commits, or review artifacts.

external-referencepending

Reference checkpoint

references slot

Every external claim should resolve to a cited paper, benchmark, standard, or documented prior system.

paperpending

Release checkpoint

release-gate slot

Every PDF needs a named condition before it can move from draft to citation-ready.