Model Training Academy (MTA) is a TypeScript-first training orchestration framework for teams that want to run model work as a repeatable engineering process instead of a pile of one-off scripts.
The framework is being carved out of the private Waker monorepo so the orchestration layer can serve image, audio, text, and multimodal projects without inheriting Waker's wake-word product constraints.
This public repository is still early, but it is no longer just a placeholder. It now carries the intended process model, configuration model, release shape, and the first reference example for a small image-classification workflow.
MTA is for training systems where the hard part is not only "run the model" but also:
- keeping experiments comparable
- separating hypotheses from implementation details
- recording exactly what ran
- making benchmarks reproducible
- turning local scripts into a team-readable system
The framework is intentionally orchestration-first:
- configuration and planning happen in TypeScript and structured config files
- execution is delegated to explicit executor plugins
- every run writes a dossier with a stable artifact contract
- benchmark policy is treated as code, not a wiki page
MTA is designed around a scientific-method workflow rather than an ad hoc "launch some training and see what happens" loop.
The intended sequence is:
- State a hypothesis.
- Encode the hypothesis as a
study. - Declare the dataset, teacher, student, executor, and benchmark inputs explicitly.
- Generate a canonical plan before running anything.
- Execute through auditable run steps.
- Benchmark against declared rules.
- Promote, revise, or discard the result based on evidence.
That discipline matters because most training regressions are process failures before they are model failures. A run that cannot be reconstructed, compared, or explained is not a good run even if the numbers happen to look strong once.
Read this first:
project: the root boundary of one training programdataset: the input data contract, splits, lineage, and policiesteacher: the stronger or reference system used for supervision, initialization, or comparisonstudent: the model being trained or adaptedstudy: a hypothesis-driven training or evaluation programbenchmark: the scoring contract used to decide whether a study result is good enoughexecutor: the runtime backend that actually performs workexperiment: a lighter-weight sandbox for exploratory work that is not yet part of a promoted studydeployment: a packaged target shape or release profile
These nouns are meant to stay modality-agnostic. The same structure should work for a tiny image classifier, a speech detector, or a document model.
The target v0.1 configuration posture is:
mta.project.tsis the required root- entity files under
mta/can be.ts,.yaml,.json, or.jsonc - the loader resolves those files into one canonical project snapshot
plan.jsonis the content-hashable description of what will run- the run dossier records what was requested, what ran, what was emitted, and what happened
Configuration is not an implementation detail. It is the contract between research intent, execution, and review.
Read more:
The first public example is a deliberately small image-classification project:
- example path:
examples/public-tiny-mnist - purpose: show the full MTA shape on a simple image task
- model shape: a clean small CNN student
- task: MNIST digit classification
- workflow: inspect -> plan -> run -> benchmark
The example is important because MTA should be understandable through a concrete project, not only through abstract interfaces. This example is the reference narrative for "what it feels like to use MTA to train something simple and real."
Read more:
This repository is still pre-1.0.
- source-of-truth still lives in the private workspace
- the public tree is produced by a curated sync-out process
- the docs and example describe the intended v0.1 surface
- public package implementation is still being extracted
That means some pages describe the target contract before every package has landed. This is intentional. The docs are part of the design surface and are meant to constrain the extraction.
pnpm run verify