What every Meridian product owes you
The Meridian Pillars
Four principles every Meridian product embodies. They are about what the product does for the person using it — which makes them something you can hold us to, not a statement of taste.
Spark joy for analysts
The work should feel magical, not tedious. Clear output, helpful error messages, sensible defaults. The analyst should finish a task thinking that was easier than it had any right to be.
Write programs that do one thing and do it well
Inspired by the Unix philosophy, and it is a strategic bet rather than a style preference.
Meridian is an analytics framework built from the components up — modules that compose — rather than a monolith that does everything and cannot move. That choice is the competitive position:
- Versatility in the agent era. The bet is one interface per capability, so that where a component runs is not something an agent has to learn. A monolith forces one shape on every context.
- Agility that survives rapid process evolution. When how people work changes — and in the agent era it changes fast — composable modules re-arrange. A monolith has to be rewritten.
- Cost efficiency, for us and for you. You run the component you need. Nobody pays for the parts of the product they never touch, and we do not carry the weight of maintaining them together.
This pillar ranks work. Does this keep the pieces separable, or does it fuse them? is a live question about a proposed change, and a fusing answer is a reason to reshape the work. It is not merely a rule for how to construct something already chosen.
Design for the future, for it will be here sooner than you think
Taxonomies, model architectures and extension interfaces should accommodate what does not exist yet without breaking what does. Growth should not be stranded behind a decision made when the surface was smaller.
Precision Principle
Precision is what makes the product valuable, and it governs both the types we assign and the claims we make.
On a type — every validation pattern, locale rule and disambiguation heuristic must meaningfully distinguish “is this type” from “is not this type”. A validation that confirms 90% of random input is not a validation. Prefer precise locale-specific validation over permissive universal patterns; expanding locale coverage is the path to accuracy, not relaxing heuristics.
On a claim — the product, its documentation and its agents assert what can be shown, and say plainly what is not known. A confident picture that is wrong is the failure this product exists to prevent, so asserting one about our own work is the same defect wearing a different coat. An unpinned number, a bare universal quantifier and a promise the artefact does not keep are all precision failures.
The names are canonical here; the reading is local
Each part of Meridian reads these four principles for its own surface — the same principles, expressed as what they mean for a typing engine, a renderer, or a dataset. This page is the statement they point back to, so it is the one to cite and the one to argue with.
Judge them against something that exists: what works today, the open datasets, and the protocols that make them.