Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 08:30:15 UTC

C.22:0 - Use This When

Use this pattern when one stabilized problem-side episteme must be related to a selector-facing TaskSignature for eligibility, acceptance, or policy-governed selection. Typical cases include solver choice, method-family eligibility, QD archive selection, open-ended generator selection, or specialization claims that need a declared task family or work target.

The working moment often sounds like this: “We are about to compare possible ways of doing, but which facts about this problem make a method family eligible, comparable, or unacceptable for this use?” Construct the smallest A.6.0 TaskSignature that a later selector can consume without selecting a method in advance, then assign it to the exact problem-side episteme and receiving use. If problem framing remains contested or stale, use C.22.2. If a sufficient signature and assignment already exist and the current question is selection, use G.5. If a method is selected and dated enactment is being prepared, use A.15.2.

What goes wrong if missed. A problem remains a paragraph: selector inputs drift, ordinals and units get mixed, unknowns are coerced, acceptance thresholds leak into CHR fields, and reuse proceeds from a shared name, scheme, plane, or package instead of two exact local senses, a tested F.9 relation, and a separate claim about the proposed use.

What this buys. The downstream selection question gets one separately constituted TaskSignature with typed vocabulary, laws, applicability, unknown handling, and ClaimScope. Evidence, freshness, and cross-semantic relations are added only when that receiving use actually needs them. Its assignment is replayable while publication and serialization can vary without changing the signature.