Safety-Critical Coding Patterns
Guidelines adapted from NASA's Power of 10 rules for safety-critical software.
When to Apply
Full rigor: Safety-critical systems, financial transactions, data integrity code
Selective application: Business logic, API handlers, core algorithms
Light touch: Scripts, prototypes, non-critical utilities
"Match rigor to consequence" - The real engineering principle
When NOT To Use
- Ordinary application code, where these defensive checks become the
bloat that
prefer-invariants-over-fallbacks targets (use
conserve:code-quality-principles)
The 10 Rules (Adapted)
1. Restrict Control Flow
Avoid goto, setjmp/longjmp, and limit recursion.
Why: Ensures acyclic call graphs that tools can verify.
Adaptation: Recursion acceptable with provable termination (tail recursion, bounded depth).
2. Fixed Loop Bounds
All loops should have verifiable upper bounds.
for i in range(min(len(items), MAX_ITEMS)):
process(item)
while not_done:
process_next()
Adaptation: Document expected bounds; add safety limits on potentially unbounded loops.
3. No Dynamic Memory After Initialization
Avoid heap allocation in critical paths after startup.
Why: Prevents allocation failures at runtime.
Adaptation: Pre-allocate pools; use object reuse patterns in hot paths.
4. Function Length ~60 Lines
Functions should fit on one screen/page.
Why: Cognitive limits on comprehension remain valid.
Adaptation: Flexible for declarative code; strict for complex logic.
5. Assertion Density
Include defensive assertions documenting expectations.
def transfer_funds(from_acct, to_acct, amount):
assert from_acct != to_acct, "Cannot transfer to same account"
assert amount > 0, "Transfer amount must be positive"
assert from_acct.balance >= amount, "Insufficient funds"
Adaptation: Focus on boundary conditions and invariants, not arbitrary quotas.
6. Minimal Variable Scope
Declare variables at narrowest possible scope.
for item in items:
total = calculate(item)
results.append(total)
total = 0
for item in items:
total = calculate(item)
results.append(total)
7. Check Return Values and Parameters
Validate inputs; never ignore return values.
result = parse_config(path)
if result is None:
raise ConfigError(f"Failed to parse {path}")
parse_config(path)
8. Limited Preprocessor/Metaprogramming
Restrict macros, decorators, and code generation.
Why: Makes static analysis possible.
Adaptation: Document metaprogramming thoroughly; prefer explicit over magic.
9. Pointer/Reference Discipline
Limit indirection levels; be explicit about ownership.
Adaptation: Use type hints, avoid deep nesting of optionals, prefer immutable data.
10. Enable All Warnings
Compile/lint with strictest settings from day one.
ruff check --select=ALL
mypy --strict
tsc --strict --noImplicitAny
Rules That May Not Apply
| Rule | When to Relax |
|---|
| No recursion | Tree traversal, parser combinators with bounded depth |
| No dynamic memory | GC languages, short-lived processes |
| 60-line functions | Declarative configs, state machines |
| No function pointers | Callbacks, event handlers, strategies |
Integration
Reference this skill from:
pensive:code-refinement - Clean code and quality dimensionsanctum:pr-review - Code quality phase/harden - composed in the hardening pipeline/full-review safety-critical - focused entry point, and an
auto-detection row when assertion density is low, loops are
unbounded, or recursion lacks a termination proof
Violation Output Format
For each rule violation, report:
Rule N: <rule name>
Location: file.py:42
Anchor: `<verbatim source text at line 42>`
Issue: <what violates the rule>
Fix: <concrete remediation>
Verify Findings Are Grounded (safety-critical:findings-verified)
Every finding must cite a real location and a verbatim anchor. Write
findings to .review/findings.json and confirm each citation resolves:
python plugins/imbue/scripts/citation_verifier.py \
--findings .review/findings.json --repo-root .
Drop or label UNVERIFIED any finding the verifier fails (exit 1); only
verified findings enter the report. See Skill(imbue:review-core) Step 5
and Skill(imbue:structured-output) for the schema.
Exit Criteria
Sources
- NASA JPL Power of 10 Rules (Gerard Holzmann, 2006)
- MISRA C Guidelines
- HN discussion insights on practical application
