E.1 - Vision & Mission

E.1:1 - Problem frame

Use this charter when proposing an FPF rule or artifact and deciding whether it serves the framework’s purpose. Name the reader’s task, show which core invariant the rule supports, and state a measurable stakeholder benefit or justify its omission. Use §4’s short route and §5.2’s worked decision. When the claim also proposes a material realization or physical intervention, apply the separate feasibility branch in §5.1.

FPF aims to give engineers, researchers and learners a reusable scaffold for carrying ideas through comparison, decision and implementation. A shared vocabulary is useful only where it helps a named use; the charter does not by itself demonstrate improvement over a domain’s existing practice.

E.1:2 - Problem

When a claim crosses domains without its meaning, basis or conditions, the receiver can repeat work or rely on an inapplicable result. A proposed common rule can repair that problem, but can also add learning and maintenance cost. Decide from the affected use rather than assuming that a shared framework is always superior.

E.1:3 - Forces

Mission Statement

Enable any motivated system/actor/agent/transformer — human or AI — to transform a raw idea into a reproducible, auditable change in the physical world through incremental, falsifiable cycles.

Vision Statement

Make reliable reasoning accessible across disciplines: combine the relevant shared grounds and reusable methods of FPF Core with suitable domain methods, and keep decisions traceable to their premises, evidence and revisions.

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.

E.1:5 - Conformance Checklist

Mathematical constructions retain their own validity and composition conditions. Material feasibility becomes an additional question when a claim proposes realizing a construction materially or intervening in a physical system. A missing manufacturing method, resource or constraint basis leaves that proposed action unresolved; a physical expression of a mathematical object establishes no realization of its elements.

An in-principle feasibility claim does not assert that production occurred. Actual Work, change, entity inception and production completion require their separate bases under A.12, A.15.1 and A.15.PROD when those claims are made.

E.1:5.1 - Three different questions about construction

• Mathematical product. A construction of R² × R³ needs its defined elements, product operations and applicable mathematical laws. With no proposed material realization, it needs no manufacturing actor or resource budget. Printing the construction on paper produces a carrier, not physical copies of all its elements.
• Proposed pump assembly. An engineer proposes assembling a named shaft and housing with a required clearance of 0.05–0.10 mm. The feasibility claim cites the manufacturing/assembly method, available equipment and materials, and the tolerance calculation supporting the stated clearance under those conditions. If the equipment capability or tolerances are unknown, return that missing basis before claiming feasibility for the decision. A valid drawing alone is insufficient.
• Manufactured pump. Claiming that pump P17 was produced additionally needs the actual assembly Work and change, and the independently applicable inception/completion facts. In an illustrative trace, a measured 0.07 mm clearance can support that one completion criterion; it supplies neither the whole production account nor an untested performance claim. A.12, A.15.1 and A.15.PROD govern those occurrence claims, while any actual composition retains its own composition rules.

E.1:5.2 - Decide a proposed reuse rule and its benefit

An engineer proposes instruction R1: “Before reusing a result, compare its subject/edition, question/use, relied sources/dependencies and qualification/currentness with this decision. Reuse only if they still answer the concern; reopen the affected question otherwise.” The artifact is a short instruction with that comparison and a filled case.

R1 supports Didactic Transparency by making the reason for reuse or reopening inspectable, and Evolvability by identifying which changed premise reopens the result. Its intended measurable benefit for the engineer is fewer invalid reuse decisions than the simpler rule “reuse the result with the same label.” The scope of the following evidence is only this stipulated desk comparison:

There is one invalid reuse under the label-only rule and none under R1 in these two cases. This supports the stated failure-prevention argument; it is not an observation of reader behavior or proof that review is faster. The added comparison has a cost. If a receiver claims “R1 makes all reviews 20% faster” without observations, remove that outcome claim and retain the bounded aim, or select a task-matched inquiry before making it. If the proposed rule merely requires a new label and says “supports Evolvability,” return the missing continuity or change-handling contribution; the label alone does not satisfy CC-Vision.2.

The next action is therefore specific: use the supported instruction for this bounded concern, investigate a claimed reader benefit through E.12 when worthwhile, or repair the unsupported invariant argument. New evidence about the source population reopens applicability; new evidence about reading cost reopens the benefit claim.

E.1:6 - Consequences

Intended gains — Make cross-domain claims easier to recover, make their support traceable, and help learners use the concepts. A particular artifact states and supports its own benefit; this charter is not evidence that those gains have already occurred. Trade‑offs — Authors face an initial learning curve and must trace every rule to an invariant; disciplined traceability is required to prevent variant sprawl.

E.1:6.1 - SoTA-Echoing — connect conformance to intended use

Practice question. Does a well-formed, traceable rule deserve adoption when its contribution and stakeholder benefit remain unclear? The selected line couples rule conformance with a bounded intended-use argument. The serious simpler default checks required fields and invariant labels, accepting the artifact when that trace is complete. That default is inexpensive and can suffice when the substantive argument is already established and unchanged; it cannot establish the argument for a new rule by itself.

The NASA Systems Engineering Handbook’s product verification and validation distinction, §§5.3–5.4 supplies the substantive line: requirements conformance and satisfaction of stakeholder expectations in intended use answer different questions. Adapt that distinction to CC-Vision.2/4 and §4 steps 2–3. The handbook concerns engineered products; its authority neither admits an FPF invariant nor proves the universal value of a reasoning framework. The conformance-only shortcut is the compared local default, not NASA’s complete method.

The GOV.UK Service Standard’s success-definition guidance supports the complementary move of identifying useful performance measures together with user research. Adapt it to the explicit benefit and evidence boundary in §5.2. Reject treating a metric target as an achieved effect. Neither source supplies a required improvement percentage or a universal framework-effectiveness test.

At the same proposal and two-case scope, §5.2’s substantive replay detects the unsafe label-only reuse that a complete traceability field would leave unanswered. It costs a small explicit comparison; wider reader or performance claims cost separately justified inquiry. Reuse an already adequate argument when its conditions match, and justify an omitted benefit where CC-Vision.4 permits it. Reopen only when the intended task, invariant contribution, benefit evidence or serious cheaper alternative changes enough to affect adoption.

E.1:7 - Relations & Precedence

Pattern E.1 governs E.2 Eleven Pillars and the Guard‑Rail set E.5; any later pattern that conflicts with E.1 MUST be revised via a DRR before entering the Canon.

“Purpose without a scaffold is wishful thinking; a scaffold without purpose is cargo‑cult—FPF welds the two into disciplined imagination.”

E.1:End