Impossibility-Theorem Instantiation Review¶

Analytical review — instantiates Incompatible Requirement Set Resolution

Checks whether the requirement set is a disguised instance of an already-proven impossibility theorem, so a known "you cannot have all of these at once" result settles the conflict without a fresh search.

Some requirement sets are not merely infeasible under your current model — they are infeasible under every model, because a general theorem has already proved that this particular combination can never coexist. Impossibility-Theorem Instantiation Review checks for exactly that: it asks whether your commitments, once formalized, match the hypotheses of a known impossibility result (Arrow's theorem, CAP, FLP, Gibbard–Satterthwaite, Rice's theorem, the no-free-lunch theorems, and their kin). Its defining move is to borrow a proof instead of running a search: where a solver would prove your one instance infeasible — a verdict that could still be an artifact of your encoding — a matched theorem proves the impossibility is fundamental, holding for any design in scope, and, just as valuable, names the only legitimate exits: violate one of the theorem's stated preconditions.

Example¶

A product spec for a distributed data store demands all three of: every read returns the most recent write (strong consistency), the service always responds even while parts of the network are cut off (availability), and it keeps working through those network partitions (partition tolerance). A team could burn a quarter trying to engineer this. The review instead formalizes each requirement — "read returns latest write" becomes linearizability, "always responds under a partition" becomes availability during partition — and recognizes the trio as an instance of the CAP theorem: no partition-tolerant distributed store can be both linearizable and available during a partition. That settles it by instantiation, no solver required. The review's deliverable is not just "impossible" but the enumerated exits — relax to eventual consistency, or accept unavailability during partitions, or (rarely legitimate) assume partitions cannot occur — plus a recheck trigger: if the "always available under partition" requirement is later dropped, or the system is scoped to a single failure domain where partitions don't arise, CAP no longer bites and this verdict must be reopened.^[1]

How it works¶

The review is recognition and mapping, not computation. First, formalize each commitment into the vocabulary of a candidate theorem — its agents, its predicates, its objects — and fix the scope over which impossibility is being claimed. Second, verify that the theorem's preconditions actually hold in your setting (CAP assumes an asynchronous network in which partitions can happen; Arrow assumes three or more alternatives and its fairness axioms). Third, if the mapping fits and the preconditions hold, cite the theorem as the certificate that the set is impossible. Fourth, read the exits straight off the theorem: each precondition or axiom the proof relies on is a candidate to relax. What distinguishes this from the solver siblings is that the impossibility it returns is general — established for the whole class of designs — and it comes almost for free, because someone already did the hard proof.

Tuning parameters¶

Theorem-library breadth — how many canonical impossibilities you screen against. Broader coverage catches more genuine instances but tempts loose, forced analogies.
Mapping strictness — how rigorously commitments must match the theorem's formal predicates. Loose mapping invites "oh, that's just CAP" dismissals of solvable problems; over-strict mapping misses real instances hiding behind different wording.
Scope of the claim — the theorem's assumptions define the region over which impossibility holds; deliberately narrowing scope (a single region, a bounded alternative set) can move the problem outside the theorem.
Precondition sensitivity — which assumptions the verdict rests on most delicately, and therefore which changes would dissolve the impossibility. These become the recheck triggers.

When it helps, and when it misleads¶

Its strength is decisiveness at almost no cost when it applies: it stops a team from trying to out-engineer a mathematical wall, delivers a general and bulletproof certificate, and points straight at the legitimate exits — the theorem's own preconditions.

Its signature failure is the forced analogy: invoking a famous impossibility ("that's basically Arrow's theorem") as a rhetorical trump card to shut down a problem whose requirements don't actually meet the theorem's hypotheses. The inverse error is just as real — a precondition may not hold in your setting, so the theorem doesn't apply and giving up is a mistake (the perennial misreading that CAP forces you to abandon consistency at all times, when it constrains only behavior during a partition). The discipline that guards both flanks is to verify the hypotheses literally before invoking the result, record those hypotheses as the assumptions the verdict depends on, and emit recheck triggers so a later change in scope or assumption forces the "impossible" ruling to be revisited rather than treated as permanent.

How it implements the components¶

Impossibility-Theorem Instantiation Review fills the formalize-and-scope side of the archetype — establishing whether the incompatibility is fundamental and under what conditions:

commitment_semantics_and_scope — its core labour is translating each commitment into a theorem's formal predicates and fixing the scope over which the impossibility is asserted.
assumption_register — the theorem bites only under its stated preconditions, so the review records exactly those assumptions as the ground the verdict stands on.
recheck_trigger — because the only escape from a proven impossibility is to change a precondition, the review emits triggers ("if assumption A is relaxed or the scope narrows below X, reopen this").

It does not build or solve a formal model of your specific instance (joint_satisfiability_model, feasible_set — that's SAT/SMT Satisfiability Check) or record the chosen resolution and its residual guarantees (decision_record, residual_guarantee_ledger — that's Decision Record with Residue); it establishes whether the impossibility is fundamental and names the exits.

Instantiates: Incompatible Requirement Set Resolution — supplies a general, theory-backed verdict that the conflict is fundamental, and names the only precondition-relaxing exits.
Sibling mechanisms: SAT/SMT Satisfiability Check · Minimal Unsatisfiable Core Extraction · Weighted MaxSAT or Soft-Constraint Optimization · Stakeholder Frontier Review · Proof Checking · Constraint-Satisfaction Solver Pass · Compatibility Matrix · Requirements Traceability Matrix · Constraint Relaxation Experiment · Pareto Frontier Analysis · Scenario Sensitivity Sweep · Scope-Boundary Stress Test · Decision Record with Residue

Notes¶

An impossibility theorem constrains the option set but does not choose the exit. It proves that all commitments cannot hold together and lists the preconditions available to relax; deciding which one yields — under whose authority, and at what cost — remains a governance judgment handed to Stakeholder Frontier Review. This is the archetype's proof-versus-governance split at its sharpest: the proof is general and non-negotiable, the choice among exits is not.

References¶

[1] The CAP theorem states that a distributed data store cannot simultaneously guarantee consistency (linearizability), availability, and partition tolerance; formally, during a network partition a system must sacrifice either consistency or availability. It is frequently misread as an always-on trade-off — but it constrains behavior only during a partition, and does not apply at all if partitions cannot occur in the system's scope. ↩