Engineering standards
This page is here because claims about engineering quality are cheap and the specifics are not. What follows is what the build actually enforces.
Every service runs the same gates, and a change is not complete until all of them pass. There is no reviewer discretion to skip one.
The gates
Section titled “The gates”| Gate | What it catches |
|---|---|
| Vulnerability scan | Known vulnerabilities reachable from our code, not merely present in a dependency |
| Security scan | Injection, hardcoded credentials, unsafe conversions |
| Linting | Style, complexity, error handling, naming |
| Architecture lint | Layer violations and single-responsibility breaches |
| Dependency lint | Import direction between packages |
| Unit tests | Correctness and data races, at 100% coverage per package |
| Mutation testing | Tests that execute code without asserting anything about it |
On top of the per-service gates, an end-to-end suite exercises the running stack across twenty-six scenarios and four services, against real Postgres, real Kafka and mock insurer systems rather than stubs.
Why mutation testing is on that list
Section titled “Why mutation testing is on that list”Coverage says a line ran. It does not say a test would notice if the line were wrong. A suite can reach 100% coverage while asserting almost nothing, and that suite is worse than no suite, because it produces confidence it has not earned.
Mutation testing removes the ambiguity. The tool changes the code deliberately, flipping a comparison or discarding a return value, then runs the tests. If they still pass, the mutation survived, and a test that cannot tell correct code from broken code has been found. The gate requires that none survive.
This is the most expensive gate we run and it is the one we would keep if we could keep only one. In claims and coverage issuance the defects that matter are wrong numbers, not crashes, and a crash is the one kind of defect a weak test suite still catches.
Layers enforced by tooling, not convention
Section titled “Layers enforced by tooling, not convention”Every service has the same internal shape: handlers parse requests and delegate, services hold business logic and declare the interfaces they depend on, repositories talk to external systems, and models hold domain entities. Dependencies point inward only.
Two of the gates exist to enforce that mechanically. Architecture rules that live only in a document decay, because a rule nobody can breach accidentally is a rule nobody has to think about, and the reverse is also true. Making the layering a build failure is what keeps the codebase legible after the people who designed it have moved on.
What the gates do not cover
Section titled “What the gates do not cover”They are about the code. They say nothing about whether the product is right, whether a market profile matches its regulator, or whether an insurer integration reflects what that insurer actually does. Those failures are found by the people doing the work and by the counterparty, not by a linter.
Conformance to the open standard is a separate question again, and it is graded rather than binary. What each level covers, how a claim is stated, and the artefacts that make a level checkable are set out under Conformance. The same rules apply to claims we make about our own implementation, which is the point of writing them down in a document we do not control the reading of.