I don't document the rules. I make the system refuse to break them.
The line between a senior engineer and someone who thinks they're senior: 'we commit to not doing X' vs 'doing X is technically impossible'. On my projects the critical rules don't live in a wiki - they're enforced by the compiler, the CI, the type or the domain object. Five real examples.
English summary
A documented rule holds until someone forgets it. So the rules that are expensive to break are moved where they can't be forgotten: SaleCast blocks cross-tenant access at compile time; Matchr refuses to deploy an unprofitable plan in CI; Vouch makes an uncited answer impossible to construct in the domain model; OneRP enforces its real-time pattern with Roslyn analyzers; MyRoadTrip makes merge conflicts structurally impossible with a CRDT. The reflex comes from industrial IoT, where you can't patch in prod.
Key takeaways
A promise is not a guarantee; move critical rules into the system.
Compiler, CI, type system and domain invariants outlast human discipline.
Rules encoded this way survive the person who knew them.
Original long-form article
The long technical article is available in French with code, context and detailed examples. The English page gives the recruiter-readable summary and the main engineering points.
Open the French articleNext step
Sounds like something you need shipped? Let's talk.
I take on critical technical work — from scoping to production, no debt or lock-in once it's handed over. Fastest way to see if it fits: a 30-minute call.
I reply within 24h — often sooner.