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 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:20:10 UTC

C.22:12.1 - SoTA-Echoing

Wolpert and Macready’s “No Free Lunch Theorems for Optimization”, 1997, remains historical lineage for the warning that method superiority is distribution-dependent. It does not by itself supply the current C.22 field set, a selector policy, or evidence that one TaskSignature is adequate. The current sources below change the pattern by value.

Current source and statusAdopted or adapted moveEffect in C.22Limitation and review condition
Roger Jiao, “Towards rigorous problem formulation for engineering design research: from motivations to measurable claims via metric-measure-method”, Journal of Engineering Design 37, 2026; Szajnfarber, Lifshitz, and Tushman, “Beyond translation: how context work during problem formulation enables effective solving by outsiders”, 2026 research article.Adopt problem-before-method formulation, operational characteristics and measures, and a named decision or action that will use the result. Adapt context work into the signature’s exact task or work target, direct declaration fields, Vocabulary, and Applicability plus the problem-side and receiving-use slots of TaskSignatureAssignmentRelation.Changes the working question, local mantra, signature content, assignment relation, reliance replay, and the manufacturing and clinical transfer cases. A fashionable method or available dataset cannot define the TaskSignature or its assignment.These sources study engineering research formulation and outsider problem solving; they do not establish FPF kinds or one universal signature schema. Review the adaptation if later cross-domain evidence overturns the importance of measurable problem characteristics or receiving-use locality.
Cenikj, Kudela, Tuba, and Eftimov, “Evaluating Real-World Generalizability of Algorithm Selection Models”, current June 2026 conference-linked paper and arXiv version.Adopt measurable problem characteristics as selector inputs and the empirical warning that transfer between benchmark and real-world landscapes can fail.Changes ScopeSlice(G), evidence and currentness relations, crossing discipline, unknown handling, and the rule that an old selector result reopens only when it depended on a changed field.The study concerns optimization landscapes and algorithm-selection models, not all methods or sectors. Do not infer universal transfer failure or a complete TaskSignature field list from its benchmark set.
Qin et al., “A survey on Quality-Diversity optimization: Approaches, applications, and challenges”, Swarm and Evolutionary Computation 100, 2026; Lin et al., “Quality-Diversity Optimization as Multi-Objective Optimization”, current 2026 preprint.Adopt collection-valued QD results, user-declared behavior or characteristic space, explicit containers and policies, and set-aware comparison. Adapt the MOO reformulation as one current option rather than the definition of QD.Changes the optional QD positions, DominanceRegime, report-only illumination boundary, archive case, and refusal of one default scalar score.The survey is broad but QD-specific; the MOO reformulation is a current preprint and one competing approach. Neither authorizes every diversity measure to enter dominance. Review when stronger comparative evidence changes container, metric, or scalarization treatment.
SciML, “Problem Interface” and “Common Solver Options”, living documentation generated in June 2026.Adapt the practical separation between a constructed problem value and later solver dispatch, plus explicit problem remake when fields change.Changes the ODE case and the smallest-repair rule: a semantic field change requires C.22:5.2’s identity, membership, and edition-continuity checks, and a changed problem-side or receiving-use episteme requires the assignment to be checked again before selector replay; solver implementation does not become the problem or TaskSignature.This is current software practice, not a transdomain ontology and not evidence that every project needs an immutable software record. Review on material interface or dispatch changes; preserve the general separation only while it continues to improve the declared use.