E.1:4 - Solution — Shared Grounds and Reusable Methods

FPF helps practitioners construct and revise ways of doing from explicit shared grounds. Its first principles are cross-domain starting commitments that govern the framework’s architecture, use, evaluation and development, including the distinctions, inferences and grounds for claims used in reasoning. The constitutional and defining patterns explain these commitments and their scope. A premise introduced in one task model has the scope justified for that model; using it does not establish a framework-wide commitment. All eleven pillars in E.2 retain their role as FPF’s constitutional first principles. For example, P-2 gives human comprehension priority over theoretical or tooling purity, and P-7 directs proofs, metrics and models towards real-world objectives.

The Kernel is the subset of Core content that defines admitted universal meta-concepts and their relations. The eleven pillars are constitutional requirements outside that subset; they govern the Kernel and other Core content. P-2 and P-7 therefore remain first principles without becoming Kernel definitions. Broader Core content also explains reusable methods. Describing a method does not establish that someone can perform it or has performed it. Practitioners use domain methods to perform the subject work; domain evidence supports bounded claims about the suitability of a method or its result for the intended use. These grounds and methods remain open to justified revision under the invariants below and E.2.

FPF expresses these shared grounds and reusable contributions through:

1. a Kernel of admitted universal meta-concepts and the rules that define their meanings and relations;

2. patterns that explain reusable methods, state their conditions and grounds, and apply or extend shared distinctions without replacing their governing meanings;

3. a pattern language (Architectural ► why/ how; Definitional ► what) with embedded Conformance Checklist (CC);

4. Design Rationale Records (DRRs) that govern safe, auditable evolution;

5. three core invariants that every artefact must honour

   • Evolvability — change is expected and governed;
   • Cross‑Scale Coherence — the same algebra binds parts to wholes at any level;
   • Didactic Transparency — each element exposes its own reasoning path.

For a proposed rule or artifact, take one affected use through these steps:

1. State the intended user, decision or action, and the failure the proposal addresses.
2. For a normative rule, name at least one core invariant and explain the rule’s contribution in that use. A copied invariant label is insufficient; if the contribution is unresolved, retain the proposal and return the missing argument or case before treating it as charter-conformant.
3. State the artifact’s intended measurable benefit, its comparison basis and how it could be checked, or the reason a benefit statement is inapplicable. Distinguish an aim or supported prediction from an observed result. Withdraw an unsupported outcome claim or obtain the evidence needed by that claim; do not substitute conformance for benefit.
4. Apply only the additional feasibility and lexical conditions that the claim activates. Keep any remaining gap and the next useful action explicit. A changed benefit basis or invariant argument reopens the affected claim, not unrelated conclusions.