Design proposals differ from claims in kind, not confidence
Type: kb/types/note.md · Status: seedling · Tags: artifact-analysis, document-system
A theory register sorts its artifacts by commitment — provisional, accepted, deliberately conjectural. That works for hypotheses, because a hypothesis is a claim with the commitment dial turned down: truth-apt, contestable, the same kind of thing as an accepted claim. It fails for design proposals, because a design proposal is a different kind of thing. It contains free parameters — choices that could have gone otherwise without anything being wrong — and an artifact with free parameters cannot be false, only unhelpful or unadopted. Filing a proposal as a low-confidence claim is a category error, not a weak claim: contestability tests don't fail against it, they don't apply.
The discriminator is operational: ask whether the artifact's distinctive choices could be defended as correct, or only as workable. A factoring of a process into five stages rather than four, a metric definition, a schema's field list — these are workable, not correct. Whoever reviews such an artifact for truth will produce noise; the right quality test is design quality — problem stated, forces stated, free choices marked, adoption criteria named.
The existential recast
A proposal whose requirements are substantive can re-enter the claims register honestly by changing the quantifier. "Maturation follows this ladder" is a universal claim that its own free parameters refute. "There exists a factoring of maturation into operations with distinct oracles — here is one" is an existential claim proved by construction. Inside a witness, arbitrary choices are legitimate: any witness proves an existential, so nobody needs to defend why the construction went this way rather than that.
The recast has a crux: the requirements R must be substantive, or the existential is vacuous. "There exists a memory system with five stages" is trivially true and worthless; the recast earns its place only when R is demanding enough that exhibiting any witness is informative. The recast is therefore not a universal rescue — it covers proposals that carry real requirements, and the rest need a descriptive home instead.
The residue is descriptive, not theoretical
A design proposal that resists the recast is still a perfectly good descriptive artifact: an account of a design object can be faithful — problem, options, forces, free choices — without the design being true. That is why unadopted designs belong in a descriptive register rather than diluting a theory register with non-truth-apt content. The split has a recurring seam: a proposal's requirements are usually the transferable part and double as the theory register's claim material, so they extract to claims and the proposal cites them, inlining only system-specific constraints. The two halves also age differently — option spaces and current-state descriptions go stale as the surrounding system moves, while the extracted requirements survive — which is independent evidence that they belong to different registers.
Hypotheses need nothing new
The taxonomy's other arm requires no machinery: hypotheses are ordinary claims at reduced commitment, served by a claim title plus a conjecture-marking status. The confusion this note resolves — observed in practice — was claims-versus-proposals, not hypotheses-versus-supported-claims. A finer epistemic-status marking becomes worth adding only when the second confusion actually appears.
Relevant Notes:
- register — defined-in: the theoretical/descriptive/prescriptive register model this taxonomy operates over
- trace-derived memory earns authority per operation, not at capture — see-also: the executed precedent of the recast — claim title carries the truth-apt part, a witness section carries the construction with free choices marked
- Alexander patterns and knowledge system design — extends: Alexander's Context/Problem/Forces/Solution form is prior art for the design-quality test that replaces contestability
- Backlink surfacing — see-also: a residue-side instance — requirements extracted to a claim note and cited, option space held descriptively