Durable intent in a noisy system

Durable intent needs a reference (and a drift signal)

Insight: Intent stays durable when it is modeled and checked against real behavior.

The cost isn’t philosophical. When intent isn’t clear and reusable—especially across teams and handoffs—decisions slow down and escalations rise. Small changes create surprise side effects because no one can tell which behavior is principle and which is residue.

By intent, I mean a decision you can reuse (a pricing rule, an eligibility rule, an access policy): what must remain true (an invariant), which trade-off it protects, and boundary examples that make “in” vs “out” unambiguous.

To preserve intent, treat it like a small model of the decision (invariant + boundaries), then create a drift signal so you can tell when execution is diverging.

A rule exists, a principle is agreed, and a decision is made—then the real system moves on. Deadlines compress, edge cases appear, and people make local trade-offs to keep work flowing without stopping the business.

If intent lives only in memory and habit, the system doesn’t “remember” the decision; it remembers the workaround that got the work done. Over time, exceptions stop being exceptions and become the implied rule, because they are the easiest thing the system can consistently reproduce. Behavior becomes the shared reference people can reliably point to.

This happens because exceptions accumulate faster than intent is captured, and behavior becomes the easiest reference to reuse.

Drift often starts at the translation boundary: intent becomes a workflow, procedure, screen, or integration. From there, small “reasonable” changes accumulate because there is no durable model to compare against—so the system can only learn from what happened, not what must remain true.

In one minute

• Intent survives when it becomes a referenceable model, not a memory.
• Drift starts after translation, when small changes ship without a conformance check.
• Start by defining one intent model and one drift signal (mismatch + exception trend).

I keep returning to this pattern because I keep encountering systems that “work” while no one can explain why—and where every change feels riskier than it should. That’s usually a sign that behavior has quietly replaced intent as the system’s source of truth.

Where drift shows up in real organizations

Here’s the moment it becomes real: a “temporary” exception is approved to unblock a critical delivery. No one writes down in the ticket or runbook what invariant it violated, what trade-off it accepted, or when it should be reviewed. Three months later, onboarding includes “don’t forget the special case.” The exception spreads to adjacent flows, and any attempt to remove it triggers fear—because no one knows whether it’s protecting a principle or just history.

You see this most clearly in systems that “keep running” while clarity erodes: teams can deliver, but no one can explain why a step exists, which rule it protects, or what it would break if removed. The work moves, but meaning stops being portable.

It shows up as repeated interpretation meetings (“what do we mean by this?”), tickets that exist only to preserve old behavior, and onboarding that depends on tribal knowledge. The system still works—until you try to change something important and discover you don’t know which parts are principle and which parts are accident.

From intent to drift (and back)

Intent is abstract. Systems are concrete. Drift happens in the translation.

To keep intent durable without freezing change, make the mechanism explicit:

• Define intent (model). Capture the invariant and boundary examples in one place.
• Translate intent (surface). Workflows, screens, procedures, integrations, and code implement the model.
• Detect drift (signal). Check behavior against the model and watch exception trends, so drift shows up before it becomes breakage.

This doesn’t mean “no exceptions”. It means exceptions must either fit the model or force an explicit decision to update it.

This pattern is weaker when decision-makers are close to execution and feedback loops are short. It becomes acute as work crosses teams, time horizons, and handoffs.

Signals that execution is redefining intent

Look for signals in meeting notes, ticket patterns, escalation logs, and “how we onboard” artifacts. If the only reliable way to explain the rule is “talk to Maria” or “read the code”, intent has already started to leak.

Interpretation churn. The same rule is explained differently by different teams, and meetings spend more time debating meaning than outcomes. That’s intent living in people, not in a shared reference—and it usually shows up as “alignment” work that produces no new clarity.

Workaround dependency. Delivery depends on someone remembering a “special case” step, a manual flag, or a hidden sequence that isn’t documented anywhere durable. That’s behavior acting as policy, which means your system is being governed by whoever remembers the exception.

Reference gaps. Changes that affect behavior ship without pointing to the intent model (the ledger entry, decision record, or rule definition). That’s drift happening in the dark: the system is evolving, but intent is not being carried forward.

Backlog as alignment. You see tickets whose purpose is “make the system behave like it used to”, without an explicit statement of what must remain true. That’s drift being managed operationally instead of corrected intentionally, and it often consumes capacity that could have prevented the drift in the first place.

Surprise side effects. Small changes trigger unexpected breakage because no one can tell which behaviors are intentional and which are historical residue. When you can’t separate principle from accident, every change carries hidden coupling.

Make intent durable (without freezing change)

Pick one move to try for 1–2 weeks, then review what you learned. Treat it as an experiment: keep it small, make it visible, and tighten it with real cases.

Create an intent model for one decision type

Pick one recurring decision type (pricing rule, eligibility rule, access policy, integration contract) and capture the invariant in one page: what must remain true, which trade-off it protects, and boundary examples that make the edge obvious. Treat this as a model: version it, keep it close to the work, and make changes point back to it.

Start with the single rule that keeps resurfacing in conversations. Watch for fewer “what do we mean?” meetings, and a higher share of tickets/PRs that cite the same reference.

Install a drift check (conformance + exceptions)

Create two lightweight signals for one intent model: a simple conformance check (“does this still match the invariant?”) and an exceptions register (owner + expiry). Require every behavior-changing change to point to the intent model and state whether it preserves the invariant or updates it.

Expect the exceptions register to grow before it shrinks—that’s visibility. Watch whether mismatches are caught earlier (in tickets/PRs) and whether recurring exceptions are being retired or promoted into explicit rules.

Separate “intent” from “execution” in decision forums

In one decision forum you own or facilitate (weekly triage or architecture review), use a two-step pattern: decide the intent first (the invariant), then choose the execution (how you satisfy it this time).

Start by adding one gate question to the agenda—“what must remain true?”—before implementation options are discussed. Then require one outcome: either the intent model is updated, or the exception is logged and time-boxed.

Watch for fewer reopened debates and fewer surprise side effects, because drift is detected earlier instead of surfacing as breakage.

---

Systems lose intent in two ways: by decision, and by drift. Drift is the quiet one—small exceptions redefining what “true” means until change feels risky. When that happens, don’t start by fixing execution—start by asking whether the system still knows what must remain true, and whether that knowledge is durable enough to survive the next wave of pressure.

When in doubt, return to the invariant you are protecting—and decide whether this exception should be retired, time-boxed, or promoted into an explicit rule.

Where in your system has behavior quietly replaced intent—and which exception is shaping the rules today?