Jaco van der Laan

When Rules Need Exceptions — How MDDE Handles Reality Without Losing Discipline

11/02/2026  ·  Data Engineering  ·  SQL Rules for Data Transformation

‹ ›

Strong architectures need rules. But real systems need exceptions.

When Rules Need Exceptions — How MDDE Handles Reality Without Losing Discipline

Strong architectures need rules. But real systems need exceptions.

If an architectural approach cannot deal with exceptions explicitly, they will still happen — just invisibly, inconsistently, and without learning.

This article explains how MDDE treats exceptions as first-class architectural signals , not failures of discipline.

The danger of pretending exceptions don’t exist

Many architectures fail in one of two ways:

  1. Rules are enforced too weakly
    → everything becomes “best effort”
  2. Rules are enforced too rigidly
    → teams work around them quietly

Both lead to the same outcome: architectural drift — either visible or hidden.

MDDE takes a different position:

Exceptions are inevitable.
What matters is whether they are explicit, reviewable, and learnable .

A rule is a hypothesis, not a law of nature

In MDDE, every rule encodes a hypothesis:

“Under normal circumstances, this constraint improves correctness, safety, or clarity.”

Rules are not moral judgments.
They are accumulated experience, frozen temporarily into code.

That framing matters — because it makes it possible to revisit them without undermining authority.

Three kinds of exceptions

Not all exceptions are equal. MDDE distinguishes between three types.

1. Contextual exceptions

The rule is generally valid, but the context is unusual.

Examples:

  • Performance-critical queries
  • Platform-specific optimizations
  • Transitional migration phases

MDDE approach
Allow the exception, but require:

  • Explicit annotation
  • Local scope

  • Clear justification

    exceptions:
    no_select_star:
    reason: “Wide table, performance-critical path”
    expires: “2025-06-01”

Temporary exceptions should age out by default.

2. Structural exceptions

The rule does not apply to a specific class of workloads.

Examples:

  • Exploratory analytics
  • Ad-hoc investigations
  • One-off experiments

MDDE approach
Move the workload outside the rule’s scope instead of weakening the rule.

This keeps the invariant strong where it matters.

3. Architectural exceptions

The exception reveals that the rule itself is incomplete or wrong.

These are the most valuable ones.

Examples:

  • A rule blocks a legitimate pattern
  • Repeated overrides occur
  • Validation shows false positives

MDDE approach
Trigger a review:

  • Why does this keep happening?
  • What assumption no longer holds?
  • Should the rule change?

Often, this leads to a new ADR.

How exceptions are implemented in practice

In MDDE, exceptions are never silent.

They are:

  • Explicit
  • Typed
  • Observable

Example rule evaluation:

{  
  "rule": "NoSelectStar",  
  "status": "overridden",  
  "reason": "Performance-critical aggregation",  
  "scope": "entity.sales_summary"  
}

This turns exceptions into data — not tribal knowledge.

Exceptions should create feedback, not entropy

The key principle is this:

Every exception must teach the architecture something.

If exceptions accumulate without reflection:

  • Rules become meaningless
  • Architecture stops evolving

If exceptions are reviewed periodically:

  • Rules improve
  • Scope becomes clearer
  • Modeling boundaries sharpen

This is how MDDE avoids rigidity without sliding into chaos.

When not to apply MDDE rules at all

Equally important is knowing when not to apply MDDE.

MDDE is a poor fit for:

  • Exploratory notebooks
  • Early hypothesis testing
  • Short-lived analysis
  • Highly creative, one-off work

Trying to enforce invariants too early kills learning.

MDDE works best after patterns stabilize , when consistency and comparability matter more than speed.

Discipline comes from clarity, not force

The goal of executable rules is not control.

It is clarity:

  • Clarity about what matters
  • Clarity about why
  • Clarity about when it’s okay to diverge

When teams understand why a rule exists, exceptions become rare — and meaningful when they occur.

Architecture that learns

MDDE treats architecture as a learning system.

Rules create stability.
Exceptions create insight.
ADRs capture the evolution.

That loop is what keeps architecture alive under real-world pressure.

Closing

An architecture without rules drifts.
An architecture without exceptions breaks.

MDDE works by holding both:

  • Strong defaults
  • Explicit deviation

Not pretending reality is simpler than it is —
but refusing to let complexity remain implicit.

What’s next

In the next articles, I’ll explore:

  • How rules evolve over time
  • Warning vs blocking rules in CI
  • Versioning architectural decisions
  • How to retire rules safely

All continuing the same theme: architecture that stays disciplined and adaptive.