Martin Gamsjaeger's wroclove.rb 2019 talk setting the stage for Markus Schirp's Mutant talk that follows. Presents the axiom-driven development process used by a small fully-remote team that communicates only in writing (no standups, no video). Motivation: minimize bugs, minimize downtime, minimize time spent thinking about simple things, learn as a team every day, share responsibility, satisfy clients. Defines vocabulary: axiom (universally-accepted truth), assumption (derived from axioms), transformation (any commit-level update to system artifacts), regression (anything putting the system in a worse state, not just a bug), atomic (cannot be made smaller), check (tests = automated checks, reviews = manual checks, flag = failed manual check). Core axioms: clients hate bugs; clients love progress; redundant semantics provide no value (the master axiom everything boils down to); inconsistency provides no value; human attention varies over time; automation reduces need for human attention; required semantics change over time; tools aren't perfect but we can imagine a perfect one (so reviewers should flag everything a perfect tool would flag); you can never fully know the client's required semantics; your mental model of the project is probably wrong. Derived assumptions: well-defined process increases team performance; automated checks preferred over reviews; push constraints down as deep as possible (into the DB with check constraints, constraint triggers); reject invalid input as early as possible; never self-censor on reviews. Introduces five commit transformations with a guideline priority order: remove, fix, refactor, change, add — plus synonyms (move, rename, upgrade, downgrade). Commit messages must start with one of these verbs or CI rejects them. Priority is a guideline tie-broken by functional dependencies; refactorings are the only lookahead transformation (justified by enabling the next transformation). Enforced constraints: redundant semantics must be eliminated; test coverage must not regress; known bugs take priority; every commit must be an improvement, atomic, pass all checks, and be independently deployable (continuous deployment, zero downtime on merge); every deploy must be reviewer-approved; everything a perfect tool would flag must be flagged; no 'just in case' code. Q&A covers move vs refactoring, the years-long evolution of the process with Markus Schirp and team leader Dan Kubb, and distinguishing fix/change from remove/add under the atomic-commit discipline.