Eight appendices that document the engineering substrate of the present thesis: local project organization, repository, source code arborescence, launch commands, simulation and production execution, web interface, and execution journal.
The local project organization mirrors the modular structure of the methodology. The Visual Studio Code workspace contains five top‑level folders, each corresponding to one segment of the workflow. data/ holds the partitioned manifests for Tier‑A, Tier‑B, Tier‑C, and Tier‑D corpora; raw audio is stored on external object storage and referenced by URI from within the manifests. models/ holds the local model registry; foundation checkpoints are referenced as Hugging Face IDs in a JSON index. src/ holds the Python source tree, organized by component (3.1 routing, 3.2 typology, 3.3 EM loop, 3.4 latent inference, 3.5 calibration). experiments/ holds configuration files (YAML) and result manifests (JSONL). docs/ holds the manuscript sources, the model cards, and the datasheets. A .devcontainer/ directory provides a reproducible Docker development image; the IDE attaches to the running container so that the host system is not modified. Linting, type checking, and unit tests run on save through configured tasks.
The source code, the manifests, the experiment configurations, and the manuscript sources are kept in a private GitHub repository at https://github.com/<org>/prova‑mg (URL to be substituted on publication). Access is governed by an explicit collaborator list, recorded in the repository's README. A mirror to an institutional GitLab instance is maintained for continuity. On final defense, a public mirror is created and the artifacts are simultaneously archived on Zenodo with a persistent DOI; the private repository is preserved for change history but is no longer the canonical reference.
The Python source tree follows a component‑oriented layout. Each component of Chapter III has its own sub‑package; shared utilities (data loading, evaluation, training loops) sit in a separate common/ package. The structure is reproduced below in abbreviated form.
prova-mg/ │ ├─ data/ │ ├─ manifests/ │ │ ├─ tier_a.jsonl │ │ ├─ tier_b.jsonl │ │ ├─ tier_c.jsonl │ │ └─ tier_d.jsonl │ └─ manifests_test/ │ ├─ fleurs_mg.jsonl │ ├─ cv_mg.jsonl │ └─ in_domain.jsonl ├─ src/ │ ├─ common/ │ │ ├─ data_loader.py │ │ ├─ evaluation.py │ │ ├─ training.py │ │ └─ utils.py │ ├─ c31_routing/ │ │ ├─ teachers.py │ │ ├─ features.py │ │ └─ router.py │ ├─ c32_typology/ │ │ ├─ train_typ_lm.py │ │ └─ decode_with_prior.py │ ├─ c33_em/ │ │ ├─ e_step.py │ │ ├─ m_step.py │ │ └─ constraints.py │ ├─ c34_latent/ │ │ ├─ graphical_model.py │ │ └─ mean_field.py │ └─ c35_calibration/ │ ├─ features.py │ └─ fit_calibrator.py ├─ experiments/ │ ├─ configs/ │ └─ results/ ├─ tests/ └─ docs/ ├─ manuscript/ ├─ model_cards/ └─ datasheets/
The repository's README.md documents the canonical launch commands for each stage of the workflow. The commands are reproduced below in abbreviated form; the full file in the repository contains environment activation, distributed‑launch wrappers, and resume‑from‑checkpoint flags.
For methodological work prior to a full corpus run, a simulation mode is provided. In simulation mode, the unlabeled pool is replaced by a synthetic stream generated from the supervised set by controlled corruption (additive noise, time warping, partial label removal), and the teacher posteriors are emulated by an analytic mixture whose disagreement profile is parameterized. The simulation mode is built on a SimPy‑like discrete‑event harness and allows the validation of the constrained EM loop independently of compute‑heavy teacher inference. A typical simulation log is reproduced below.
The production mode runs the same code path on the actual Tier‑A through Tier‑C corpora and on the registered foundation models. A typical production log records GPU hours, dataset sizes, and per‑iteration WER on the held‑out development set. Logs are stored under experiments/results/<run_id>/ and indexed by Weights & Biases.
A small web interface, served from a FastAPI back‑end and a Svelte front‑end, exposes the final model for interactive testing. The interface accepts a recorded or uploaded audio segment, displays the top‑1 transcript together with the calibrated confidence and the per‑teacher transcripts, shows the inferred dialect and register, and highlights segments tagged as code‑switched. A screenshot, reproduced in the printed thesis, displays the layout: a recording widget at the top, the consensus transcription in the centre with confidence‑coloured highlighting, the three teacher transcripts side by side below, and a metadata bar at the bottom reporting dialect, register, code‑switching density, and a link to the segment‑level posterior visualization. The interface is intended primarily for qualitative diagnostic rather than for production deployment.
A daily execution journal is kept throughout the doctoral period as a tab‑separated text file under version control. Each entry records the date, the active stage of the workflow, the run identifiers launched, the experiment configurations modified, the issues encountered, and the resolution. An excerpt is reproduced below for illustration.