Prioritise prevention and early detection over reactive fixes

What this means in practice

We design and build to stop classes of problems from happening in the first place. We prioritise clear contracts, type safety, and compliance checks that fail early. We avoid relying on assumptions that only become visible once a change is in production.

Why this matters

Preventative controls reduce rework, incidents, and costly investigation. They make delivery more predictable. They also make systems easier to change safely because teams can trust the feedback they get during development and delivery.

Practices that meet this principle

• Use TypeScript and enforce type safety as part of the build

• Define and validate contracts at boundaries, including APIs and events

• Add compliance checks and guardrails in CI so failures happen before merge and release

• Make assumptions explicit in code and documentation, and remove them when they stop being true

Validation

A change meets this principle when:

• Contracts are explicit and checked (types, schemas, or tests)

• Compliance and quality checks run automatically before release

• Failures are surfaced early enough to prevent downstream rework

• There is evidence the approach reduces repeat defects or avoids known incident patterns