Running an Audit
Before a new corpus is QC'd and published into FormosanBank, its preprocessing is audited: every transformation the corpus's ingestion code applies to the data is checked for correctness against FormosanBank's conventions. This page describes the audit as a manual procedure — the steps, the tools to run, and the judgments to make. FormosanBank also ships a guided audit-dev-repo Claude skill that walks you through exactly this sequence; the steps below are what that skill automates.
What you need
A local clone of FormosanBank with its
.venvactive (source .venv/bin/activate).The corpus dev repo as a sibling directory (e.g.
../Formosan-<Name>/) containing the built XML (commonly underXML/, sometimesFinal_XML/) and the ingestion scripts that produced it.The corpus's language, so you can find the right reference data under
QC/validation/reference/<Language>/andOrthographies/Ortho113/<Language>.tsv.
Read FormosanBank's CLAUDE.md and the QC Pipeline overview first — they define the conventions an audit checks against.
The scope: anything that touches the data
The general goal is to check every transformation the preprocessing applies — each one should make sense and look correct. Four concerns are highlighted priorities (not an exhaustive checklist):
(a)
Eliminated orthography characters
Real letters dropped — glottal-stop apostrophe, ŋ, ə, ɬ, barred/stroked letters. Curly apostrophes (’, U+2019) silently lost are a classic case.
(b)
Suppressed punctuation
Punctuation or segmentation stripped from the tier that must stay faithful (the original tier), or segmentation markers (-, =, <…>) removed from the W tier.
(c)
Other convention breaks
Schema, kindOf, TRANSL/@ver, dialects, segmentation markers, id rules.
(d)
Source-extraction artifacts
Leftovers like sentences the source marked ungrammatical (sentence-initial *), footnote-digit leaks, out-of-language examples.
The original tier is the faithfulness anchor: most of (a), (b), and (d) reduce to "did the original tier lose something the source had?"
The procedure
1. Read the preprocessing
Read the dev repo's README and every scrape/parse/build script. Produce a plain-language summary of the transformations it applies and in what order — flag every step that deletes or substitutes characters or drops/normalizes punctuation. Confirm your reading is correct before going further.
2. Map each transformation to our pipeline
For each step, classify it: (i) our pipeline already does this (and how it differs), (ii) it's a no-op for us, or (iii) it conflicts with a convention (cite which). Pay special attention to anything touching the original tier and to W-tier segmentation markers, which must survive. As a reference, FormosanBank's own tooling runs in two passes — a cleaning & standardization build (apply_manual_edits → clean_xml → orthography detection (human) → standardize → add_phonology) followed by a read-only validation pass — both laid out in the QC Pipeline overview.
3. Run the validators on the built XML
Run the finding-based validators against the dev repo's XML output and read each per-rule summary plus its findings CSV. Use --no-exit-on-hard so a HARD finding doesn't abort your run — at this stage you are gathering information, not gating.
Organize the hits by concern using the map below.
4. Diff the output against the source
Automated rules don't catch everything. Pull a sample of sentences with sample_sentences.py (or pick representative ids) and, for each, compare the FORM[@kindOf="original"] against the raw source:
(a) Did any orthographic letter disappear? Compare the original-tier character inventory against both the source and
reference/<Language>/.(b) Did punctuation or segmentation in the original tier vanish relative to the source?
(d) Are there sentence-initial
*(should have been excluded), footnote-digit leaks, or out-of-language runs?
5. Flag and decide
Group findings by concern (a–d) with concrete evidence — file, id, and a source-vs-XML sample for each. This is a human-judgment step: every finding needs a maintainer's call (real bug / acceptable / needs a source check) before it becomes a remediation item. An audit surfaces problems; it does not fix them.
6. Record the report
Write a per-repo report (the skill saves it at claudeplans/audit-<Repo>.md): what the preprocessing did, findings by concern with evidence, the pipeline mapping, and which conflicts must be fixed in the reproduction scripts before the corpus is ported.
Concern → tool map
(a) dropped orthography chars
orthography_extract.py --kindOf original → validate_orthography.py vs reference/<Language>/; diff the original-tier inventory against the source; watch curly-apostrophe loss
(b) suppressed punctuation
validate_text.py; confirm the original tier still has source punctuation/segmentation and the W tier kept -/=/<>
(c) convention breaks
validate_xml.py (schema/kindOf/ver/dialects) + validate_glosses.py (segmentation & reconstruction rules)
(d) extraction artifacts
validate_text.py (*-in-FORM, footnote leaks); grep source + XML for sentence-initial *, stray digits, out-of-language runs
Important boundaries
An audit is not a fix-it pass. Do not modify the dev repo or
Corpora/while auditing. Remediation happens in the dev repo's reproduction scripts, then the corpus is re-QC'd.Evidence over assertion: every finding should cite a file, an id, and a source/XML sample.
Once the audit is clean (or its findings are remediated and re-QC'd), the corpus is ready to port in.
Related
Last updated