When Constructs Disagree

The Security Auditor says: “This deploy contains an unpatched dependency with a known CVE. Block it.”

The Ship construct says: “Tests pass. Changelog updated. PR approved. Ready to merge and deploy.”

The CEO Reviewer says: “We committed to the customer that this would be live by Friday. It is Thursday.”

Three constructs, each operating correctly within its domain. Each reaching a different conclusion about what should happen next. This is not a bug in the system. It is the system working as designed — and it surfaces a problem that every organization faces but rarely makes explicit.

The Nature of the Disagreement

Construct conflicts are not technical bugs. They are value conflicts. The Security Auditor values safety. The Ship construct values velocity. The CEO Reviewer values commitments. None of them is wrong. They are optimizing for different things.

In a human organization, these conflicts happen in meetings. Someone says “we can't ship with this vulnerability.” Someone else says “the customer is waiting.” A decision-maker weighs the risks and makes a call. The call is not algorithmic. It depends on how severe the vulnerability is, how important the customer is, how much trust is at stake, and half a dozen other factors that are not in any playbook.

When constructs disagree, the same judgment is needed. But there is no meeting. There is no decision-maker in the loop — unless someone designed the system to surface the conflict instead of silently resolving it.

Silent Resolution Is Dangerous

The worst outcome is when conflicts are resolved silently. If the system simply runs both constructs and the last one wins, the outcome depends on execution order — an implementation detail that should never determine business decisions. Did the deploy go out with the vulnerability? It depends on whether the Security Auditor ran before or after the Ship construct.

This is not a hypothetical. In any system with multiple constructs operating on the same artifact, silent conflict resolution is the default. The system does not know the constructs disagree. It executes each one, and each one does what it was told.

The solution is explicit surfacing. When constructs produce contradictory recommendations, the system should stop and present the conflict to a human. Not “the Security Auditor found an issue” — but “the Security Auditor recommends blocking this deploy, the Ship construct says it is ready, and the CEO Reviewer notes a customer deadline. Here are the details. What do you want to do?”

Conflict Patterns

Not all disagreements are the same. Understanding the type of conflict determines how to resolve it.

Safety vs. speed. The most common conflict. One construct says stop, another says go. Resolution: safety should win by default, with an explicit human override required to proceed despite the safety concern. The override should be logged. This mirrors how aviation works — the pilot can override the stall warning, but the black box records that they did.

Quality vs. scope. The Design Auditor says the spacing is wrong. The Ship construct says the feature is complete. Resolution: this depends on the severity of the design issue. A misaligned button can ship. A broken accessibility pattern cannot. The construct system needs a way to distinguish “should fix eventually” from “must fix now.”

Consistency vs. pragmatism. The Code Reviewer says “this pattern is inconsistent with the rest of the codebase.” The Debugger says “this pattern works and fixes the production issue.” Resolution: during an incident, pragmatism wins. The consistency can be addressed in a follow-up. But the follow-up must actually happen — and that is a different construct's job to track.

Cost vs. thoroughness. Running every construct on every artifact costs money. The QA Engineer wants to run exhaustive tests. The budget says run the smoke tests. Resolution: this is a resource allocation problem that should be decided at the organizational level, not by individual constructs. A “resource policy” construct sets the budget. Individual constructs operate within it.

Designing for Disagreement

The best construct systems are designed with the expectation that constructs will disagree. This means:

Every construct should output confidence and severity. Not just “block the deploy” but “block the deploy (P0, high confidence).” This gives the system information to triage conflicts. A P0 from the Security Auditor overrides a P2 from the Design Auditor without human intervention.

Conflicts should be surfaced, not suppressed. A dashboard, notification, or inline comment that says “these two constructs disagree” is worth more than a system that silently picks a winner.

Resolution precedents should be recorded. When a human resolves a conflict — “ship despite the vulnerability because the CVE only affects a feature we have not launched” — that decision should be recorded as a precedent. Over time, these precedents become a governance construct: the organizational memory of how conflicts are resolved.

This is, in the end, a governance problem. Not a technical one. The technology for detecting and surfacing conflicts is straightforward. The hard part is defining the values that determine resolution. And that is, irreducibly, a human decision.

Related: The Conductor Problem explores who decides which constructs activate. The Soul Stack covers how layers compose and when they conflict.