What engineering coherence means

Engineering coherence is the extent to which independently executed software changes remain consistent with the technical decisions, boundaries, constraints and assumptions that govern a system.

The key word is independently. One engineer working alone keeps a system coherent almost by default, because one person holds the decisions in their head. Coherence becomes a problem when work splits. Two teams, ten engineers or fifty coding-agent sessions each make changes that are correct from where they sit. The question is whether those changes still add up to one system.

Coherence is a property of the system, not of a single change. You cannot read it off one pull request. A change that adds a direct database call from an API handler may be fine in isolation. It is incoherent if the team decided that handlers go through a service layer, and the next five changes copy it.

What has to stay coherent

Coherence is about the decisions that shape a system, not about code style. Formatting, naming and lint rules matter, but tools already handle them well. The things that have to stay coherent are the ones that are expensive to reverse:

  • Boundaries: which service or module owns which responsibility.
  • Dependency direction: which layers may depend on which.
  • Ownership: which team or component is the source of truth for a piece of data or behavior.
  • Interfaces and contracts: the shapes other code relies on.
  • Data access: which paths may read or write which stores.
  • Security constraints: where secrets, authentication and untrusted input may flow.
  • Approved patterns and technologies: the libraries and approaches the team chose, and the ones it ruled out.
  • Lifecycle state: which decisions are current and which were replaced.
  • Exceptions: the places a rule deliberately does not apply.

How coherence breaks

Coherence rarely breaks through one bad change. It breaks through a sequence. A team shares intent. Over time the context behind that intent fragments: some decisions live in architecture decision records (ADRs), some in a wiki, some in a thread, some only in a senior engineer's memory. Work then runs independently, and each executor (an engineer or an agent session) follows the part of the context it happened to see. The result is divergent implementation.

How engineering coherence breaks Four stages from left to right. Shared intent: the team agrees on decisions. Fragmented context: each executor sees only part of them. Independent execution: many changes are made in parallel. Divergent implementation: each change is locally correct, and together they no longer match the decisions. HOW COHERENCE BREAKS 1 · SHARED INTENT The team agrees on decisions 2 · FRAGMENTED Each executor sees part of them 3 · INDEPENDENT Changes happen in parallel 4 · DIVERGENT Locally correct, globally divergent AI lowers the cost of step 3, so the whole sequence runs faster
Coherence breaks in four steps. No step needs a mistake. Each executor acts correctly on the context it has, and the system still diverges from what the team decided.

AI coding agents do not invent this pattern. They speed it up. An agent lowers the cost of independent execution, so a team can run more of it in parallel. Each session starts without the conversations that shaped the system. If the decisions are not available to that session, it fills the gap with whatever looks reasonable in the code nearby. That is often an older pattern the team meant to retire.

Five dimensions of coherence

It helps to split coherence into five dimensions, because each one fails differently:

  • Decision coherence: changes follow the same decisions, not competing versions of them.
  • Context coherence: every executor receives the decisions that apply to its work, not a random subset.
  • Structural coherence: boundaries, ownership and dependency direction hold as the code grows.
  • Temporal coherence: changes follow the current decisions, not ones that were superseded.
  • Execution coherence: the same decision produces the same outcome in every place work happens, from an editor session to a pull request check.

A team can be strong on one dimension and weak on another. A well-kept ADR folder helps decision coherence. It does nothing for context coherence if agents never read it.

How it relates to other concepts

  • Architectural drift is the degradation of coherence over time. Drift is what you measure once coherence has been lost and the losses have become precedent.
  • Architectural conformance checks whether code matches an intended architecture. It is one way to test coherence, not the whole of it. Conformance tells you about structure at one moment; coherence also covers context, lifecycle and the consistency of outcomes.
  • Shared mental models are how human teams kept coherence for decades: people who had been in the room carried the decisions. That works for a team of ten. It does not scale to many agents that start every session with no memory of the room.
  • Engineering decision governance is the mechanism that keeps independently executed changes on the same decisions. Coherence is the outcome; decision governance is how a team protects it.
  • Decision continuity keeps decisions available across sessions and handoffs, which is the precondition for context coherence.

What preserves coherence

Coherence holds when a decision can travel from the conversation where it was made to the change where it applies. The chain has six links:

  1. Conversation: the team makes a decision.
  2. Documentation: someone writes it down with its reasoning.
  3. Addressable decisions: the decision gets an identity, a scope and a lifecycle, so a tool can refer to it.
  4. Contextual retrieval: the decisions that apply to a task reach the person or agent doing it.
  5. Deterministic enforcement: where a decision can be expressed as a rule, a check applies it the same way every time.
  6. Evidence: the result records which decision was applied and what happened.

Most teams have the first two links. The chain usually breaks at the third, because a document is not an addressable decision. Without that link, retrieval returns text that may be out of date, and enforcement has nothing stable to point at.

What engineering coherence is not

  • Not code consistency. Two services can use different formatting and still be coherent.
  • Not architectural purity. A coherent system can carry deliberate exceptions, as long as they are decided and recorded.
  • Not identical choices. Teams can choose differently where the decisions allow it.
  • Not removing autonomy. The goal is that independent work lands on the same decisions, not that every change is centrally approved.
  • Not organizational alignment in general. Coherence here is about technical decisions in a software system.
  • Not generic AI governance. Model risk and acceptable-use policy are separate concerns.

Where Mneme fits

Mneme, the product this site describes, does not create coherence. Teams do, by making decisions and keeping them current. Mneme's part is narrower. For architectural decisions in a repository, it keeps a versioned record of the decisions, retrieves the decisions most relevant to a task for the agent doing it, and deterministically enforces the constraints that can be encoded as rules on supported surfaces, such as coding-agent hooks and CI checks. That covers links three to five of the chain for one class of decision, and part of the sixth: each check result names the decision and rule behind a violation, but the current release keeps no durable evidence record. How decisions are modeled is described in the decision model.