Skip to content

Computability Boundary Decision Record

Decision record — instantiates Computability Boundary Mapping

Records where a project drew the computability boundary, which guarantee it will ship, and what would force the line to be redrawn.

A boundary decision that lives only in someone's head gets re-litigated every six months and drifts silently when the world changes. Computability Boundary Decision Record proves nothing and analyzes nothing; it is the durable, citable ledger that records where a team drew the line between what it will solve exactly, what it will restrict, and what it declines to attempt — together with the guarantee it will actually ship and the assumptions that decision rests on. Its defining role is memory and provenance: it turns a hard-won conclusion into an artifact that survives staff turnover and can be reopened deliberately, on a stated trigger, rather than reopened by accident or ignored until it rots.

Example

A team building a "universal configuration linter" concludes — from the impossibility and complexity work — that full semantic validation of their language is undecidable, so they will ship a sound, bounded checker instead. They write a decision record: the declared problem class, the impossibility result relied on, the guarantee shipped ("flags every violation within nesting depth 8; may over-report; makes no claim beyond depth 8"), the assumptions it depends on, and the trigger that would reopen the whole question — if the config language ever gains general recursion. Nine months later a new engineer proposes "let's just make it complete." The record answers in one page: here is why that is impossible, here is what we ship instead, and here is the exact change to the language that would make the question worth reopening.

How it works

The mechanism captures a decision plus its provenance and its expiry conditions, not a derivation. It states which side of the boundary the project chose and why; links out to the constructive proof, impossibility certificate, and complexity analysis rather than restating them; expresses the shipped guarantee in falsifiable terms a reader could check; and names the specific assumption changes that must trigger a re-evaluation. What distinguishes it from an ordinary design doc is that its content is the boundary and its guarantee, and that it is written to be superseded, not silently edited, so the trail of why the line moved stays intact.

Tuning parameters

  • Granularity — one project-level record versus a record per subproblem. Finer records track a complex boundary precisely; coarser ones stay readable but blur distinctions.
  • Immutability — append-only supersession versus edit-in-place. Append-only preserves the rationale history that makes a reopened decision trustworthy.
  • Trigger sensitivity — how large an assumption change must be to reopen the decision. Too sensitive and it churns; too loose and it certifies a guarantee the system has outgrown.
  • Guarantee precision — how tightly the shipped guarantee is stated. A sharp, falsifiable guarantee is auditable; a vague one ("mostly correct") records nothing anyone can check.

When it helps, and when it misleads

Its strength is institutional memory: it stops re-litigation, stops silent drift when assumptions change, and makes the boundary auditable by someone who wasn't in the room. Its failure mode is that a record is only as true as its inputs — it can faithfully enshrine a wrong boundary with all the authority of a right one, and stale triggers let it keep certifying a guarantee the system no longer meets. The classic misuse is writing it after shipping, to rationalize a decision already made rather than to record a reasoned one — an Architecture Decision Record[1] run backwards. The discipline is to tie the record explicitly to its assumptions and recheck triggers, and to supersede rather than quietly edit when the line moves.

How it implements the components

  • decision_record — it is the recorded go / restrict / decline decision, with the rationale and the boundary it draws.
  • computability_guarantee_record — it publishes the guarantee actually shipped (fully decidable, decidable subclass, semi-decidable with explicit unknown, or bounded) in checkable terms.
  • recheck_trigger — it names the specific assumption changes that must reopen the boundary decision, so drift is caught deliberately rather than discovered late.

It records but never derives — the constructive witness (Constructive Algorithm and Correctness Proof), the impossibility certificate (Diagonalization Impossibility Proof), and the complexity placement (Computational Complexity Analysis) are produced elsewhere and merely cited here.

References

[1] Architecture Decision Record — a lightweight, durable document capturing a significant decision, its context, and its consequences (a pattern popularized by Michael Nygard). A computability-boundary record is that pattern applied to the decidability line and its shipped guarantee. ↩