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:50:20 UTC

E.23:4.1 - Ordinary loop method

For one quality-improvement loop:

  1. Name the exact object version and the evaluation that will judge it. Reuse the current QualityEvaluationQuestionFrame and QualityEvaluationUseDeclaration when they still fit the purpose and receiving use. Keep the evaluator, evaluation pattern or Method, characteristic space, evidence basis, result form, ClaimScope, and qualification window separate.

  2. State the content change sought, protected trade-offs, cost and risk account, and local stop condition. Do not use 5, all-5, or 5-defensible as the target; say what should become better in practice.

  3. Reuse the exact current E.22 question frame, or open one when no frame binds the current object, purpose, scope, and result-consuming work or decision.

  4. Run the declared evaluation. When the evaluated object is one FPF pattern version, retain the complete E.21 result: every coordinate, ShortRationale, PrecisionRestorationProfile, evidence basis, coordinate payload, and status. A loop note, blocker summary, or “no blockers” statement is not a substitute. If dated evaluation Work is asserted, identify it and its result binding or direct result relation; keep any durable result episteme separate.

  5. Record each returned finding or proposal separately. A grouped memory summary does not close skipped items, and a proposal remains a proposed next action rather than performed Work.

  6. Select the next change. Selection does not perform it. When the account asserts dated improvement Work, identify that Work and connect it to a returned value or changed object only through an obtaining A.6.1 binding or declared Work-to-result or Work-to-change relation. If that relation is unavailable, keep proposal, Work, changed object, and Transformation separate and return the missing relation.

    Repair below-floor findings first. Above the floor, prefer a substantive gain—such as clearer action, a missing case or countercase, current source support, restored predecessor content, cleaner relations, or a split of overloaded material. Do not add guards, catalogues, or quality proof merely to defend a higher score. Close with no change only after the evidence shows that no feasible non-dominated improvement remains worth its cost under the protected trade-offs.

    For a precision-restoration defect, apply F.19 and open a restoration or subject pattern for an unresolved FPF-specific meaning. Claim a Method or MethodDescription only when A.3.1 and A.3.2 admit it. Keep locator, Method, description, performer, assignment, Work, result, and responsibility separate. Run one bounded KindRestorationCheck when the changed expression can alter FPF-governed meaning; otherwise F.19’s local revalidation completes the ordinary repair.

  7. Re-evaluate the changed object as a separate pass through the same declared evaluation with comparable evidence and conditions. If the evaluation itself needs to change, use §4.1a before comparing values across that change. Keep the later Work, application or direct result relation, evidence, returned value, and result episteme distinct from the first pass.

  8. Record what improved, what stayed at the floor, what was unchanged by value, what became worse, and which findings moved outside this evaluation. Compare the two result epistemes rather than treating the later pass as a continuation field of the first Work.

  9. Decide stop, continue, switchMethodFamily, openNewFrame, or holdUntilInformationBasisSufficient. When later replay depends on alternatives and guards, use the conditional structure block below. A decision or selected continuation neither authorizes nor performs the next Work.

  10. Leave an account that lets the next reader recover the object versions, evaluation, proposals, performed passes, result or change bases, evidence, trade-offs, cost and risk, continuation, stop and return boundaries, and the reason for the decision. Use the structured QualityImprovementLoopRecord only when a named replay, handoff, audit, or machine-facing use needs that form; otherwise a short result with the same recoverable facts is enough.

Stop here when this route answers the current use. Open the names, record schemas, and unfolding-structure block below only when a named receiving use depends on that added assurance detail.