About
What this is, and what it is not yet.
An open-source modelling language and compiler for systems whose specifications are too important to live in four tools that never meet. It is pre-1.0, and this page says exactly what that means.
01 / What this is
A compiler, a wire format, and every surface
Not a diagram tool with an export button. The compiler checks a model, lowers it to a versioned artifact, and that artifact is what everything downstream reads.
Phero Lang gives each kind of specification its own small language — a domain model, an application design, an authorisation policy, a decision model, an event contract, a use case pattern, a case model, an interaction flow, a deployment projection. They share one type index, one expression language and one diagnostics registry, so a check in one can see a declaration in another.
Each surface compiles to a JSON artifact with a version gate. Rust code generators, JSON Schema, Cedar policy, a DMN engine model and a CMMN case definition all read those artifacts and nothing above them. That boundary is the design: it is why a backend can be written outside this repository, and why a grammar change cannot quietly alter generated code.
The whole implementation is a Rust workspace, released as one binary,pherolang. The documentation in this repository is the same documentation the docs site renders — there is no second copy to drift.
The example corpus
9
Surfaces
23
Crates
8
Applications
305
Graph nodes
Compiled by pherolang 0.3.0 (x86_64-unknown-linux-gnu) fromexamples/, which CI compiles, generates and executes on every change.
02 / Who it is for
Three kinds of team, and one kind that should wait
A modelling language is a long commitment. It is fairer to say who will get value from this one now, and who will not.
Teams whose domain is the hard part
Lending, insurance, health, logistics, internal platforms: anywhere the rules are the product, authorisation is part of correctness, and a decision table outliving its author is a liability. These are the systems the surfaces were shaped against.
Platform engineers who generate code
If you already write generators against a schema and you are tired of the schema being whatever the last parser produced, the artifact contract is the interesting part. A backend is a function; it needs no compiler changes and no grammar knowledge.
People who need the model to outlive the tool
Artifacts are committed, byte-compared and validated without the compiler. A model is a file in your repository, not a row in somebody's database — which is also why it can be reviewed like code.
03 / Maturity
Pre-1.0, with the rules written down
Version numbers are a promise. This is the promise, in the terms the project actually publishes.
0.x does not promise stability. Grammar, artifact shape and CLI surface may change at a minor version. What is promised is disclosure: every break lands in the changelog with the golden-regeneration notes needed to see exactly what drifted.
1.0 freezes the wire formats. From then on, within aformatVersion, evolution is additive only: new optional fields, no renames, no changed meanings, no artifact that stops parsing. A formatVersion bump is the only sanctioned break, and it has to be a major release with a migration note.
One exception has already been spent. The 0.3 release does not read 0.2 artifacts. When the product was renamed for 0.3, the provenance key, the instance discriminator and the schema identifier all moved with it, so every artifact that depended on them moved to formatVersion 2. That was the single allowed pre-1.0 wire break; a saved older artifact fails artifact check with one named migration message instead of a generic mismatch.
Support is bounded. Only the latest 0.x minor receives fixes, and there is no commercial support contract, SLA or hosted service. Security reports have a private channel and a stated response aim, not a guarantee:SECURITY.md.
The full policy — what each artifact promises, what a release consists of — isVersioning and release policy.
Where the guarantees live
- Versioning — 0.x allowances, the 1.0 freeze, the one pre-1.0 wire break.
- Backend contract — what an artifact guarantees to whoever consumes it.
- Proof-obligation register — each claim's status and evidence pointer, with a review date on the rows that carry one.
- The claim ladder — including everything the project explicitly refuses to claim.
- CHANGELOG.md — the drift record itself.
04 / The name
Phero Lang, two words
A spelling rule, stated once and held mechanically by the repository's own gate.
The product is Phero Lang — two words, never the bare token. The wordmark and the command-line binary are pherolang, one word. The library crates arephero-*; the repository is yestechgroup/pherolang; the origins arepherolang.com and docs.pherolang.com.
This is not a style preference. The single token is already the name of unrelated projects, so a search for it lands somewhere else; the compound is what this project can own. The rule is enforced by a script in the continuous-integration gate, which fails on any revived spelling outside a small, documented allowlist — the naming contract isdocs/NAMING.md.
05 / Where the work happens
In one repository, in the open
The compiler, the grammar, the documentation, the examples and this site are in the same Apache-2.0 tree. There is no private core.
Bug reports, failing test cases, documentation fixes and new backends are all welcome —CONTRIBUTING.md is the path from a clone to a merged pull request. The gate is one script;CI runs the same one, so a green local run and a green CI run are the same thing.
The examples are not samples: examples/ is compiled, generated and executed by the test suite on every change. If a claim in the documentation stops being true of the code, the build fails before the documentation can drift.
06 / How to engage
File an issue, or model something with us
The fastest useful contribution is a failing case. The most useful conversation is a real domain the current surfaces do not describe well.
For a bug: a minimal reproducible model beats a description. Attach the smallest.mox or design file that shows the problem, the output ofpherolang --version, and what you expected instead.
Design partnerships are how the next round of work gets chosen: a few teams at a time, working with the maintainers on a real system. It is pre-1.0 tooling with no support contract, so the terms are modest in both directions — what a partner gets and what we ask is spelled out on the homepage.
Suspected vulnerabilities go through aprivate advisory, never a public issue.
Design partners
Write to hello@pherolang.com with a paragraph about what you are modelling and what makes it hard. There is no form and no sales call.