Engineering Decision Governance

What engineering decision governance means

Engineering decision governance is the system that determines which engineering decisions govern a given change, why, and with what evidence.

Every software team makes technical decisions: use PostgreSQL for transactional data, keep the payments service behind its API, do not add a new HTTP client library. Most teams record some of them. Far fewer can answer, for a specific change, which of those decisions apply to it. Fewer still can show afterwards that the change respected them.

Decision governance closes that gap. It treats a decision as something with authority over certain work, for a certain period, with a known relationship to other decisions. The same model should serve every party that changes the system: engineers, coding agents, continuous integration (CI) checks and automated pipelines.

Why decision records are not enough

Architecture decision records (ADRs) solved a real problem. They capture the context and reasoning behind a choice, often in the repository, next to the code. But a record is a document. On its own it answers none of the operational questions:

• Is this decision still in force, or did a later one replace it?
• Which parts of the system does it cover, and which does it deliberately exclude?
• If two decisions both cover a file and disagree, which one wins?
• Can anyone check a change against it without reading prose?
• After the change lands, what shows the decision was applied?

Search does not answer these questions either. Finding a document that mentions PostgreSQL is not the same as knowing that an accepted, current decision requires PostgreSQL for this service. Humans bridge that gap with judgment and hallway conversations. A coding agent that starts each session fresh cannot. It will follow whatever text it retrieves, including a decision the team superseded last quarter.

Anatomy of a governed decision

A decision becomes governable when it carries more than a statement. The properties below are what a governance system needs to reason about it:

• Identity: a stable way to refer to the decision and each version of it.
• Statement: what was decided, in plain words.
• Scope: the part of the system the decision is about.
• Applicability: the work it governs, which can be narrower than its scope.
• Authority: who or what process accepted it, and who can change it.
• Provenance: where it came from, such as a specific ADR file and version.
• Lifecycle: whether it is active, superseded, deprecated or inactive.
• Precedence: how it ranks against other decisions that cover the same work.
• Exceptions: places it deliberately does not apply.
• Enforcement potential: whether part of it can be expressed as a rule a machine can check. Some decisions yield several rules. Some yield none and stay as guidance.
• Evidence: a record of which decision was applied to which change, and with what result.

The questions decision governance answers

Put the properties together and a governance system can answer six questions about any change:

1. Which decisions are in force right now?
2. Which of them govern this change?
3. When two of them conflict, which one wins, and why?
4. Who can change a decision, and how is the change recorded?
5. Which parts can be checked automatically, and which need a human?
6. What shows, afterwards, that the right decisions were applied?

Mneme's own design work narrows this to three questions that must have deterministic answers. They are recorded in ADR-031, Decision Governance Semantics, an accepted design decision in Mneme's open-source repository:

• Effective resolution: given the current state of the decisions and a context, which decisions govern it, which do not, and why.
• Governance change: between two states, which decisions in force changed, and which scope and rules are affected.
• Evidence identity: for a given outcome, which exact decision version and rule produced it.

ADR-031 is accepted and in progress. It is not in a released version of Mneme yet, so read these three as the design direction, not as shipped behavior. The rule it sets is the important part: no answer may depend on a retrieval score, a model's output, file order or the clock. Where the state is ambiguous, the answer says so instead of guessing.

Why decisions become the scarce asset

As AI lowers the cost of writing code, the code itself becomes easier to replace. What stays expensive is knowing what the right implementation is: the constraints, trade-offs and past failures behind the current design. That context lives in decisions. A team that can regenerate a service in an afternoon still needs to know which database it must use and which boundary it must not cross.

Two Mneme insights make this argument in full. AI Makes Software More Ambitious shows how cheaper implementation shifts the hard problem to keeping changes coherent. The AI ROI problem is about systems, not models makes the same point from the return-on-investment side. Decision governance keeps that asset current, so teams do not have to rediscover it.

How it differs from adjacent concepts

One model for humans, agents and pipelines

Decision governance only works if every party that changes the system reads the same decisions with the same rules. If an engineer's editor, a coding agent and a CI check each interpret the decisions their own way, they will reach different verdicts on the same change. The governance model has to sit outside any one tool, so that a decision means the same thing wherever work happens.

How it relates to other concepts

• Engineering coherence is the outcome decision governance protects: independent changes that still add up to one system.
• Precedence semantics are the part of decision governance that decides which of two overlapping decisions wins.
• Decision continuity keeps decisions available across sessions and handoffs, so governance has something to act on.
• Deterministic enforcement is how the encodable part of a decision is applied: the same input gives the same verdict every time.

Where Mneme fits

Mneme applies decision governance to one class of decision: architectural decisions in a repository. Since mneme-hq 0.10.0, the current release of Mneme's open-source package, the Decision Index is the persisted, versioned record of those decisions. It stores immutable versions, an explicit active version, lifecycle status, supersession links (a record that one decision replaced another) and, where known, the source of each version.

In 0.10.0, when two accepted ADRs share exactly the same scope, explicit supersession, then priority, then date decide which stays active; broader and narrower scopes coexist. See precedence semantics for the detail. An unreleased change under ADR-031 removes the date step. Mneme's checks enforce the rules that can be encoded on supported surfaces, and each violation names the decision and rule that triggered it. Until a release ships ADR-031, the three questions above are the plan, not the product.