The MGF engineering standard

A family policy, written down and countable.

The mgf-* libraries and tools use this standard with validation suited to each project's language and conformance level. The sooth systems-software family follows its own engineering standard.

What a standard is

A standard is how values become repeatable behaviour.

The MGF engineering family is meant to grow without becoming a pile of unrelated projects. Its standard is how that stays possible.

It turns values into repeatable behaviour: typed errors, structured logs, layered configuration, reproducible checks, explicit status, and reviewable evidence. A library should not only claim reliability — it should leave signs a human, a tool, or a future maintainer can inspect.

The corpus

The bar is a rule corpus, and the corpus is indexed.

Rules are anchored identifiers, grouped into families, each family defined by one document. The index is machine-readable, which is why this page can count instead of estimate.

The standard is an anchored rule corpus with a machine-readable index: rule identifiers, their families, and which are binding. recorded at build · 2026-09-04

323 anchored rules
313 binding (MUST)
10 advisory (SHOULD)
25 families

Every family in the index, largest first — identifiers and defining document only. The rules themselves live in those documents. recorded at build · 2026-09-04
Family	Rules	Binding	Defined in
TS	29	29	TESTING.md
AG	23	22	AGENTS.md
SC	23	23	SECURITY_STANDARD.md
DOC	19	19	DOCUMENTATION.md
LG	17	17	LOGGING.md
AP	16	16	API_DESIGN.md
DP	14	14	DESIGN_PRINCIPLES.md
REL	14	14	RELEASING.md
WF	14	14	WORKFLOWS.md
CF	13	13	CONFIGURATION.md
EH	13	13	ERROR_HANDLING.md
CRT	12	12	REVIEW.md
OP	12	12	OPERABILITY.md
PKG	12	12	PACKAGE_DISTRIBUTION.md
DEP	11	11	DEPLOYMENT.md
OB	11	10	OBSERVABILITY.md
SEAT	11	10	SEATS.md
GUI	10	10	GUI_CONSUMERS.md
SHP	10	10	SESSION_HOOKS.md
PF	8	7	PERFORMANCE.md
TM	8	6	TIME.md
PR	7	5	PRESENTATION_LAYER.md
SP	6	6	SCOPE.md
FB	5	5	DOCUMENTATION.md
NM	5	3	NAMING.md

The contract

Joining the federation is a two-sided agreement.

An MGF project that adopts the standard owes a documented set of commitments; the federation owes it shared library surfaces, recipes, a gate shape, a feedback channel, and coordinated release semantics.

The contract between the federation and a project that joins it is locked: what a project owes and what it is owed change through named amendment classes, not through a quiet edit. recorded at build · 2026-09-04

The standards corpus is locked: amendments are classified, and a breaking change is close to never. recorded at build · 2026-09-04

The engineering standard this site is built against is recorded at build from the standard's own package metadata. recorded at build · 2026-09-04

Versions shown here are the versions the registry records for the working tree. The package index is the publication contract, and the two are not guaranteed to agree — the index is what an install command actually resolves against. recorded at build · 2026-09-04

Every project reads as though one hand wrote it.

The levels

Adoption has degrees, and each project declares its own.

A single bar does not mean a single depth. Each repository declares a level in its own tracker and audits itself against it — including when the audit says it has not got there.

The MGF standard defines three conformance levels. A repository's own tracker records its declaration and evidence where that tracker exists; the public registry does not supply a per-project conformance result.

The estate records its own failures with dates: a conformance tracker that says a repository is below the level it declared, an audit artifact whose waivers expire, and a gate whose documentation records how long its predecessor checked nothing.

L1 — Lite

The spirit of the standards, best effort. Where a greenfield experiment starts — and where this website itself sits, with a recorded carve-out for the rules that assume a Python package.
L2 — Standard

Every binding rule, audited one by one with evidence per rule. The default for federation siblings and for anything a production system depends on.
L3 — Strict

Binding rules, advisory rules, and runtime enforcement wired in. The cornerstone library holds this level, re-checked adversarially rather than self-declared.

The registry records no conformance level, so no level is shown against any project on this site. The declaration lives in each repository's own tracker, with the date it was last audited.

How a value becomes something you can check.

values rules checks evidence behaviour MGF policy

Within the MGF family, values become rules, rules become project-specific checks, and checks leave evidence with stated limits.

A value on its own is a claim. The standard turns it into a rule, a rule into a check, a check into recorded evidence — and evidence into behaviour a human or a tool can repeat.

The MGF Python baseline names four gate categories: linting, strict type checking, tests with a coverage threshold, and import layering. Each project declares validation suited to its language and conformance level; this is policy rather than a recorded pass, and it is not the sooth family's suite.

The baseline gates are described here as policy thresholds rather than an estate-wide result. Dated local measurements and CI evidence retain their run context; this page does not turn them into a universal current score.

Some builds here are checked for reproducibility rather than assumed: a proof repository rebuilds an integer core on different processor architectures and compares digests, and release artifacts are produced with a reproducible bill of materials.

The look of this site is gated too: undefined design tokens, raw colour values, more than one top-level heading per page, and type below the legibility floor all fail the build. recorded at build

The four categories describe the MGF Python baseline. A Zig project, this Astro site, and a sooth-family repository use validation suited to their own language, scope, and standard; the presence of a policy does not assert a passing result for any project.

What each of those gates cannot tell you is written out on proof.

The standard, in spirit

What an MGF project is asked to carry forward.

The MGF rule corpus, federation contract, and library registry live in one repository. These principles describe their intent; each project still needs its own executable validation.

One MGF family bar

Projects in the mgf-* engineering family use one documented standard, adapted to each language and declared conformance level. The sooth family follows its own standard.

Deterministic outputs

The same inputs should produce the same bytes. Where that is checked rather than assumed, it is checked by something a stranger can run — and where it is not yet checked, the page says so.

Provenance-bearing artifacts

Important artifacts carry where they came from and how they were made, so a claim about an artifact can be traced instead of trusted.

Machine-verifiable claims

Where a claim can be checked by a tool, a tool checks it. Significant changes pass an explicit review and must be backed by evidence a machine can re-examine.

Typed errors and structured logging

Failures are explicit and typed; logs are structured and consistent across the federation, so a system is observable and debuggable by design rather than by heroics.

Rejection is a correct outcome

Correctly refusing invalid input is a recorded, successful result — not a crash. The system is honest about what it knows and what it will not accept.

Documentation for people and machines

Documents are written for humans and for the agents that build with the work — concrete, enumerated, and kept true to the artifacts they describe.

Read the rules, or see them applied

The standard, the libraries and the proofs are meant to be read, not taken on faith. recorded at build · source repositories are private

The standard lives in one repository, mgf-standard, together with the contract and the generated registry this page counts from. That repository is not reachable by a stranger, so this page offers no link to it; this page links it the day the repositories are public. In the meantime, see how the bar shapes what exists on the work, and what the gates do and do not establish on proof. recorded at build · source repositories are private