TigerStyle (Dedalus)

TigerBeetle-derived coding style used in Dedalus systems code: design for safety, then performance, then developer experience - in that order, with zero technical debt and assertion-heavy design.

Adapted from TigerBeetle's "TigerStyle," this is the discipline for the highest-stakes Dedalus code (hypervisor, storage, billing, control plane). Style here is a means to an end - safety, performance, DX - not readability for its own sake. Source: dedalus-api/TIGER_STYLE.md § Why Have Style

The ordering: safety > performance > DX

All three matter, but they are ranked. A change is evaluated by whether it advances safety first, then performance, then developer experience. Simplicity is not a concession - it is how the goals come together into one "super idea," and it is the hardest revision, not the first attempt. Source: dedalus-api/TIGER_STYLE.md § On Simplicity And Elegance

Safety (NASA Power of Ten lineage)

• No recursion, bounded loops, static allocation. Control memory and time up front; no unbounded growth. Source: TIGER_STYLE.md § Safety
• Assertions everywhere. At least two assertions per function. Pair assertions across read/write paths, and assert both the positive space (what must be true) and the negative space (what must never happen). Source: TIGER_STYLE.md § Safety
• Explicit options at call sites. Never rely on a library's defaults; pass the options explicitly so behavior is visible where it is invoked. Source: TIGER_STYLE.md § Safety
• Hard 70-line function limit. A function that grows past ~70 lines is doing too much. Source: TIGER_STYLE.md § Safety/Performance

Performance and control flow

• Push ifs up, push fors down. Hoist branching toward callers; push iteration down into tight inner routines. Centralize control flow rather than scattering it. Source: TIGER_STYLE.md § Performance
• Spend the design budget early: an hour or a day of design is worth weeks of production, because simple systems are faster to get right and cheaper to operate. Source: TIGER_STYLE.md § On Simplicity And Elegance

Zero technical debt

Fix showstoppers in the design phase, not in production. The policy is to not accumulate debt: think hard upfront so implementation, testing, and operation are dwarfed by the quality of the design. This pairs with the Edict's distinction between technical and cognitive debt. Source: TIGER_STYLE.md § Technical Debt

Relationship to other Dedalus style docs

TigerStyle governs systems/Rust code where safety dominates; the Dedalus Edict governs interpretability and interface design across the polyglot monorepo; the Dedalus Style Guide covers the broader hard-limits/IO conventions. Together they form the Dedalus correctness stack.

Applicability

Proof

TigerStyle work needs proof of boundedness, invariants, and failure posture. At minimum, name the bounded loop or allocation decision, show the paired assertions or equivalent invariant checks, and verify with the smallest test that can fail if the invariant is wrong.

Style Rule Contract

This page follows Style Rule Contract: name the default pattern, banned pattern, reason, exception, proof, and codification path clearly enough that the next agent can apply the rule without asking Kevin again. If a local repo has a stricter rule, follow the local rule and update the wiki when the decision becomes durable.

---

Timeline

• 2026-07-01 | Aligned this page with Style Rule Contract so style guidance names default behavior, banned patterns, exceptions, proof, and codification expectations. Source: User request, 2026-07-01
• 2026-07-01 | Added applicability and proof sections so TigerStyle is reserved for safety-critical systems paths and paired with boundedness and invariant evidence. Source: User request, 2026-07-01
• 2026-05-31 | Page created from dedalus-api/TIGER_STYLE.md. Captured the safety>performance>DX ordering, NASA Power-of-Ten safety rules, assertion pairing, 70-line limit, and zero-technical-debt policy. Source: dedalus-api/TIGER_STYLE.md, 2026-05-31