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 14:36:52 UTC · snapshot created 2026-10-03 14:38:14 UTC · last check 2026-10-03 15:20:20 UTC

E.23:4.1a - When the evaluation needs to change

Use this branch when a missed defect, false objection, harmful proposed repair, changed use or excessive evaluation cost gives reason to reconsider the evaluation. An ordinary object repair can keep using the existing adequate evaluation.

First identify what changed. A new object version, a new requirement, a different task population, a different measuring procedure and a different evaluator implementation can require different responses. Fixing an implementation error can preserve the intended evaluation while invalidating the results affected by that error. A threshold that varies with load under a fixed rule still uses that rule; it does not by itself change the evaluation.

Keep the evaluation meanings and comparison conditions stable within one comparison. To change them between cycles, use A.19.ECS:4.5: compare the old and proposed evaluations on independently grounded defect and admissible cases, inspect harmful repairs and full cost, and use a new independent case when known cases were used for tuning. Decide whether to adopt the change for a stated use, retain it on trial, revise it, reject it or keep the current evaluation. A stricter result or higher evaluator agreement is not the adoption criterion.

After adoption, name which earlier conclusions depend on the changed rule. Re-evaluate affected preserved cases where cross-evaluation comparison is needed; otherwise retain earlier results with their original scope. Declare a bridge when it is justified, and leave unlike values incomparable when it is not. New task populations and requirements create new questions without retroactively falsifying supported old answers.

Worked slice. A review evaluation rewards concise explanations but misses an omitted dependency that makes the instruction unusable. Adding the missing dependency improves the object under its existing usefulness requirement. Changing the evaluator so it notices that defect is a different proposal. Compare that evaluator with its predecessor on the defective text and a concise, fully usable alternative; reject a repair that makes every explanation longer without need. A new independently grounded case supports adoption beyond those development cases. Previously supported readability judgements remain scoped to their text and reading conditions; only conclusions depending on the missed dependency need reopening.