Machine dialects are worth what the listener can parse

A dialect's worth is relational, not intrinsic

The central claim of the project is that a machine dialect is neither strong nor weak on its own. Its value is relational, expressed in the README as a formula: dialect utility is a function of speaker, listener, task, route and budget. Five terms in one expression is the whole research programme, because it rules out the more comfortable assumption that a good dialect is simply a good one. The framing underneath it is that language models increasingly operate as heterogeneous systems of solvers, routers, critics and tool users, yet their intermediate reasoning is still almost always written as human-facing prose. MDia recasts a trace as a message produced by one machine component and interpreted by another. Speaker models create persistent Language Symbolism Frameworks, which the README calls compact dialect cards carrying symbols, grammar, reusable operators, validity rules, answer contracts, provenance and empirical transfer profiles. Listener models then execute those dialects, and routing happens under explicit accuracy, token, parseability and reliability constraints rather than under a single global score for the prompt.

Compression can delete exactly what the listener needs

The argument against naive brevity is the most transferable idea in the repository. Natural language is readable and flexible, but it can spend generated tokens on discourse, pedagogy and surface conventions that a machine listener has no use for. The tempting fix, forcing shorter answers, does not work, and the reason is specific: aggressive compression can remove variables, evidence links, parse commitments, verification state and output contracts, which are precisely the parts the listener does need. That produces the distinction the project keeps returning to, the separation of brevity from communicative adequacy. The objective is not to minimise tokens in isolation, it is to preserve the task relevant state that a particular listener can reliably interpret under a budget. The same relational thinking shows up in the contrasts the README draws: a prompt or language has no single global quality score, a stronger solver is not automatically a better teacher, and weak or specialised speakers can produce highly adoptable public dialects. Hidden state is also not required, since the protocols are discrete and can be stored, hashed, compared and routed across black box APIs.

Eight lifecycle stages end in a frozen dialect bank

The at a glance table condenses the design into one row per dimension. The scientific object is a reusable machine dialect held as a persistent LSF card, and the unit of analysis is a speaker, listener, dialect and task event, which is what makes transfer measurable rather than anecdotal. The lifecycle is eight named stages: collect, create, evolve, profile, select, route, validate and report. The selection principle is the one worth memorising, because it is a sequencing constraint rather than a technique: dialects and route policies are frozen from validation evidence before any held out execution. Inference plans come in four shapes, `single`, `aggregate`, `compose` and a guarded `abstain/raw-fallback` that exists for the case where the dialect fails and the model should drop back to raw output. Compatibility is stated as discrete, archivable, auditable and workable against black box LLM APIs. The research scope behind all of it names the studies the framework exists to enable: accuracy and token frontiers, cross model transfer, listener openness and resistance, publicness, teaching advantage, code switching and negative transfer guards.

CLSR is now a config file, not the main event

The repository states its own priority order bluntly: it is MDia first, and CLSR is the homogeneous agent, concrete LSF routing special case configured through `configs/clsr.yaml`. The supported implementation lives under `src/mdia/`, while historical research workspaces stay under `legacy/` for provenance and are explicitly not the public API. The division is a real change of scope rather than a rename. CLSR introduced the create, evolve and route lifecycle for reusable LSFs inside a homogeneous model community, and MDia keeps that foundation while expanding the unit of analysis to heterogeneous speaker and listener interactions. The comparison table spells out what that changes in practice. The community moves from homogeneous or same family agents to heterogeneous families and scales. The object moves from LSFs optimised for the accuracy token frontier to a dialect ecology indexed by speaker, listener, task, route and budget. Cold start changes most: CLSR induced initial LSFs from task exemplars, whereas MDia treats direct traces as evidence that carries more weight than a hand written starting point and requires no human authored meta dialect. Transfer becomes explicit self dialect and foreign dialect matrices rather than reuse inside one community, and the profile columns change with it, from accuracy, cost, domains and failure modes towards publicness, openness and resistance, which are properties of the listener rather than of the dialect alone. The comparison table in the copy of the README available here is cut off mid row at that profiles line, so the remaining rows of that table cannot be confirmed from what is visible.

The toy pipeline needs no key and no model download

The quickstart is built so it cannot fail for the usual reasons. The deterministic toy pipeline exercises the complete lifecycle using redistributable fixtures, and it requires Python 3 or newer, no API key and no model download:

python -m venv .venv
source .venv/bin/activate
python -m pip install -e .

mdia pipeline --config configs/toy_mdia.yaml

One command produces a versioned run directory containing immutable split manifests, direct traces, dialect generations, transfer profiles, a frozen dialect bank, route plans, predictions, token accounting, rule results and a reproducibility report. The determinism claim is narrow and testable: re-running with the same configuration and seed selects the same cards and the same routes. Help for both the top level command and the pipeline subcommand is available through `mdia --help` and `mdia pipeline --help`. So the entry cost is a virtual environment and an editable install, and the first artefact you can look at is a report rather than a set of logs. The toy fixtures live under `examples/toy/`, and the packaged configuration is `configs/toy_mdia.yaml`. The rest of the tree follows the same split between research and research output: `artifacts/`, `assets/`, `docs/`, `papers/`, `scripts/`, `src/`, `tests/` and `configs/` at the top level, alongside `CITATION.cff` for citation metadata and a `.gitleaksignore`, which is a reasonable companion to a repository whose whole subject is exchanging generated trace files between models. The project is MIT licensed and its primary language is Python, with the last push to main on 30 July 2026 and no published GitHub releases, so the PyPI version string rather than a release tag is what pins a run.

Every value in the report resolves to an artifact and a checksum

The layout of a run directory is the reproducibility argument, so it is worth reading as a contract rather than as file names:

runs/<run_id>/
  manifest.json
  report.md
  splits/{induction,evolution_validation,router_validation,test}.json
  direct_traces.jsonl
  dialects/generation-*.json
  profiles/{evolution_validation,router_validation}.jsonl
  selection/frozen_dialect_bank.json
  execution/{route_plans,predictions,evaluations}.jsonl
  execution/token_accounting.json
  rules/{registry,results}.json

The splits are named by stage, induction for building, evolution validation and router validation for selection, and a held out test set, which is the same three way split the selection principle depends on. Selection gets its own directory because the frozen bank is the artefact a held out run consumes. Execution keeps plans, predictions and evaluations together so a prediction can be read next to the route that produced it, with token accounting beside them so the accuracy and cost claims sit in the same place. And the stated rule for the report itself is the strictest line in the README: every value in it is designed to resolve back to a run artefact, an evaluator version, a count and a checksum.

Two runtime dependencies and a strict type checker

The packaging is deliberately plain, which suits a research artefact that others need to reproduce. The distribution is `mdia` at version 1.0.0, requires Python 3.10 or newer, and declares exactly two runtime dependencies, pydantic in the 2.7 to 3 range and PyYAML in the 6 range. Everything heavier is optional: an `analysis` extra for numpy and scipy, and a `dev` extra holding mypy, pytest 8, pytest-cov, ruff and types for PyYAML. One console script is exposed, `mdia` bound to `mdia.cli:main`, and packages are discovered under `src`. The linting and typing settings are where the strictness shows. Ruff targets py310 with a line length of 110 and selects the pycodestyle, pyflakes, isort, pyupgrade and bugbear rule sets while ignoring line length violations. Mypy is configured for Python 3.10 against the mdia package with `disallow_untyped_defs` and `no_implicit_optional` on, plus checks for unused configs, redundant casts and unused ignores. Pytest runs quiet with the test path pinned to `tests/`.

The .env.example exists to say it is not read

The environment file is a trap for anyone assuming dotenv support, and the comments inside it are the documentation. The first line says the deterministic toy pipeline does not require any environment variables at all. The next says the package does not parse `.env` files, and that `.env` is ignored purely as a safety backstop. Two blank placeholders are provided anyway, `MDIA_API_KEY` and `MDIA_API_BASE`, for a provider backed adapter whose variables you export through your shell or secret manager. The rule about where configuration belongs is the important one: the model name and an optional `api_key_env` override live in the validated run config, not in this file, and if `api_key_env` names a different variable you define it only in your local environment. The closing instruction is explicit, do not add a resolved key here. So the file is a signpost rather than a configuration surface, and the security model depends on that distinction being respected.

Editorial conclusion

Treat MDia as research infrastructure rather than a library to drop into a product, because what it ships is a reproducible experiment harness with an ICML 2026 paper attached, not an inference client. It earns its place when your problem is several models talking to each other and you need to know which compressed dialect each listener can actually execute under a token budget. Three things to check before you build on it. Read the artifact contract rather than the prose, since every figure in the report is supposed to resolve to a run artifact, an evaluator version and a checksum. Keep CLSR in mind as the special case rather than the product, since it is a config file over a homogeneous model community. And read the `.env.example` comment before you wire secrets, because the package deliberately does not read `.env` files and only the validated run config is allowed to name a key environment variable.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pzqpzq/LSF_MDia on GitHub
4. README