#Part E – The FPF Constitution and Authoring Guides

Preface node heading:part-e-the-fpf-constitution-and-authoring-guides:57038

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Vision & Mission: “Operating System for Thought”

#Problem frame

Modern engineering, science, and strategy all suffer from conceptual overload: dozens of domain tools, drifting vocabularies, and disconnected “best practices” splinter ideas as they travel from napkin sketch to certified deliverable. Stakeholders—Engineers, Researchers, Learners—lack a single, evolvable scaffold that can carry an insight across that span.

#Problem

Absent such a scaffold, every discipline re‑invents epistemology and systems thinking, spawning silos, steep learning curves, and brittle life‑cycle models. Previous attempts either froze agility in rigid hierarchies or dissolved rigour in tool‑centric jargon.

#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

Reliable reasoning should be as accessible as version control: clone the conceptual kernel, extend it with domain patterns, and commit decisions that remain traceable across time, scale, and discipline.

#Solution — FPF as an Operating System for Thought

FPF delivers a generative scaffold realised as:

1. a Kernel of non‑derivable, cross‑domain first principles;

2. pluggable patterns—Systemic Calculus, Knowledge Dynamics, etc.—that instantiate those principles;

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.

#Conformance Checklist

#Consequences

Positive — Unified language accelerates cross‑disciplinary discovery; regulators can audit claim lineages; learners acquire concepts through the spec itself. Trade‑offs — Authors face an initial learning curve and must trace every rule to an invariant; disciplined traceability is required to prevent variant sprawl.

#Relations & Precedence

Pattern E.1 governs E.2 Eleven Pillars and the Guard‑Rail set A.5–A.8; 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

#The Eleven Pillars

#Problem frame

Pattern E.1 set the FPF mission as an operating system for thought. To turn that mission into a durable architecture, FPF needs a small, explicit constitution - principles that remain stable while everything built on top of them can evolve. Without such invariants, domain silos, vocabulary drift, and tool-centric shortcuts quickly erode coherence and reproducibility across disciplines.

The pillars are also the first-principles basis of FPF. They are the minimal commitments from which pattern-level work derives: decisive structure, teachability, maturing formality, open kernel, layering, register discipline, practical payoff, cross-scale consistency, explicit state, open-ended evolution, and SoTA renewal. Later patterns can support this basis by making a concrete argument about pillar support more inspectable; they do not replace pillar authority.

#Problem

Frameworks without binding first principles wobble between two extremes: rigid dogmas that kill adaptation and amorphous guidelines that invite cognitive chaos. In either case, reasoning fragments, auditability collapses, and physical impact suffers.

#Forces

#Solution

FPF rests on eleven non‑negotiable pillars. Each pillar is a binding constraint that every artefact, pattern, and design‑rationale record (DRR) must honour. Together they form the load‑bearing structure that guarantees evolvability, cross‑scale coherence, and didactic clarity.

When a pillar-impact argument relies on mathematical structure, scale behavior, optimization, uncertainty, invariance, obstruction, or other first-principles modeling support, the applicable mathematical-lens use support path is C.29. The pillar claim remains governed by E.2; C.29 only states the mathematical lens, preserved and lost structure, admissible use, neighboring-pattern exits, and stop condition that make the pillar support inspectable.

Any DRR that contradicts a pillar must first amend this constitutional pattern.

#Conformance Checklist

#Policy — Bitter‑Lesson Preference (BLP)

Intent. Favor general, computation‑leveraged, and freedom‑of‑action methods over hand‑tuned, brittle heuristics when safety and legality are held constant. This codifies the empirical trend that methods which scale with data, compute, and search breadth outpace bespoke rule‑engineering. Applicability: beyond ML, this policy covers search/optimization, control, simulation‑based inference, and other computational sciences where capability improves with scale and exploration. When NQD/E/E‑LOG promotes novelty/coverage (illumination) telemetry into dominance (via an explicit CAL policy; policy‑id recorded in SCR), these telemetry metrics are included in BLP comparisons for the audited window.

BLP‑1 — Scale‑Audit Requirement. Any DRR that selects a more specialized/hand‑engineered method over a general/scalable alternative MUST include a Scale‑Audit:

• (a) Parity harness: same ComparatorSet, freshness window, and evaluation seeds/replicates; set-returning evaluation (see G.5/G.9). Dominance criterion: Pareto‑only by default across the declared objective vector; any alternative requires a documented waiver by Gov‑CAL under E.3 precedence.
• (b) Budgets: sweep compute (steps/tokens/params/time/energy, as applicable), data (size/quality), and freedom‑of‑action (from script‑like instructions → minimal prohibitions) under a fixed risk/safety envelope. If any parameter cannot be swept, pin it and record the invariant.
• (c) Slopes & uncertainty: report ∂quality/∂compute, ∂quality/∂data, and (where applicable) ∂coverage/∂freedom‑of‑action and ∂novelty/∂budget; include error bars/CI from multi‑seed trials; publish edition pins and policy‑IDs in SCR/telemetry (G.11).
• (d) Resources: publish Resrc‑CAL accounts (time/energy/FLOPs) and assurance deltas (B.3).
• (e) Objective declaration: list the objective vector (quality, risk, cost, and any illumination telemetry explicitly promoted into dominance via CAL with policy‑id recorded in SCR) used for Pareto comparison.

BLP‑2 — Preference Rule. Given admissibility and comparable assurance (within δ) and budget (within α), prefer the method whose slope vector is Pareto‑dominant over the audited range (per BLP‑1c/1e). If no dominance holds within error bounds, prefer the more general method (fewer domain‑specific heuristics, greater transfer via Bridges Φ/Ψ); otherwise resolve via E/E‑LOG tie‑breakers declared in policy.

BLP‑3 — Minimal‑Prescription Default. Author rules‑as‑prohibitions (negative constraints) over step‑by‑step scripts. Encode limits in Φ policy tables (and Φ_plane where applicable) instead of procedural checklists; allow the agent/system to sequence functions autonomously under those constraints (SoS‑LOG). Pre/post‑conditions and test harnesses remain permitted; scripts are permissible only when mandated by safety/regulation, or with compelling evidence recorded in the DRR and reviewed under E.3 precedence / E.5 Guard‑Rails.

BLP‑4 — Heuristic‑Debt Register. Any hand‑tuned rule admitted for pragmatic reasons MUST be registered as Heuristic Debt with: scope, responsible role, expiry/review window, measurable replacement target under BLP‑2, and a de-hardening/sunset plan. Track in CalibrationLedger/BCT (Baseline Change Tracker) and cite in SCR.

BLP‑5 — Continuous‑Learning Posture. Where product policy allows, enable feedback‑driven adaptation (e.g., preference learning, critique loops) within Guard‑Rails (E.5) and privacy/regulatory controls, with appropriate opt‑outs where required. Disabling adaptation requires DRR justification and a review date.

BLP‑6 — Precedence & Safeguards. BLP is a Gov/Arch policy instantiated by Pillars P‑10 (Open‑Ended Evolution), P‑11 (SoTA Alignment), P‑7 (Pragmatic Utility), and P‑1 (Cognitive Elegance). It does not override safety/ethics (E.5) nor E.3 precedence rulings; where BLP conflicts with Guard‑Rails, Guard‑Rails prevail. When NQD/E/E‑LOG elevates illumination to dominance for exploration mandates, BLP adopts that lens rather than overriding it.

Informative SoTA contexts (post‑2015): set-returning selection across LLM prompt‑programming vs fine‑tuned task models; preference‑learning families (RLHF ↔ DPO); QD archives (MAP‑Elites/CMA‑ME/DQD/QDax); open‑ended environment–method co‑evolution (POET‑class); offline RL vs Decision Transformer parity; and beyond ML, optimization/control (model‑based planning vs hand‑tuned controllers) and simulation‑based inference in the sciences. These are illustrative only; use the parity harness instead of single‑winner leaderboards.

#Conformance Checklist — BLP

#Relations

• Instantiates pillars: P‑10, P‑11, P‑7, P‑1.
• Depends on: G.5/G.9 (admission/comparator/selector & parity harness), G.11 (refresh telemetry), C.5 (Resrc‑CAL), C.18 (NQD‑CAL), C.19 (E/E‑LOG), F.7/F.9 (Bridges, CL/Φ/Ψ).
• Constrained by: E.5 Guard‑Rails (DevOps Lexical Firewall; Notational Independence; Cross‑Disciplinary Bias Audit) and E.3 precedence.

#Definitions

α (budget tolerance) may be relative or absolute; declare units (e.g., % cost, wall‑time, energy). δ (assurance tolerance) is the permissible delta in assurance under B.3; declare measure and floor(s).

#Consequences

Positive

• Provides an explicit “north star” for every contributor.
• Delivers a falsifiable checklist for evaluating proposals.
• Builds trust in high‑assurance domains through transparency.

Trade‑offs

• Constitutional review adds friction to rapid, informal changes.
• Amending the pillar set itself demands high‑bar governance.

#Rationale

The pillars are distilled from systems engineering, philosophy of science, software architecture, and ontology design. They interlock: Cognitive Elegance (P‑1) enables Didactic Primacy (P‑2); Open‑Ended Kernel (P‑4) and FPF Layering (P‑5) make Open‑Ended Evolution (P‑10) and SoTA alignment (P‑11) feasible; Cross‑Scale Consistency (P‑8) provides the algebraic backbone for Scalable Formality (P‑3). This minimal yet sufficient set balances stability with change, rigor with accessibility, and abstraction with measurable impact.

C.29 is a downstream support pattern for this constitution when mathematical first-principles structure is part of an argument about pillar support. It makes the structure, loss, and stop condition explicit while E.2 remains authority over what counts as a pillar.

#Relations

• Depends on: pat:constitutional/vision – pillars operationalise the mission.
• Refined by: All subsequent patterns in the Core Specification.
• Mathematical support path: C.29 supports pillar-impact arguments only for adequacy of mathematical lenses used to express first-principles structure. It does not amend pillar content, priority, or conformance.
• Governs: Every DRR, tool, and pedagogical artefact linked to FPF.

These pillars are not a cage but the load‑bearing columns of a workshop where ideas can be safely built, dismantled, and evolved.

#E.2:End

#FPF Pillar-Adequacy Evaluation CharacteristicSpace

Status: Core.

#Problem frame

Use E.2.DA when the object under improvement is an FPF-level object and the question is whether it realizes the E.2 Pillars adequately for a declared use. The object can be a monolith edition, selected pattern host set, pattern family, projection set, release candidate, or whole-FPF edition.

Use it after a broad cleanup, new pattern family, projection repair, source-use repair, or corpus-level improvement when local pattern quality is not enough. A set of good local patterns can still harm FPF entry, naming, layering, source use, projection integrity, or open-ended evolution.

Not this pattern when the evaluated object is one authored pattern version, one DRR, one local wording repair, or one pattern-use entry problem. Use E.21, E.9.DA, E.10 and its precision-restoration neighbours, or E.11 for those objects.

First useful move: name the FPF object under improvement by value, declared use, reader family, and qualification window; then evaluate all eleven Pillar coordinates. If a Pillar seems unaffected, give it a value and a short rationale saying what is preserved.

What goes wrong if missed: FPF can become locally polished but globally worse. Readers may find fewer useful entry points, precision repairs may erase the working move, source rows can turn decorative, or several patterns can grow local variants of the same doctrine.

Primary EntityOfConcern in plain terms: the scoped FPF object under improvement as an E.2 Pillar-realizing language object.

#Problem

E.2 gives the Pillars and their constitutional meaning. It does not by itself evaluate whether a concrete FPF object realizes those Pillars well enough for a concrete use. Without E.2.DA, corpus-level reviews tend to collapse into local pattern scores, process state, review praise, or broad claims that "FPF improved."

The specific failures are:

1. Local pattern quality is averaged into FPF adequacy.
2. Entry projections and companion files start carrying semantics beside governing patterns.
3. Precision repair improves terminology but damages first-use comprehension or changes the FPF kind carried by the repaired text.
4. Source and SoTA rows are counted rather than checked for changes in FPF moves.
5. Front-like words such as all 5s, exceptional, Pareto, SoTA, NQD, or shortlist become loose synonyms.
6. Corpus-level stop claims hide what became worse.
7. Pillar values become repair targets, so the corpus gains projection proof, entry apparatus, source rows, or review evidence while the FPF object becomes less usable, less layered, or less decisive.

#Forces

#Solution

E.2.DA is the Pillar-adequacy specialization of A.19.ECS. It evaluates one FPF object under improvement against all eleven E.2 Pillars for a declared use.

There is no smaller E.2.DA evaluation. If the caller only needs local pattern quality, DRR adequacy, or wording repair, that is a different object-under-improvement evaluation. Once E.2.DA is invoked, every Pillar coordinate receives a value, short rationale, evidence locus, and shared evidence basis for the FPF object being evaluated.

#Local names and kind settlement

These names are local to the evaluation unless F.18 promotes a durable name. They name FPF content objects and evaluation fields, not release state, review state, or project evidence.

#Evaluation record

FPFPillarAdequacyEvaluation:
  FPFObjectUnderImprovementRef: <object and version named by value>
  FPFAdequacyUseScope: <entry | authoring | review | project use | source absorption | corpus release | other use named by value>
  FPFAdequacyReaderScope: <primary reader and working situation>
  FPFAdequacyQualificationWindow: <edition, source, neighbour, release, or comparison window>
  FPFPillarAdequacyEvidenceBasis: <checked pattern, host, monolith, projection, README, ToC, E.11, or I.2 entry locus, source, relation, companion, evaluation-result, and missing loci that affect values>
  FPFPillarAdequacyCoordinateTable: <all eleven coordinates, values, short rationales, evidence loci>
  FPFKindRestorationEvidence: <when broad wording or precision repair is part of the evaluated change: pre-repair and post-repair kind, relation or claim kind, slot or use-position if part of the changed FPF-governed claim, admissible use, scope, governing pattern when another pattern governs the kind under repair, relation, claim, or position, and preserved, split, intentionally changed, or blocker disposition>
  FPFPillarAdequacyStatus: <status>
  StopOrRepairCondition: <local stop, first repair, Pillar decision, or architecture decision>

[E.22](/generated/patterns/E.22) may frame the evaluation purpose when the caller needs floor evaluation, exceptional improvement, trade-off inspection, open-question discovery, absorption, or proposal portfolios. [E.23](/generated/patterns/E.23) governs repeated improvement after the evaluation returns findings or candidate proposals.

#Ordinal coordinate scale

The values are ordinal content evaluations. They are not a scalar score, maturity ladder, release gate, or proof that development ends.

#Required Pillar coordinates

#Evidence and coordinate separation

One evidence locus may support several coordinates, but the rationale must say what property it supports in each coordinate. The following distinctions carry most repairs:

If a distinction cannot be recovered from the FPF object, lower the affected coordinate and state the first repair. Do not add a new local doctrine table to explain around the missing content.

E.21 and E.9.DA results are evidence loci for E.2.DA, not inputs to be averaged. A pattern-quality value can support a Pillar only by pointing to the FPF-level effect it creates or damages.

#Result-row discipline and calibration

An E.2.DA result uses this table shape:

A Pillar essay, local-quality average, two-column table, or result whose value depends on unchecked corpus, projection, or source evidence is not an E.2.DA result. It is only draft evaluation material. Missing or unchecked evidence lowers the Pillar coordinate that needs it; it does not make the coordinate optional.

Common calibration points:

#Status and stop condition

The stop condition states the declared floor, values, bounded non-use, smallest reopen locus, and first repair if the declared use is not yet admissible.

#Compact result form

E.2.DA result:
  FPF object under improvement: <FPFObjectUnderImprovementRef>
  Declared use and reader: <scope>
  Qualification window: <window>
  Evidence basis checked: <FPFPillarAdequacyEvidenceBasis>
  Status: <FPFPillarAdequacyStatus>
  Coordinate table: <Pillar coordinate | Value | ShortRationale | EvidenceLocus for all eleven Pillars>
  First repair or stop: <repair | hold | local stop>
  Reopen if: <smallest changed locus or condition>

For a small release decision, the coordinate table may be compact. It is still complete. Status is not assigned from prose, a checklist count, a local-pattern average, a two-column table, or a result missing evidence loci needed by its values.

When [E.22](/generated/patterns/E.22), [E.23](/generated/patterns/E.23), absorption, or exceptional-improvement framing asks for improvement, below-floor Pillar coordinates return findings or repair. Above-floor coordinates receive proposal rows only for substantive non-dominated FPF-level content opportunities inside the declared use: better entry recognition, governing-pattern authority, source-currentness carry-through, projection thinning, corpus-ecology repair, kind-preserving precision restoration, open-ended evolution support, or deletion or relocation of apparatus that weakens the FPF object. Do not treat every value below 5 as a defect. A 4 may be the correct stop value only with loci showing why further Pillar-content movement is dominated, unavailable, or outside scope.

#Worked slices

Broad precision cleanup. A wording pass makes many patterns more admissible but several Problem frames now explain less about why the distinction matters, or a cleaned phrase changes the governed kind while the trigger word disappears. P2, P6, and P7 receive lower values until the affected patterns restore recognition reason, useful action, and pre-repair and post-repair kind evidence in admissible wording.

Ontic architecture repair. A campaign adds E.24.CD, E.24.PUB, or a new ontic host. Pillar values rise only if the change reduces duplicate ontology, type explosion, or shadow authority and improves FPF entry, authoring, review, or project use. Extra ontic terminology, score proof, or publication-boundary prose without better action lowers P1, P2, P5, P6, and P7.

Repeated content, route, reference, neighbour-reference, and negative-fanout cleanup that weakens content. A corpus pass removes repeated "not proof", "not gate", and "not work" prose, route metaphors, repeated guards, repeated mini-rules, repeated conditional neighbour-reference mappings, reference boilerplate, or architecture-placement prose, but leaves several patterns with less positive ontology, method, norm, or worked action than before. P2, P5, P6, P7, and P10 receive lower values until the affected patterns restore their own subject content and state only current declarative governing relations.

Projection repair. README scenarios, ToC rows, E.11 entry-distribution loci, and I.2 expanded entry-disambiguation cases improve search but can start carrying pattern semantics. P5 and P9 fall because projections become shadow authority. The repair moves durable semantics back to governing patterns and leaves thin echoes in projections.

Source absorption. A new source family adds current methods, but pattern bodies only cite it. P11 stays low until source rows change selected moves, examples, checks, or stop conditions. P7 changes only when the source changes action.

#Bias annotation

This pattern biases FPF toward whole-language adequacy. The bias is useful because local repairs often hide corpus-level loss.

The bias is bounded by the object-under-improvement declaration. E.2.DA does not replace E.21, E.9.DA, E.10, E.11, or E.23; it evaluates their FPF-level Pillar effect when the scoped FPF object includes their results.

#Conformance checklist

#Common anti-patterns and repairs

#Relations

| E.10, A.6.P, C.2.P, C.16.Q, F.18 | Govern local precision and naming repair. | | E.11, E.17, I.2 | Govern entry, projection, publication, description, and expanded entry-disambiguation roles that may affect Pillar adequacy. | | C.18, C.19, G.5, G.9, G.11 | Govern OEE, NQD, pool, selected-set, parity, and refresh semantics when those semantics are claimed. | | C.29, C.16, A.17, A.18, A.19 | Govern mathematical-lens, characteristic, scale, measurement, and characteristic-space legality when those claims are being made. |

#Rationale

FPF needs a corpus-level quality instrument because the language can degrade while individual pattern edits look successful. The complete eleven-coordinate evaluation prevents the common escape hatch: "this is only a local repair" repeated across many files until Pillar realization changes.

The instrument is still affordable because it asks for short rationales and evidence named by value loci. It does not require a new review process, full audit bundle, or exhaustive source dossier.

#SoTA-Echoing

#Consequences

#E.2.DA:End

#Principle Taxonomy & Precedence Model

#Problem frame

Pattern E.2 supplies eleven immutable pillars, yet experience shows that a flat list of principles invites ambiguity: reviewers cannot decide which pillar overrules another and “dead‑letter” rules accumulate.

#Problem

When two pillars or derived principles pull in opposite directions, architectural decisions stall—or worse, drift toward the loudest voice. Without an explicit taxonomy and precedence cascade, FPF risks devolving into subjective debate, breaking its claim to be a rigorously auditable “operating system for thought.”

#Forces

#Solution

#Principle Taxonomy

Every principle is an instance of U.Principle assigned exactly one class ∈ { Gov, Arch, Epist, Prag, Did }.

Epistemological sub‑concerns (reasoning, falsifiability) reside inside Onto, avoiding category sprawl yet keeping semantics and trust in one bucket.

#E.3:4.2 - Precedence Stack

Within the precedence stack the default order is: Gov ≫ Arch ≫ Epist ≫ Prag ≫ Did

Graph Rule — The precedence graph MUST be acyclic; any new edge that would form a cycle is rejected.

Governance principle vs Architectural principle clash: e.g. Core release schedule (Gov) outranks performance‑tuning (Prag)

#Conformance Checklist

#Illustrative Conflict Resolution

1. The Conflict

   • P‑1 Cognitive Elegance (Arch) demands an unambiguous term for “part–whole” entities, pushing us toward Holon.
   • P‑2 Didactic Primacy (Did) values immediate practitioner familiarity, pushing us to retain System.

2. Risk of Stalemate Without a precedence cascade, the discussion would collapse into subjective argument: “purity beats clarity!” vs “clarity beats purity!”.

3. Applying the Precedence Model

   • Default order: Gov ≫ Arch ≫ Epist ≫ Prag ≫ Did.
   • Arch outranks Did; therefore P‑1 takes formal precedence over P‑2.

4. Principled Decision We adopted Holon to satisfy the higher‑priority principle and mitigated the didactic cost by:

   • declaring System ≡ U.System ⊑ U.Holon,
   • providing aliases and an “On‑Ramp” tutorial.

The precedence rule did not merely name a winner; it compelled a solution that honoured both principles in proportion to their rank.

Precedence (high → low). Law & Regulation → E.5 Guard‑Rails → B.3 Trust & Assurance → E.3 governance decisions → E/E‑LOG policies (editioned) → BLP (E.2) → Product Policies → Implementation Tactics.

Notes.

• BLP is a constitutional policy (see E.2 / “BLP”), but does not supersede E.5 Guard‑Rails nor B.3 assurance floors; it does govern ties among lawful, comparable‑assurance options.
• Wherever NQD/E/E‑LOG promotes illumination telemetry to dominance (via an explicit CAL policy; policy‑id recorded in SCR), BLP adopts that lens rather than overriding it (see E.2 BLP‑6).
• Any exception to policy MUST include a DRR with rationale and expiry.
• BLP Override (Waiver). When a narrower hand‑engineered method is selected over a general/scalable alternative within declared tolerances (α = budget, δ = assurance), the DRR MUST include:
  • a BLP Scale‑Audit (see E.2 BLP‑1) covering compute/data/freedom‑of‑action sweeps and slope/uncertainty reporting,
  • the tolerances α/δ and objective vector used (E.2 BLP‑1e),
  • a Heuristic‑Debt entry (responsible role, scope, expiry/review, de-hardening plan) per E.2 BLP‑4,
  • an AutonomyProfileId (see E.3‑ABL) and the GateDecision authority (see Gate‑decision authority map below). Set-returning parity. All precedence decisions that compare methods MUST use the G.5/G.9 parity harness and Pareto dominance; scalarisation across mixed scales/units is prohibited (B.3).

BLP — Bitter‑Lesson Hooks into Precedence

1. Tie‑breaking. If two lawful options are within δ assurance and within α budget, prefer the option whose slope vector Pareto‑dominates over the audited window; if no dominance, prefer the more general method. (E.2 BLP‑2.)
2. Script‑vs‑Search conflicts. For conflicts between procedural scripts and general search/learning, scripts prevail only when mandated by E.5 or regulation, or when a DRR records a BLP‑waiver with expiry and hazard rationale (E.2 BLP‑3/6).
3. Publication. Precedence rulings that reference BLP MUST publish editioned policy‑IDs, edition pins, and Resrc‑CAL accounts to the SCR (E.2 BLP‑1d; G.11).

ABL — Autonomy‑Budget & Oversight Profiles (GateProfile) This section defines an extensible family of autonomy oversight profiles for agentic tool use: each profile specifies (i) a budget envelope, (ii) a Freedom‑of‑Action (FoA) descriptor, and (iii) the required gate‑decision publication to authorize execution under that envelope. The familiar labels L0…L4 are treated here as profile identifiers (not a fixed managerial ladder): projects MAY introduce additional profiles or sub‑profiles by minting new profile ids, provided they publish the same fields (budgets, FoA, decision roles, telemetry requirements) and keep profile changes explicit and auditable.

Normative requirements by profile.

• Budgets. Each profile MUST declare ceilings for time / compute / cost / risk and a FoA descriptor; units must be explicit (Resrc‑CAL). Budgets are hard gates at run‑time (C.Agent‑Tools‑CAL ATC‑3).
• Profile binding & change visibility. Every CallPlan MUST declare the active profile id. Any profile change is a GateCrossing (E.18) and MUST be published (DecisionLog entry + pinned policy‑ids), so an auditor can reconstruct which profile governed which Window.
• Assurance floors. B.3 WLNK minima on F and R apply at all profiles. Any profile‑specific tightening (e.g., higher required R_eff or stricter CL/Φ policies for broader FoA) MUST be declared on the profile and pinned by policy‑id. Pre‑deployment assurance deltas MUST be recorded for L2+.
• Exploration discipline. explore_share MUST be explicit in the CallPlan (C.Agent‑Tools‑CAL ATC‑4). Deviations from defaults require DRR justification.
• Provenance. L1+ MUST emit a CallGraph with Service/Method editions, EmitterPolicyRef, budget deltas, and observation hooks (C.Agent‑Tools‑CAL ATC‑5/6).
• BLP conformance. For L2+, selection MUST apply BLP (E.2 BLP‑2) with α/δ tolerances declared in the plan policy. Any admitted heuristic requires a Heuristic‑Debt entry (E.2 BLP‑4).
• Learning/Adaptation. L3–L4 MAY enable feedback‑driven adaptation within E.5 Guard‑Rails and privacy controls; L0–L2 default off unless a DRR documents mitigation (E.2 BLP‑5).
• Human‑in‑the‑Loop (HITL). HITL obligations are expressed as gate decisions and pause/resume hooks, not an implicit “approval ladder”:
  • L0–L1: execution MAY start only after an explicit GateDecision authorizing the CallPlan is present in the declared window.
  • L2: sentinels MUST be able to pause execution; resumption requires a new GateDecision recorded in the DecisionLog.
  • L3: the profile MUST declare periodic review windows; continued execution across a review boundary requires an explicit GateDecision.
  • L4: continuous telemetry review; the default execution context is sandboxed; leaving the sandbox requires an explicit GateCrossing with a published CrossingBundle (E.18 + F.9/F.17/E.17, with A.21 when a gate decision is live).

Gate‑decision authority map (default signers; who may author GateDecisions).

• L0: EoR or appointed maintainer.
• L1: EoR and peer reviewer (two‑person rule).
• L2: Team Lead and Safety representative.
• L3: Product Owner and Safety and Legal/Privacy.
• L4: Gov‑CAL Board (multi‑disciplinary) with documented scope, time‑boxed trial budget, and rollback criteria.

Profile promotion / demotion triggers.

• Promote a profile when repeated BLP‑consistent results show stable assurance within δ and budget adherence within α for ≥ N_policy runs (declare N_policy in the active profile). Promotion is not implicit: a GateDecision MUST authorize the profile change and cite the slope evidence (E.2 BLP‑1c).
• Demote a profile when: (i) a sentinel breaches risk or budget, (ii) assurance drops below floors, (iii) policy changes, or (iv) a significant heuristic‑debt item expires without replacement. Demotion MUST be published as a GateCrossing with updated budgets/policies pinned.

#Conformance Checklist — E.3 ↔ BLP Interop

#Consequences

Positive — Turns subjective debate into objective, traceable decisions; high‑impact conflicts surface early.

#Rationale

The chosen taxonomy mirrors FPF’s layered dependency: Governance rules how change occurs; Architecture shapes what can exist; Epistemology secures meaning and trust; Pragmatics and Didactics ensure usefulness and learnability. Explicit override edges supply the flexibility experts need, while the default hierarchy keeps day‑to‑day design deterministic—a “living constitution” that remains both human‑intelligible and machine‑enforceable.

#Relations

• Depends on: pat:constitutional/vision, pat:constitutional/pillars
• Governs: All subsequent patterns and DRRs; Guard‑Rail patterns reference CC‑PT.\

“A taxonomy sorts principles; precedence gives them order—together they convert debate into design.”

#E.3:End

#FPF Ecosystem Family Architecture

#Problem frame

The FPF ecosystem contains three maintained families: the normative Conceptual Core, executable or machine-checking Tooling Reference material, and learning-oriented Pedagogical Companion material. If these families are mingled without a clear architectural separation, the ecosystem becomes difficult to navigate, govern, and maintain. Users cannot easily distinguish binding rules from helpful advice, and the entire framework's release cycle becomes coupled to its most volatile component.

#Problem

How can we structure the FPF ecosystem to ensure a clean separation of concerns between normative concepts, didactic materials, and executable tooling? A formal architecture is required to maintain conceptual purity, enable independent evolution of components, and provide a clear map for all stakeholders.

#Forces

#Solution

The FPF ecosystem is formally stratified into three canonical FPF ecosystem families. Each family has a distinct purpose and is governed by different rules, ensuring a clear separation of concerns. The interaction between these families is governed by the Unidirectional Dependency Principle (see Guard-Rail E.5.3).

1. The Conceptual Core (The Canon): This family contains the normative FPF patterns, kernel definitions, rules, and invariants. It is the canonical FPF pattern set for universal FPF content. It is defined to be tool-agnostic and notation-independent.

2. The Tooling Reference: This family contains executable tools and machine-checkable support publications that implement or verify the normative rules of the Core. This includes reference linters, simulators, and data schemas. This family makes Core rules operational without becoming the Core pattern set.

3. The Pedagogical Companion: This family contains non-normative, didactic publications designed to help humans learn and apply FPF. This includes tutorials, worked examples, and playbooks. This family explains the Core and the Tooling Reference without changing Core meaning.

#Archetypal Grounding (System / Episteme)

• For a U.System:

  • Conceptual Core: Defines the universal pattern U.System.
  • Tooling Reference: Provides a modeling language profile or a serialization schema for modeling systems.
  • Pedagogical Companion: Provides a tutorial on how to model a water pump using that profile.

• For an U.Episteme:

  • Conceptual Core: Defines U.Episteme and the F-G-R assurance tuple components (F/R characteristics plus G as ClaimScope).
  • Tooling Reference: Provides the reference linting tool to automatically score epistemes.
  • Pedagogical Companion: Provides a case study on how a scientific theory's R-score evolves over time.

#Conformance Checklist

#Consequences

#Rationale

This pattern establishes the macro-architecture of the entire FPF ecosystem. By separating the normative Core from executable Tooling Reference material and learning-oriented Pedagogical Companion material, it creates a system that is simultaneously stable, agile, and accessible. This layered architecture is a proven pattern in large-scale systems, from the OSI model in networking to the structure of modern operating systems, and it is essential for FPF's long-term health and scalability.

#Relations

• Instantiates: P-5 (FPF Layering) at a macro-level.
• Is Constrained by: E.5.3 (Unidirectional Dependency).
• Is Foundation For: The entire authoring and governance model, as it defines the "territories" where different rules apply.

“A canon without a rationale is scripture; a rationale without a canon is gossip. FPF keeps both, fused in patterns.”

#E.4:End

#Four Guard‑Rails of FPF

#Problem frame

FPF positions itself as a timeless, universal “operating system for thought.” Collaborative projects of this scope face four predictable entropic pulls:

1. Implementation gravity – concept prose accretes tool jargon.
2. Notation lock‑in – one diagram style becomes “the language.”
3. Convenience cycles – quick fixes create reverse dependencies.
4. Disciplinary monoculture – implicit bias colours “universal” rules.

Left unchecked, these forces erode Pillars P‑1 Cognitive Elegance, P‑4 Open‑Ended Kernel and P‑5 FPF Layering.

#Problem

Without explicit, non‑negotiable protectors the Conceptual Core would slowly:

• entangle with transient technology terms,
• hard‑freeze into a single dialect,
• devolve into a tightly coupled “big ball of mud”,
• betray its trans‑disciplinary promise.

#Forces

#Solution — the Four Guard‑Rails

FPF establishes four architecturally enforced guard‑rails that every Core, Tooling, and Pedagogy artefact must obey. They function as an “immune system” resisting each entropic pull. Scope note (conceptual, not lint). These guard‑rails regulate the architecture of thought—concepts, claims, and their relations. They do not mandate tools, file formats, notations, or workflows; any linting or automation lives outside the Core and is optional, provided it preserves these conceptual constraints.

Concrete rules for each rail live in patterns E.5.1 – E.5.4.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

A constitution without enforcement degrades into dead‑letter rules. The four guard‑rails translate abstract Pillars into concrete, testable constraints. Grouping them under one umbrella pattern:

• gives newcomers a single “safety index” to consult,
• makes compliance binary (pass / amend),
• provides a stable anchor for future automated conformance tools—without mentioning any specific engine, thus honouring GR‑1 itself.

They collectively instantiate Pillars P‑1, P‑2, P‑4, P‑5 and reinforce the precedence order defined in E.3.

#Relations

• Comprises:
  • pat:guard/devops‑firewall (E.5.1) – GR‑1
  • pat:guard/notational‑independence (E.5.2) – GR‑2
  • pat:guard/unidirectional‑dependency (E.5.3) – GR‑3
  • pat:guard/bias‑audit (E.5.4) – GR‑4
• Depends on:
  • pat:constitution/pillars (E.2)
  • pat:constitution/principle‑taxonomy (E.3)
• Constrains: every Core, Tooling, and Pedagogy artefact; all DRRs.

#E.5:End

#DevOps Lexical Firewall

#Problem frame

The FPF Core is meant to remain valid across decades and technology generations. Implementation details—file formats, build pipelines, runtime flags—evolve rapidly and differ between domains. When such terms invade normative prose, the Core ages as quickly as the tools it mentions.

#Problem

Conceptual erosion: a rule that cites a transient technology becomes obsolete when that technology fades, forcing unnecessary Core revisions and fragmenting historical audits.

#Forces

#Solution

Establish a Lexical Firewall around the Conceptual Core (conceptual constraint; not a build‑time linter):

1. Forbidden lexicon Normative patterns SHALL NOT contain tool‑or file‑specific words (e.g. protocol keywords, file extensions, IDE commands). Permissible wording: “a reference parser”, “a serialisation schema”.

2. Indirection rule When a Core concept needs an executable illustration, the pattern cites the Tooling Reference family artefact by conceptual name, never by concrete path or syntax.

3. Glossary pointer If an unavoidable technical term appears, it is defined in a Tooling Glossary outside the Core and referenced by conceptual alias—not embedded. Non‑normative automation. Machine checks MAY exist in Tooling; they are advisory and MUST NOT be imported into the Core.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

Language shapes thought. By firewalling transient jargon, we uphold P‑1 Cognitive Elegance (clarity), P‑2 Didactic Primacy (domain‑neutral exposition) and P‑5 FPF Layering (clean separation between Core and Tooling). The rule is content‑agnostic and thus itself immune to the very decay it prevents.

#Relations

• Parent umbrella: pat:constitution/guard‑rails (E.5)
• Constrains: every pattern in Conceptual Core
• Instantiates pillars: P‑1, P‑2, P‑5

#E.5.1:End

#Notational Independence

#Problem frame

FPF concepts must travel across academic disciplines, modelling tools, and future notations we cannot yet foresee. If a normative pattern binds its meaning to one diagram style, file syntax, or markup dialect, the concept ages as soon as the notation does.

#Problem

Semantic lock‑in: when a definition relies on a particular glyph set or diagram grammar, alternative communities either translate it—risking drift—or ignore FPF altogether.

#Forces

#Solution — Notational Independence Guard‑Rail (conceptual; semantics over syntax; not a notation mandate)

1. Semantics primacy Normative content SHALL define concepts in linguistic form first (plain English + mathematics if needed). Visual or syntax examples are secondary illustrations.

2. Equivalence clause When an official alternate notation exists, the pattern must state: “Representation A and Representation B are semantically equivalent under mapping M.”

3. Reference indirection If the Core cites a diagram, it does so by conceptual role (“reference boundary schematic”) rather than by file or syntax name.

4. Conceptual prefix neutrality FPF conceptual prefixes (e.g., U., Γ_, ut:, tv:, ev:, mero:) are cognitive namespaces, not syntax tokens. Core patterns MUST NOT tie their meaning to any concrete serialisation or URI scheme for these prefixes; any expansions are illustrative only and live in Tooling or Pedagogy.

5. Cards and other "forms" Cards, tables and other "forms" exist in FPF core only as conceptual model, not as data model, thus no need to data-related notation or notation for lint. Comformance checklist and quards is also conceptual, argumentation like "this will ease machine check" is forbidden, no machine checking is intended in core; machine checks and linters live only in Tooling.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

Language and diagrams are tools, not truths. By elevating semantics over syntax, FPF maintains P‑1 Cognitive Elegance and P‑2 Didactic Primacy while safeguarding P‑5 FPF Layering: tooling layers can add new renderers without Core edits.

#Relations

• Parent umbrella: pat:constitution/guard‑rails (E.5)
• Constrains: every normative Core pattern and official alternate rendering
• Instantiates pillars: P‑1, P‑2, P‑5

#E.5.2:End

#Unidirectional Dependency

#Problem frame

FPF separates artefacts into stable Conceptual Core, executable Tooling Reference, and fast‑evolving Pedagogical Companion (see E.4 FPF Ecosystem Family Architecture). If dependencies can point both ways, volatile layers will eventually drag the Core into rapid revision cycles or introduce domain‑specific bias.

#Problem

Architectural gravity: a tutorial or helper script adds a new feature, Core patterns import it “temporarily,” and within months the supposedly timeless layer depends on transient assets—breaking Pillar P‑5 FPF Layering.

#Forces

#Solution — One‑Way, Acyclic Imports

Define a strict partial order over FPF ecosystem families and guard meaning flow (see E.10 V-1): imports point only upward in stability, and no Core semantics may derive from Tooling/Pedagogy. No linters or machine checking in Conceptual Core.

imports is a dependency DAG, not a specialisation relation (normative). Whenever an artefact exposes an explicit imports : [...] list (e.g., SignatureManifest.imports in A.6.0), treat imports as dependency edges governed by this section: the induced imports graph MUST be acyclic (a DAG) and MUST respect the declared direction. imports MUST NOT be used to encode specialisation (e.g., ⊑ / ⊑⁺ between mechanisms); specialisation relations are declared separately via the relevant morphism and specialisation-chain rules (e.g., A.6.1 U.MechMorph).

Pedagogical Companion ⟶ Tooling Reference ⟶ Conceptual Core

1. Allowed edges Dependencies MAY point only upward (toward greater semantic stability). No cycle is ever permitted.

2. No downward import Conceptual Core patterns SHALL NOT import Tooling Reference or Pedagogical Companion family members. Tooling Reference family members SHALL NOT import Pedagogical Companion family members.

3. Future layers Any new family is inserted below an existing one or becomes part of the Tooling or Pedagogy strata; the ordering extends accordingly.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

One‑way import graphs are a proven safeguard in operating systems (kernel vs user land) and layered protocols. Here the rule operationalises Pillars P‑4 Open‑Ended Kernel and P‑5 FPF Layering, ensuring that innovation happens “below” without contaminating the timeless Core.

#Relations

• Parent umbrella: pat:constitution/guard‑rails (E.5)
• References family definition: pat:constitution/fpf-ecosystem-family-architecture (E.4)
• Instantiates pillars: P‑4, P‑5
• Constrains: All artefact imports recorded in DRRs or SCRs

#E.5.3:End

#Cross‑Disciplinary Bias Audit

#Problem frame

FPF calls itself trans‑disciplinary, but every author carries implicit metaphors from a source domain. If those metaphors leak into “universal” patterns, practitioners from other fields disengage or mis‑interpret the rules.

#Problem

Unrecognised bias hides in wording, examples, unit choices or principle weighting. Once embedded in normative language, such bias is hard to remove and contradicts Pillars P‑2 Didactic Primacy and P‑8 Cross‑Scale Consistency.

#Forces

#Solution — Principle‑Taxonomy‑Guided Bias Audit

1. Bias‑Lens set Every normative pattern is assessed through five lenses that match the Principle classes from E.3: Gov, Arch, Onto/Epist, Prag, Did.

2. Equilibrium question For each lens ask: “Does the pattern over‑privilege this class or silence it?” Examples:

   • Over‑reliance on Onto/Epist precision may ignore Prag cost.
   • Dominant Arch metaphors may alienate Did audiences.

3. Scope‑or‑Balance rule

   • If imbalance is found and universality is intended, re‑phrase to restore balance.
   • If imbalance is intentional (domain‑specific pattern), mark the scope explicitly: “Applies primarily to thermodynamic systems.”

4. Audit trace The pattern carries a short Bias‑Annotation paragraph recording which lenses were tested and any scoping statement. No workflow checklists or reviewer metadata or other data and data format and data governance tips is stored in the Core.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

Coupling the audit directly to the Principle Taxonomy keeps the guard‑rail concept‑driven, not workflow‑driven. No mention of review boards, CI‑jobs, or checklists appears in the Core; such mechanics belong in the Tooling Guide. This guard‑rail therefore satisfies GR‑1 (Firewall) while securing Pillars P‑2, P‑7 Pragmatic Utility, P‑8.

#Relations

• Parent umbrella: pat:constitution/guard‑rails (E.5)
• Depends on: pat:constitution/principle‑taxonomy (E.3)
• Constrains: All normative patterns claiming universality

#E.5.4:End

#Didactic Architecture of the Specification

#Problem frame

FPF addresses readers from at least two characteristics of diversity:

• Disciplinary – systems engineers, knowledge scientists, ethicists.
• Experience – newcomers need intuition; experts need rigour.

Past drafts mixed governance mandates with domain examples, producing a steep learning curve and repeated “forward‑reference” detours.

#Problem

If core ideas are buried under formalism or scattered across parts, readers either give up or misuse the framework. We need a didactic macro-order that guides cognitive load from low to high while keeping normative sections discoverable, without letting readers confuse document order with one universal first-practical workflow.

#Forces

#Solution — “On‑Ramp to Archetypes first, Authoring last” sequence

#Document order is distinct from first-practical entry

The macro-order of the document is a didactic scaffold, not a universal practical workflow. Entry navigation publication units such as README, Preface, ToC query cues, E.11 entry-distribution loci, and I.2 expanded entry-disambiguation cases are informative navigation only: they may cross Parts when that is the first honest entry for the question under repair, and they do not create a second normative process history.

The "On-Ramp First" Macro-Structure: The specification is ordered to create a smooth cognitive ramp:

• It begins with an informal, non-normative Preface (The On-Ramp), which uses storytelling and concrete examples (System and Episteme) to build intuition.
• It then proceeds through the normative Parts (A-D), moving from the foundational kernel to the rich patterns of trans-disciplinary reasoning.
• It concludes with the authoring rules (Part E) and appendices, ensuring that this "meta" content does not obstruct the primary learning path.

1. Preface (On‑Ramp) Informal tour; introduces U.System and U.Episteme via concrete stories before any normative language appears.

2. Part A Kernel Minimal holonic ontology and the Transformer principle give readers the essential vocabulary.

3. Part B Trans‑disciplinary Reasoning Tell‑Show‑Show pedagogy: universal rule → Sys‑CAL example → KD‑CAL example.

4. Part C Extension Patterns Domain‑specific calculi expand on the examples already seen.

5. Part D Ethics & Conflict Optimisation Shows reflective patterns only after readers grasp holonic reasoning.

6. Part E Authoring Constitution, guard‑rails, and contributor rules come last; novices can postpone reading.

7. Appendices (Annexes) Tutorials, tooling guides, and migration scripts live here.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

Educational research shows retention improves when abstract rules are immediately paired with contrasting illustrations. By fixing the reading order and mandating Tell‑Show‑Show inside every architectural pattern, FPF embeds pedagogy into its architecture, realising Pillars P‑2 Didactic Primacy and P‑1 Cognitive Elegance without weakening rigour.

#Relations

• Depends on: pat:constitution/guard‑rails (GR‑1 ensures example jargon stays outside Core).
• Constrains: Placement of all Parts, patterns, and appendices.
• Instantiates pillars: P‑1, P‑2

#E.6:End

#Archetypal Grounding Principle

#Problem frame

Universal rules are powerful only when readers can grasp them. In FPF the Conceptual Core speaks in substrate‑agnostic language: U.Holon, Γ‑aggregation, MHT emergence. Practitioners need to “see” those rules in familiar matter—physical hardware or bodies of knowledge—before they can reuse them.

#Problem

A purely abstract statement risks two failures:

1. Didactic failure – readers dismiss the pattern as “too meta,” violating Pillar P‑2 Didactic Primacy.
2. Unproven universality – without cross‑domain instantiation the rule remains an untested claim.

#Forces

#Solution — mandatory Archetypal Grounding subsection

Every architectural pattern SHALL include a dedicated section, titled exactly “Archetypal Grounding,” that shows how the abstract law SCRs in FPF’s two canonical holon flavours:

1. U.System – the archetype of a physical, operational holon.
2. U.Episteme – the archetype of an abstract, epistemic holon.

This enforces a repeatable Tell‑Show‑Show rhythm:

#Archetypal Grounding (of this pattern itself)

#Conformance Checklist

#Consequences

#Rationale

Tell‑Show‑Show is a proven pedagogical sequence. By making it normative, FPF hard‑codes P‑2 Didactic Primacy into the fabric of every architectural pattern while still honouring P‑1 Cognitive Elegance—the grounding section replaces brittle ad‑hoc anecdotes with a disciplined dual example. Linking scope‑justification to the five Principle lenses ties the pattern to the Taxonomy‑Guided Bias Audit and keeps governance language out of the Core.

#Relations

• Implements macro flow: pat:authoring/didactic‑architecture (E.6)
• References base types: pat:kernel/holon (A.1) (U.System, U.Episteme)
• Interacts with bias guard‑rail: pat:guard/bias‑audit (E.5.4) via CC‑AG.3
• Constrains: Authoring template in pat:authoring/pattern‑template (E.8)

#E.7:End

#FPF Authoring Conventions & Style Guide

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative)

#Use this when

Use E.8 when you are writing, revising, or reviewing one FPF pattern and need to know what shape, voice, reader-recognition role, and assurance material the pattern must carry before it can be treated as mature FPF text.

Use it especially when a draft is technically correct but hard to use: the cold reader cannot tell when to apply it, what action to take, what mistake that action prevents, which related pattern governs a specific outside claim, or which assurance material is informative rather than the first user-facing guidance.

Not this pattern when. Use E.9 when the main work is deciding why FPF should change and how that decision is distributed across patterns. Use E.19 when the main work is an admission or refresh review. Use the local domain pattern when the question is what FPF says inside that domain rather than how a pattern should be authored.

#What goes wrong if missed

A pattern can satisfy a checklist and still be practically unreadable. It may open with package architecture instead of a recognisable working moment, bury its payoff, hide the pattern that governs a specific outside claim, or let assurance prose silently replace the reader-facing claim. The result is a formally neat text that authors can defend but practitioners cannot reliably use.

#What this buys

E.8 gives FPF authors one shared pattern shape and one shared authoring discipline: recognition text first, assurance text second, canonical sections present, terminology kept stable, SoTA used as current practice grounding rather than decoration, and practical consequences visible before a reader has to reconstruct the architecture.

First useful move. Put the working situation, first action-guiding move, practical payoff, ordinary boundary, and nearest heavier assurance condition into the recognition text before tightening template details or conformance material.

Cheap stop. If the draft already gives a cold reader the working situation, first useful move, practical payoff, ordinary boundary, and nearest heavier assurance condition, do not add more authoring apparatus just to look mature. Use conformance material to verify that guidance; do not let it replace the guidance.

FPF-governed wording extension. Add heavier assurance, conformance, SoTA grounding, relation material, or related-pattern material only when the light recognition text would leave a false claim, unstable primary EntityOfConcern, hidden governing pattern for a specific claim/relation/boundary, unbacked practical payoff, or misleading admissible use.

When an authoring pass claims quality improvement rather than ordinary drafting, keep these roles distinct: E.22 frames the improvement-oriented quality-evaluation question, the object-under-improvement evaluation such as E.21 or E.9.DA supplies value meanings and stop meanings, C.16.Q repairs overloaded quality and evaluative-characterization wording, C.25 carries engineering quality-family endpoints when those endpoints are claimed, and E.23 governs any repeated quality-improvement method. Closing checklist rows or satisfying a review profile is not by itself quality improvement.

When a pattern claims practical payoff or uses a score, coordinate value, checklist result, benchmark, projection signal, review result, or release posture as evidence of value, name the intended value and the visible proxy relation. If the visible proxy is being treated as the value itself, apply E.13 and repair the proxy-to-value substitution before the payoff claim is admitted.

Quality/projection evidence placement. Pattern-quality status, corpus projection, README/ToC/E.11/I.2 alignment, card/retrieval evidence, cold-reader evidence, monolith parity, landing evidence, developer/reviewer/executor correspondence, and other quality-carrier facts belong in the evaluation result, review run record, projection carrier, or release/landing evidence carrier. They do not belong anywhere in the pattern itself, including notes, appendices, Relations, Rationale, SoTA-Echoing, examples, tables, and checklist rows, unless the pattern's own EntityOfConcern and intended-reader move are that evaluation/projection work. This is a role test, not a lexical test: the same word may be user-facing content in an evaluation pattern and carrier leakage when it reports quality, landing, projection, or role-turn state for this pattern.

Pattern roles across coupled flows. In authoring guidance, speak at the pattern level. One pattern may be the pattern of concern for different roles in different flows: an author repairs it, E.21 evaluates it, E.19 admits or refreshes it, a practitioner selects and uses it, and a later evaluator may reopen it. Those flows may be joined in one TransformationFlowStructure through transfer, feedback, return, projection, landing, edition-change, or repair relations, but their roles and EntityOfConcern assignments stay distinct. The pattern itself also carries its own primary EntityOfConcern: the subject its Problem/Solution/guidance is about. Development-flow evidence may cause rewrites, but reviewer/executor exchange, status, projection proof, landing proof, and use-found evidence remain in their carriers rather than entering the pattern as if they were guidance for the intended reader. This is the pattern-authoring instance of the broader transformation-flow and P2W coupled-flow rule: a publication, principle scheme, work plan, or self-evolving specification flow may help create or govern later work without becoming the performed work, project evidence, gate passage, assurance, edition bump, or applied-edition content.

Maturity rule. Section completeness is not pattern maturity. A pattern matures when its Problem frame, Solution, worked cases, boundaries, and conformance checks all point to the same usable action guidance.

Primary EntityOfConcern in plain terms. The primary EntityOfConcern of E.8 is the authored FPF pattern: its canonical sections, reader-recognition role, wording discipline, examples, rationale, anti-patterns, SoTA-Echoing, and relations.

Primary working reader. The first reader is an FPF author or reviewer shaping pattern prose for later practitioners and managers. The downstream practitioner is the reader the pattern must ultimately serve, so the authoring guide must model the same recognition discipline it requires.

#Pattern Kind In Plain Terms

An FPF pattern is an action-guiding method description for a recurring working situation. It is applied by an intended FPF user who recognizes the situation, understands the problem and forces, and then uses the Solution to decide what to do, what to stabilize, what to avoid, and what practical change should follow.

Pattern application is the user-side act: the user recognizes the working situation, applies the pattern, and uses the Solution to shape the next admissible move. Its Problem frame, Problem, Forces, Solution, Consequences, worked slices, and anti-patterns carry the guidance. Its Conformance Checklist checks whether that guidance has been applied and authored correctly; it must not replace the Solution or turn the pattern into a control form.

The primary content-bearing job is constructive method guidance: the pattern must say what the user should do so the recurring error does not arise. Error prevention, auditability, and conformance checks are evidence that the guidance is usable; they are not the pattern's center. The first substantive content in the opening Problem frame and Solution must be a positive subject spine: the primary EntityOfConcern kind, the first admissible action-guiding move, the practical delta, and the few boundaries needed for that first move. The text must not replace subject content with repeated guards, distinctions, related-pattern mappings, references, mini-rules, definitions, caveats, architecture rationale, or quality/projection evidence unless the repetition adds a new local action, case, evidence value for the user, or first-reading recognition need. Copying distinctions owned by other patterns into this pattern as repeated "do not confuse our EoC with their EoC" prose is the same repetition problem. Boundary doctrine is pattern content like any other doctrine: if strict distinction, non-use, ToC navigation, or the governing pattern for a claim/relation/boundary already carries the distinction, do not repeat it locally. Use one short pattern id or governing-pattern statement when needed. Add local boundary prose only when it states a documented local confusion and exact stop condition that the owning pattern does not already carry. The repair is to say clearly what this pattern's own EntityOfConcern is, not to enumerate the unbounded set of other things it is not.

The same rule blocks pattern-application drift for any FPF object, not only for patterns. Name the object by its FPF kind when the kind is known: a pattern is a pattern, a claim is a claim, a relation is a relation, a row is a row, a source is a source, a publication is a publication, a WorkPlan is a WorkPlan, and so on. FPF patterns are applied to situations, claims, texts, or work objects. Use governing pattern only in the typed form governing pattern for <claim/relation/boundary> when one pattern actually governs that specific item; use related pattern for a looser pattern relation; use relation only for the relation itself. A compact pattern-reference sentence should be declarative: this pattern applies to <situation/claim/object>, this claim is governed by <pattern id>, this relation is recorded in Relations, this entry cue belongs in README, ToC, E.11, I.2, or a retrieval/projection carrier, or this pattern application stops under <condition>. Relations are positive claims, not catalogs of absent relations. Detailed discoverability belongs in README, ToC query cues, E.11, I.2, or retrieval/projection carriers; compact related-pattern statements belong late in Relations after the positive subject/action spine. Ordinary references use ordinary reference apparatus: a pattern id in prose, a citation, Builds on, Coordinates with, Relations, ToC, README, E.11, or I.2. They are also not repeated as many conditional sentences or small variants when one compact definition, boundary, table, Relations, ToC, README, E.11, I.2, or retrieval/projection locus already carries the same content family.

Treat precision-restoration problems in pattern prose as one profile with five layers: word/head/use precision, phrase apparatus, repetition/distribution, role/carrier separation, and pattern application. Do not add a local row for each new symptom. E.8 requires the author to keep the positive subject/action spine first; F.19 repairs phrase-level apparatus; E.10, E.10.ARCH, F.18, or the governing pattern repairs remaining word/head/use precision; E.21 measures the collapsed effect on pattern quality.

A wording cleanup is kind-preserving by default. Before an author accepts a changed FPF-governed phrase as a repair, the pre-repair and post-repair EntityOfConcern, kind, relation or claim kind, slot or use-position, admissible use, and scope must be recoverable when those items are live. This is a bounded complete preservation check, not an order to formalize ordinary prose or unchanged text and not permission to choose "no edit" as the easy minimum. Leaving text unchanged closes only when the phrase is not triggered, ordinary prose, or already satisfied by value with loci; otherwise the finding remains open. Removing a trigger word or replacing a generic head is not a repair when it changes the ontology: for example, a graph-shaped method cue must not be narrowed into a work sequence unless an accepted decision explicitly changes the kind and consequences. If a relation, signature, mathematical-lens, role, method, work, or evidence position is live, the author cites the governing pattern for that position instead of restating its ontology in E.8. If the phrase hides several kinds, split them or send the decision to the governing pattern or DRR; do not flatten them into one cleaner-looking word.

For apparatus-overwrap, follow F.19. E.8 adds only the pattern-authoring placement rule: after boilerplate apparatus is removed or moved and remaining content is precision-restored under E.10, E.10.ARCH, F.18, or the governing pattern when needed, pattern prose keeps only the intended user's admissible move and boundary. Process, architecture, review, quality, projection, and release evidence stay in their own carriers unless they are rewritten as that user-facing move.

When an action-adjacent pattern classifies wording, a name, a publication face, an explanation class, a comparison unit, or another semio-facing object, that classification is only useful if it connects back to action guidance. The pattern must say what use or action is admissible now, what related use or action is not admissible under the current pattern, and which FPF pattern governs the case when the claim is a work, evidence, gate, decision, assurance, engineering-justification, release, or reliance claim.

Semio-Echoing is admissible only as a trigger-controlled auxiliary placement. Use it when E.10, C.2.P, or E.10.ARCH has exposed a wording-use overread whose EntityOfConcern, episteme/publication stack, alignment path, and remaining admissible reader move are recoverable by value. Do not add it as a generic warning block. In non-semio patterns the primary content remains the pattern's own EntityOfConcern and admissible move; semio material stays as a thin cue, related-pattern relation named by value, local recovery line, or named description and publication-use boundary section unless it changes that move or blocks a documented overread. If the material mainly says that a description, view, publication, record, card, diagram, source, or file is not a permission, promise, prescription, evidence item, assurance verdict, decision, gate passage, release, work occurrence, or authority source, keep it out of the subject Solution and put it in that boundary section or in the exact description-publication pattern.

#Problem frame

FPF grows through the addition of patterns written by authors from many disciplines. Without a shared structure and voice, the framework would fracture, violating Pillars P‑1 Cognitive Elegance and P‑2 Didactic Primacy.

#Problem

Structural drift and stylistic fragmentation threaten three qualities:

1. Comparability – readers cannot align patterns lacking common headings.
2. Narrative cohesion – prose swings from dry jargon to informal blog style.
3. Reviewability after guidance – missing sections hide boundary and assurance checks (Archetypal Grounding, Bias‑Annotation) that let reviewers verify the action guidance without replacing it.

#Forces

#Solution — One template, enriched by style principles

#Canonical Pattern Template

Within each pattern, the canonical section headings SHALL appear in the order below. For each canonical content section heading (1–12), the <Title> component (after the heading separator, e.g. -) MUST start with the canonical section title (case-insensitive match; canonical capitalisation preferred); an optional clarifier after an em dash is allowed (e.g., Solution — …). The Footer marker (section 13, if present) is a sentinel and is governed by H-9 rather than the standard <FullId> - <Title> shape.

Extensibility. Authors MAY add additional sections. Prefer expressing them as subsections under the nearest canonical section (e.g., 4.1, 4.1.1 under Solution). If an additional pattern-level section is necessary, it MUST NOT delete or reorder the canonical sections and its title MUST NOT shadow a canonical title.

Mandatory vs optional.

• Canonical sections 1–13 are mandatory in every pattern.
• Canonical sections carry content. Authors must not use omission placeholders as section substitutes; when a section is intrinsically small, write the smallest content-bearing grounding, misuse, boundary, or reduced-case statement that preserves the section's role.
• First substantive authoring seed. The first non-empty authored body of a pattern SHALL already instantiate the canonical section frame by value: title line, header block, canonical sections 1–13, and the footer marker.
• Recognition-role openings and first-minute working guidance belong inside that canonical frame. Any retained pre-template entry material must also stay inside that same canonical frame rather than appearing as one pre-template opening memo. Authors MUST NOT seed one pre-template opening memo and postpone canonical sectioning, Conformance Checklist, or footer-marker installation to one separate E.19, assembly, or review-repair pass.

Template:

• Title line: Hashes + FullId + - + Pattern Title; optional (informative) note.
• Header block: Type, Status; optional Normativity override.

1. Problem frame
2. Problem
3. Forces
4. Solution
5. Archetypal Grounding (Tell-Show-Show; at least one content-bearing grounding slice, reduced grounding case, or ordinary/non-use boundary)
6. Bias‑Annotation
7. Conformance Checklist
8. Common Anti‑Patterns and How to Avoid Them (at least one local misuse, overread, or exact boundary case; no placeholder)
9. Consequences
10. Rationale
11. SoTA-Echoing (post-2015 practice alignment; terminology drift and deltas; full comparison or reduced SoTA required whenever external or internal practice changes the Solution)
12. Relations
13. Footer marker

Footer marker. End each pattern with a single visible sentinel heading line by itself: ### <PatternId>:End. This makes truncation detectable even when HTML comments are stripped or surfaced by editors. The footer marker is intentionally content‑free: do not place prose under it.

Note. Pattern boundaries are still parseable by scanning for the next pattern heading (## …), but an explicit :End marker helps retrieval pipelines (and LLM prompts) distinguish “this chunk is the whole pattern” from “this chunk was cut mid‑pattern”.

#Heading & ID discipline (human tooling + retrieval)

FPF is often consumed through full‑text search and retrieval (RAG). A reader or an LLM may see a subsection without its parent headings, so headings must be self‑identifying.

H-1 (Heading shape). Every pattern heading and every subsection heading inside a pattern SHALL follow: <hashes> <FullId> - <Title> (optional note of non‑normativity)

Exception. The Footer marker is a sentinel heading and is governed by H-9, not by the standard <FullId> - <Title> shape.

H-2 (Heading separator). The canonical separator between <FullId> and <Title> is - (ASCII, space-hyphen-space). Previously authored text may use Unicode dash variants such as – or — as separators; tooling SHOULD treat those variants as migration candidates, and authors SHOULD migrate touched headings to -.

H-3 (FullId). FullId is the full hierarchical address. For a pattern heading it is the pattern ID (e.g., A.2, E.10.D1). For headings inside a pattern, append dot‑separated ordinal section numbers after the colon (:) (e.g., A.2:4.4, E.10.D2:3). Exception: the Footer marker uses the reserved sentinel token :End as defined in H-9. The colon (:) is reserved for section paths and MUST NOT appear in pattern IDs.

H-4 (Ordinals). Ordinals in section paths SHOULD track the canonical template numbering (1 = Problem frame, …, 13 = Footer marker) to maximise cross‑pattern comparability. During refactors or in previously authored patterns, ordinals MAY be local. In that case, the canonical section title at the start of <Title> is the semantic key; readers and tools MUST NOT infer section semantics from the ordinal alone. Note: the Footer marker itself is exempt from ordinal encoding; it uses the reserved token :End (see H-9).

H-5 (Where kind and normativity are declared). Pattern kind (e.g., Architectural / Definitional) MUST be declared in the Header block, not encoded into the heading text. Normativity (normative / informative) MUST also be declared in the Header block when it deviates from the default. If a reminder is needed for readers, authors MAY add a short parenthetical note at the end of the heading (e.g., (informative) / (non‑normative)), but headings MUST NOT use square‑bracket tags.

H-6 (Heading levels). Heading levels MUST preserve a fixed offset between structural layers (Part or Cluster (flat) → Pattern → Pattern sections):

• Part and Cluster headings MUST use # (level 1) across the file.
• A Pattern heading MUST use ## (level 2).
• Inside a pattern, each nested section MUST add exactly one # per level (e.g., ## A.2 - …, ### A.2:2 - …, #### A.2:2.1 - …).

H-7 (Ellipsis discipline). Authors MUST NOT use three consecutive full stops/dots (...) as punctuation in headings or narrative prose. Authors MUST use the Unicode ellipsis … (U+2026) instead. For editorial elisions in quotations, authors SHOULD prefer […] to make the omission explicit and distinguish it from retrieval truncation. Exception: literal three‑dot sequences that are part of an external language’s syntax MAY appear only inside code spans or fenced code blocks.

H-8 (Normative keywords). The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119, as clarified by RFC 8174 (only when capitalised). Authors SHOULD avoid informal deontic phrasing (“need to”, “is required to”) in normative clauses.

Deontics vs admissibility. Use RFC keywords only for deontic obligations (requirements on authors, reviewers, implementers/tooling, or published pattern or companion texts) — i.e., things an agent can choose to do or omit. Do not use RFC keywords to state definitions, structural invariants, typing rules, or other admissibility conditions of the modeled world.

When you need an enforceable constraint that is mathematical rather than deontic, express it as a non‑deontic predicate using one of: Definition:, Invariant:, or Well‑formedness constraint: (optionally with formal quantifiers). Prefer mathematical terms like cardinality 1..1 (total) / 0..1 (partial) / 0..n over deontic adjectives like “mandatory or optional” when the intent is cardinality, not duty.

Admissibility predicate discipline (recommended shape). When expressing admissibility/validity constraints as predicates (Definition: / Invariant: / Well‑formedness constraint:):

• Authors MUST NOT use RFC keywords inside the predicate block.
• Authors SHOULD give each predicate a stable identifier and short name (e.g., RA‑1 (Locality), RE‑3 (Method gate)), so that Conformance Checklist items can reference it without re‑authoring the rule.
• Authors SHOULD write the constraint as a declarative predicate (optionally quantified), e.g., role ∈ Roles(context), rather than as “X MUST …”.
• If the constraint needs to be checked as part of pattern conformance, authors SHOULD reference the predicate identifier from the Conformance Checklist (and/or call out validator behaviour), rather than duplicating the predicate with RFC keywords.

H-9 (Footer marker sentinel). Footer marker SHALL be a single heading line whose FullId is the pattern ID followed by the reserved sentinel token :End (no ordinals, no title, no square‑bracket tags): ### <PatternId>:End It is the only allowed heading inside a pattern whose section token is non‑numeric. It MUST be the final line of the pattern and MUST NOT carry any prose. Tooling and readers MUST treat it as a boundary sentinel, not as a semantic section.

Unification note: historic A‑ and D‑templates differed only by the presence/absence of Bias‑Annotation and Relations; the unified template keeps the headings everywhere and requires every heading to carry content-bearing grounding, boundary, consequence, rationale, source-use, relation, or reduced-case material rather than an omission placeholder. The Alexandrian pattern canon historically calls Problem frame “Context”. FPF avoids that label because Context is already overloaded in FPF (e.g., U.BoundedContext and its Plain‑register label).

#Stylistic Principles (S-0 ... S-19)

Authors use the principles as a scaffold, not a straitjacket: the goal is coherent, engaging insight. Engagement remains subordinate to semantic discipline: hooks, quotable lines, Plain restatements, and didactic images may improve recognition, but any ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim kind or admissible-use boundary they carry must be recoverable through the governed Tech reading or named neighboring pattern. Ordinary Plain prose without that claim kind or admissible-use boundary stays ordinary prose.

S-0 (Narrative Flow Seven-Step Heuristic) — explanation Narrative flow is recommended to follow these steps: Hook -> Frame -> Weave -> Ground -> Bridge -> Flow -> Close.

Brief explanations:

Narrative Flow Heuristic also operationalises S-1 (Density w/o Jargon), S-2 (Internal Cohesion), S-4 (Contextualisation), and S-6 (Quotable Closers).

#Recognition text and assurance text

Every canonical pattern SHALL stabilise one primary EntityOfConcern, relation record, or claim record early enough that a cold reader can tell what kind of thing the pattern is actually governing. If ordinary forms vary (note, sheet, guided UI, rendering, review aid), the text must make explicit which of those are merely presentation forms of one primary selected EntityOfConcern, relation, or claim and which would instead name a different act, process, work-result record, or governing companion. Recognition and assurance texts may refine that selected item differently, but they must not silently swap the central kind.

If a pattern uses a broad umbrella or head together with a narrower operative branch, the text must also make the stack explicit early enough for first reading: what the broad head names, what the current narrowed branch is, what primary EntityOfConcern, relation record, or claim record is actually in play, what move is being carried by that object, and what wider work or process remains outside the pattern. A qualifier alone does not restore that stack.

Under F.18 local-first naming, the canonical pair here is recognition text and assurance text. The earlier provisional recognition shell / assurance shell wording is retired. These names refer to two reading-order roles carried by existing sections or projections inside one pattern; they do not mint new authoritySourceRef targets, governing-pattern relations, publication-form/face kinds, publication-face kinds, or a second face family. A third didactic-content role remains optional and is justified only when the family is especially easy to misuse, easy to over-read, or hard to teach without extra scaffolding.

The recognition text is the first-reading text. It is the part of the pattern that lets a cold working reader recognise the situation quickly enough to decide whether to keep reading. It should start from a subject-domain or practice moment before internal taxonomy whenever the pattern is meant to help real work rather than only internal canon maintenance. In practice it usually appears in an early Use this when line or equivalent opening, plus the upper parts of Problem frame, Problem, Solution, Consequences, and nearby worked slices. Its job is to make visible:

• what ordinary working situation this pattern is for;
• what goes wrong if the pattern is missed;
• what the pattern buys the reader in practice;
• when this is not the right pattern;
• what primary EntityOfConcern, relation record, or claim record is actually being kept stable;
• and, when technical terms must appear early, a pairwise plain gloss for each early FPF-governed technical term.

The assurance text is the second-reading text. It carries the heavier FPF-governed material that makes the pattern reviewable and auditable:

• declaration blocks and typed fields when those are part of the pattern's declared conformance or boundary claim;
• representation ontology, EntityOfConcern discipline, or primary-EntityOfConcern discipline;
• any minimal modeling or mathematical lens that keeps the primary EntityOfConcern, relation record, or claim record stable;
• guidance/check, invariants, admissibility, and stop or neighbouring-pattern conditions;
• SoTA-Echoing when it carries explanatory work;
• and the review hooks that let a broader or more consequential interpretation or use be checked explicitly.

The assurance text may sharpen, justify, and discipline the recognition text. It must not silently replace, strengthen, or universalize the claim that the recognition text made visible. If the recognition text says “this pattern helps with a bounded working situation”, the assurance text must not quietly turn that into an unbacked carrier claim, unbacked guarantee, or broader universality claim.

If a pattern claims universal or transdisciplinary status, that claim must already be visible in the recognition text. It is not enough for universality to appear only later in a guidance/check sheet, declaration block, or SoTA-Echoing rationale. A broad claim should therefore be demonstrated in the recognition text through at least three heterogeneous reader or domain situations. When a compact matrix helps, F.16 is the preferred template for showing that breadth. If SoTA-Echoing carries an FPF-governed claim, the practical implication of those rows should be recoverable from the recognition text and case bank rather than remaining a late-only justification layer.

A third didactic-content role means enough didactic and operational content that the pattern survives without nearby project documents. Typical indicators include:

• at least one concrete source and resulting-publication slice in Archetypal Grounding when the pattern governs transforms or publication change;
• at least one boundary-heavy example or anti-example when nearby patterns or other governing companion roles are easy to confuse;
• reviewer guidance that tells what to inspect first and which neighboring FPF pattern governs the failure mode and which project-side FPF kind and reference named by value carries the claim or effect;
• local mini-definitions or glossary material for recurring terms that would otherwise be recovered only from project context.

Pattern density is therefore not “more metadata” and not “longer tag lists”. It is the presence of enough recognition, assurance, and, when needed, extra didactic material that a reader can understand the pattern, apply it lightly in ordinary cases, and recognise when a heavier review path is required.

#Package-form and governing-pattern relation role-word discipline

FPF pattern prose is not free-form descriptive English. When authors name a package-form or a governing-pattern relation, they must use role words with stable semantic intent.

Use the following distinctions explicitly:

This is a cross-cutting review discipline, not a replacement for local pattern lexica. For example, A.6.7 / A.19.CHR already carry the suite/kit/pack distinction, and E.17.1 already carries the viewpoint bundle/family/library distinction.

• governing pattern = the pattern that carries the primary guidance/check authority of the family;
• specialization = a named refinement under an existing governing pattern;
• overlay = a cross-cutting governance role or reading-order projection over existing governing patterns;
• profile = a declarative review/use role derived from a governing pattern rather than a replacement pattern;
• family = a recurring class of cases governed by one pattern or governing companion;
• bundle = a packaged set of defaults, allowances, or coordinated members;
• cluster = a navigation or reading-order grouping; not by itself a governing-pattern claim;
• suite = a coordinated set of members with explicit suite semantics under the governing FPF pattern or named authority reference;
• pack = an editorial or review grouping, not automatically a semantic-authority claim;
• kit = a reusable coordinated publication or boundary-description package with kit-level semantics under the governing FPF pattern or named authority reference;
• record = a case, report, or review record;
• umbrella = a provisional or review-stage head spanning possible subfamilies before a final governing FPF pattern, accepted DRR, or pattern-body decision.

These words are not interchangeable. In particular, authors must not let cluster, bundle, suite, family, profile, overlay, or umbrella do the work of an unnamed governing-pattern relation. When that relation matters, it must be stated directly: specialization under ..., profile governed by ..., overlay over ..., bundle under ..., or another equally explicit formulation.

A pattern may reuse a pattern-native role word when that role is already defined by the governing pattern. Outside that case, authors must not improvise near-synonyms or shift between role words for stylistic variety.

#Precision-restoration placement discipline

When a pattern or companion text is drafted from E.10 or E.10.ARCH, distinguish two authoring objects:

• semanticArea is the Part-F semantic unit for a wording-use restoration row: one Concept-Set row, one UTS row, or an explicitly bounded row-set. It is declared with semanticAreaBaseConcept and semanticAreaSenseFamily.
• ontologicalNeighborhood is the applicability neighborhood around that named semanticArea: nearby primary EntityOfConcern kinds, relation kinds, claim records, governing FPF patterns, non-use boundaries, and remaining reader move that can carry the recovered meaning after the wording is repaired.
• pattern nest is the publication and specialization placement of a pattern under its governing pattern family.

These are not synonyms. A precision-restoration pattern is placed in the pattern nest whose primary EntityOfConcern, relation record, or claim record it repairs. Its semanticArea states the Part-F semantic unit it repairs, while its ontologicalNeighborhood may name several relation governing the asserted uses. For example, quality-term repair lives in the C.16 characterization nest, even though its neighbouring relations can include relation construction, action invitation, evidence, assurance, source-use assignment, engineering quality bundles, pattern-quality evaluation, or mathematical-lens use.

Affected patterns should use a thin pointer when the first-stage wording repair belongs elsewhere. The pointer names the selected restoration pattern and the condition that triggers it; it does not copy the trigger registry, the full E.10.ARCH recovery algorithm, or a second local architecture for the same repair. The affected pattern then keeps its own subject matter: the characteristic, structure, view, episteme, relation, evidence, assurance, gate, work, decision, or adequacy question it already governs.

If a draft proposes a new precision-restoration pattern, the authoring claim must show the repeated wording failure, semanticAreaBaseConcept, semanticArea, semanticAreaSenseFamily, the recovered primary EntityOfConcern kind or relation/claim record, the intended pattern nest, the neighboring governing relations, and the admissible action left after repair. A new pattern is not justified merely because a word appears often, because a local checklist wants a bucket, or because a campaign needs a tidy grouping.

#Reader-role discipline for pattern prose

A pattern is written for its intended FPF user: the person who will use the pattern to organise thought, inspect a case, publish a note, or review a result under that pattern. Its FPF-governed sections therefore explain what the pattern lets that user do, what it forbids, what it costs, and how it relates to neighbouring patterns in user terms. When neighbouring patterns or other governing companion roles are named, the prose should answer one user question such as which neighboring FPF pattern applies, which project-side FPF kind and reference named by value carries the claim, which nearby pattern is easy to confuse, or what must stay coordinated here; it should not read as one explanatory aside about why the package architecture was split that way. E.8 reader and reviewer wording is FPF pattern-authoring wording. Project-side publication readers, explanation readers, comparative review units, and participants in named project-side review relations are governed by the publication or project-side patterns that name those publication units, explanation-use relations, comparative review units, evidence paths, work records, or gate records, such as E.17, E.17.ID.CR, E.17.EFP, A.10, A.15.4, A.20, or A.21.

Authors must keep FPF-development or package-architecture material separate from that user-facing body. In particular, Problem, Solution, Consequences, Rationale, worked slices, and ordinary-vs-FPF-governed wording guidance must not do the work of:

• arguing that the material is worth isolating;
• justifying overlay/profile/governing-pattern or authority-reference choice as a package decision;
• discussing authority-reference freeze, naming freeze, merge state, blast radius, or safest landing form;
• or narrating future package promotion or defer decisions.

If architecture-placement commentary is still helpful, the default place is a separate companion note or ADR-like architecture note. A pattern may include a short optional informative subsection such as Architectural placement note (informative) only when that placement materially helps users avoid misuse; even then, it must stay clearly separated from the user-facing solution and rationale rather than replacing them.

#Human-facing fit beyond role correctness

Human-facing fit is also subject-domain fit. A recognition text that starts from internal taxonomy, pattern-placement convenience, or package-architecture wording before the problem-domain moment is still under-authored even if its later guidance/check text is correct. When a broader umbrella name and a narrower operative branch are both used, the recognition text should also tell the reader which stack is actually active rather than leaving that reconstruction to a later declaration block or companion note.

A pattern can already be role-clean, boundary-clean, and reader-role-clean, yet still fail the first minute of use for a cold working reader. That failure usually appears when the text is admissible but does not yet make the working situation, practical payoff, primary EntityOfConcern, non-use boundary, or first action-guiding move visible enough.

P-2 epistemic precision check. When E.10 selects epistemic precision restoration for pattern prose, the first admissible action-guiding move must survive as a remaining admissible reader move or be replaced by an neighboring FPF pattern governing that claim application that now carries that claim. This is a direct E.2 P-2 and E.12 requirement, not an optional style preference. Intentional didactic metaphors and vivid Plain recognition lines are admissible when they are ordinary recognition aids or when their claim kind or admissible-use boundary maps back to Tech under E.10:6.2. A precision-corrected rewrite that leaves the recognition text inert is still under-authored.

For canonical patterns, the first-reading text should behave as a recognition text and the heavier review/check scope should remain in an assurance text.

When a pattern claims practice guidance or is meant to be used by engineers, managers, researchers, or other working readers, authors should make the following visible before the heavier harness takes over:

• a recognisable Use this when or equivalent first-minute recognition cue;
• a concrete working situation in Problem frame, not only taxonomic or pattern-placement language;
• a short statement of what goes wrong if the pattern is missed or misread;
• a short statement of what this pattern buys the reader in practice;
• the first admissible action-guiding move the user should take in that situation;
• a short Not this pattern when boundary for ordinary nearby non-use cases;
• one minimally viable worked case or use slice that shows what changes in practice;
• when a typed declaration block, formal lens, or other compact modeling material is FPF-governed, a short user-facing statement of what kind of object the pattern is governing and what minimal lens keeps that object reviewable;
• pairwise plain glosses for any FPF-governed technical terms that must appear before the heavier declaration role arrives;
• when SoTA-Echoing carries explanatory work, a short working-reader implication for each row or cluster of rows and a visible link back to the case bank or worked slices that those rows discipline;
• a visible split between the recognition text and the heavier assurance text or companion material;
• and, if the draft implicitly serves several working-reader situations, an explicit primary working reader, primary concern, or primary viewpoint.

Problem-frame recognition signature (informative). A canonical pattern should expose the working situation through its Problem frame, not through one separate navigation block. When an E.11 pattern-entry discoverability problem is present, the same Problem frame may also carry candidate-pattern and tempting-wrong-pattern cues; otherwise it should stay with action guidance rather than becoming a local catalogue row.

The local recognition signature should make recoverable:

• the concrete working situation;
• the primary EntityOfConcern, relation named by value, claim record, or stabilized concern;
• what goes wrong if the pattern is missed or misread;
• the first admissible action-guiding move and what that move buys;
• the ordinary not-this-pattern boundary;
• the first admissible action-guiding result; when an E.11 discoverability problem is present, the first admissible entry stop or entry-stabilizing result.

Use this pattern when, This pattern applies when, or equivalent Problem frame prose may be used as the first sentence or compact cue of this signature. It is not one separate required section. Compact candidate-pattern comparison belongs in E.11-distributed entry material; expanded entry-disambiguation cases belong in I.2.

If the prose points to neighbouring patterns or other governing companion roles, it should present them as neighboring FPF patterns, project-side FPF kinds and references named by value, or E.11 entry-recognition reclassifications rather than as hidden co-authorities of the current pattern.

If the pattern claims broad, universal, or transdisciplinary usefulness, that breadth should already be visible in the recognition text. At minimum the recognition text should show at least three heterogeneous reader or domain situations rather than one narrow case family with a later broad claim attached. When a compact matrix helps, F.16 is the preferred template for making that breadth legible.

This is not a request to flatten the pattern into plain language only. It is a rule about ordering, assurance depth, and text consistency: the recognition text must help a working reader recognise the pattern early, while the assurance text continues to carry the full claim kind or admissible-use boundary. If the pattern uses technical lexicon, ontological distinctions, or a mathematical lens, those structures must remain recoverable, but the first-reading text should not require the reader to decode that full stack before recognising the working situation. The assurance text may tighten or discipline the recognition text; it must not silently shift what the recognition text claimed.

Illustrative migration example (informative).

Old pre-template top:

Start here when the dominant question is API, protocol, SLA, published boundary, or compliance wording.
First output: Claim Register.
Neighboring pattern relations / entry-recognition reclassifications: A.6.B, A.6.C.

Repaired Problem-frame recognition signature:

Use this pattern when boundary-facing language - API, protocol, SLO/SLA, compliance clause, or other published boundary description - mixes guidance/check clauses, admissibility gates, duties, and evidence into one sentence or published boundary description.

If missed, the text becomes boundary-claim soup: runtime behavior, governance, and evidence are treated as one undifferentiated promise.

Do not use this pattern merely because the text mentions an API or boundary description. If the question is still one unstable cue, preserve it through the admissible cue-preservation line first.

First admissible action-guiding result: one `A.6.B`-governed atomic claim set or one Claim Register whose claim/use questions are explicit enough for the governing FPF pattern or named project-side FPF kind and reference to inspect.

#Design-time and run-time referents stay separated in pattern prose

Pattern prose must keep its referent index explicit. In ordinary body sections, the default truth-makers are run-time or governed-domain objects, states, moves, boundaries, consequences, and user-facing practical effects. Normative-standard wording is still admissible when the sentence is explicitly about the standard as a normative publication, for example in marked migration navigation examples, marked informative notes, or conformance/checklist clauses.

Design-time and development-state referents are different objects. The current draft, current body, current pass, author, reviewer, handoff, packet, governing companion, landing choice, or other writing-process objects must not be smuggled in as the hidden truth-condition of pattern prose. A quick test is: what makes this sentence true? If the sentence is true because the current text is arranged a certain way, because the author or reviewer must do something next, or because the current development state says so, then it is design-time residue, not pattern content.

Move that material to the authored-slice carrier, handoff, DRR, or companion architecture note. If a sentence is kept in the pattern, rewrite it so that its truth depends on the governed run-time/domain object or on the standard's declared normative claim set rather than on the current writing pass. If a pattern or example claims autonomy for any Role/Method/Service:

1. Add a subsection “Autonomy (RoC‑E.16)” that lists:
   • AutonomyBudgetDeclRef (id, version, Scope (G), Γ_time),
   • Aut-Guard policy-id (PolicyIdRef),
   • OverrideProtocolRef (SpeechAct names, SoD),
   • pointer to where Green‑Gate applies in the Method steps,
   • where AutonomyLedgerEntry is recorded on U.Work.
2. Include one Tell‑Show‑Show vignette that demonstrates depletion and override handling.
3. Use LEX‑BUNDLE terms (Scope (G), Γ_time, Role, Method, and Work). Avoid “validity”, “process”, “actor”, “system”, “mechanism” unless mapped to kernel types.

#Archetypal Grounding (System / Episteme)

Note: Prefer examples that reuse FPF characteristics vocabulary (e.g., F (Formality) rather than “F‑score”) unless you explicitly mean an external metric and name it as such.

#Bias‑Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for the authoring conventions in this pattern. This guidance biases toward Did (readability, narrative flow) and Arch (template regularity) by design; the mitigation is content-bearing reduced sections and justification through the smallest grounding, misuse, boundary, or reduced-case statement, not omission placeholders.

#Conformance Checklist

CC style (canonical). Conformance Checklist items are authoring checks: they test whether the pattern guidance has been applied and written correctly in a pattern or companion text that claims conformance. They do not replace Solution, do not make the pattern a control form, and do not state deontic obligations about the modeled world. A CC clause of the form “X SHALL ...” is to be read as “In a conforming pattern or companion text, X SHALL ...”.

Preferred wording for new or edited CC items: start with an explicit conformance subject (e.g., “Authors ...”, “Reviewers ...”, “A conforming implementation ...”, “A validator ...”). If a CC item is enforcing an admissibility predicate, it SHOULD cite the predicate’s identifier (from a Definition: / Invariant: / Well-formedness constraint: block) rather than restating the predicate as “X MUST ...”. For boundary/interface/protocol/declaration patterns, prefer A.6.B-scoped claim IDs (L/A/D/E) or cite an existing Claim Register (A.6.B:7) instead of restating mixed prose.

#Common Anti-Patterns and How to Avoid Them

These failure modes recur in drafts and in downstream application. They are predictable ways the Forces in this pattern get violated.

#Consequences

#Rationale

Structure and style function as FPF’s grammar. By unifying what were once separate “template” and “style guide” patterns, authors face a single reference point that satisfies:

• P‑1 Cognitive Elegance – uniform, minimal surprises.
• P‑2 Didactic Primacy – narrative flow, dual archetype examples.
• Guard‑Rails 1 & 2 – no tool jargon, no notation lock‑in inside prose.

A unified template also improves retrieval: a chunk containing A.2:<n> - Bias‑Annotation remains self‑identifying even when parent headings are missing, and the recommended footer marker makes truncation detectable.

International and industry standards often speak in terms of conformance criteria. FPF uses the label Conformance Checklist to make adoption easier for engineers and managers.

#SoTA-Echoing (normative; lineage and deltas to contemporary State-of-the-Art)

Purpose. Make each pattern's relationship to contemporary best-known problem-solving practice explicit and comparable without importing tooling or data governance. This section is prose-first and notation-independent. It does not mint an independent second rule source, but it is an FPF-governed alignment section: the Solution, Conformance Checklist, Relations, worked cases, and other FPF-governed sections must reflect the stance stated here or explicitly justify divergence.

SoTA definition. In FPF, SoTA names the best-known currently defensible problem-solving practice for the named practice question in the relevant domain or practice tradition. It is not official status, a recent edition, broad popularity, citation volume, institutional adoption, reputation, or familiar terminology. A standard, book, paper, benchmark, or practice report carries SoTA only when it states or justifies the current best-known answer for the named practice question; otherwise it is lineage, current-standard reference, rationale-only material, or rejected-popular-practice material.

Two-part SoTA test. A row must pass both tests. First, the source family must be SoTA-bearing: it must represent the current best-known answer for the named practice question or a clearly named current branch of that answer. Second, the pattern must incorporate that answer by value: the adopted, adapted, or rejected stance must change Solution, boundary, anti-pattern, rationale, checklist, relation, worked case, evidence requirement, stop/reopen condition, or another FPF-governed pattern locus. A current best-known source that changes no FPF locus is uncaptured SoTA; a citation that changes wording without being current best-known practice is not SoTA.

Incorporation test. A SoTA row is accepted as pattern grounding only when it changes what the pattern lets a working user do, what the pattern forbids them to over-read, which neighbouring FPF pattern must apply, which evidence or validation requirement remains applicable, or how the Solution and neighbouring FPF-governed sections are written. A citation that only decorates the pattern or proves that the author has read a tradition does not carry E.8.

Minimum contents (authoring requirements).

1. Evidence binding (no duplicate SoTA). If a SoTA Synthesis Pack exists (G.2), this section SHALL cite its ClaimSheet IDs, CorpusLedger entries, and BridgeMatrix rows as the governing evidence source for claims and report adopt, adapt, or reject consistent with those IDs. Avoid forking an untracked SoTA narrative. 1a) Accepted decision and source material set, not DRR-only narrowing. When a pattern is drafted under an accepted DRR and other accepted decision or source materials also exist by value, the DRR remains the decision and placement record, but SoTA-Echoing, neighboring-pattern relations, and any minimal modeling or mathematical lens MAY and SHOULD inherit non-conflicting material from that accepted material set.
2. Sources (current problem-solving source refs, not prestige refs). For Architectural patterns, cite at least 3 primary SoTA source refs that carry current best-known answers for the named practice question, with at least two independent Traditions when more than one serious tradition currently answers that question. For Definitional patterns, cite at least 1 current source or practice ref for the reduced issue being governed: terminology work, ambiguity or sense recovery, separation between constraint and ontology, controlled-vocabulary caution, or a comparable definitional problem. If the best source is older but still current, mark why it still answers the named practice question rather than treating source age, standard status, or popularity as SoTA by itself.
3. Best-known, not merely popular. Authors SHALL distinguish best-known currently defensible practice from merely widespread or fashionable defaults. If the pattern adopts, adapts, or rejects a popular but less defensible practice, that divergence MUST be stated explicitly. 3a) Currentness and lineage status. Older standards, early papers, and historically important examples may be cited as lineage only when later practice has materially changed the answer. They may carry a SoTA row only when the pattern states why the source ref is still current for the named practice question or pairs it with a current source that supplies the current practice. 3b) Problem-domain and practice answerability. The selected SoTA source family MUST answer the governed working problem and the relevant domain or practice tradition. It MUST NOT be selected only because it makes package placement, naming neatness, or pattern clustering easier to justify.
4. Practice alignment. For each cited item, state what is adopted, adapted, or rejected and why in 2 to 4 sentences.
5. Scale admissibility. If numeric operations are implied, bind to ComparatorSet or CG-Spec and declare partial-order stance with no hidden scalarization.
6. Cross-Context reuse. Any reuse across U.BoundedContext must expose Bridge id plus CL and, if ReferencePlanes differ, Phi policy ids; penalties affect only R_eff.
7. Lexical hygiene. Avoid “mapping” unless you mean an explicit Bridge, translation relation, or other named relation with loss notes.

Writing guidance (readability). Write short paragraphs, not tag lists. For each Tradition, provide one sentence naming the practice, one sentence comparing it to the pattern's Solution, and one sentence giving adoption status with reason. Where helpful, add one System and one Episteme micro-example (Tell-Show-Show).

Format: human-first. A small table is allowed, but each row MUST be accompanied by 1 to 2 sentences as above. Vendor tokens, tool tokens, file formats, or data schemas are out of scope unless the named practice question under discussion makes them have FPF-governed use.

#SoTA alignment for this pattern (E.8 self-echo)

#Relations

• Coordinates with: E.9.DA when an authored pattern body is drafted from a concrete DRR and the blocker is whether the DRR selected, distributed, carried source use, carried accepted decisions, or supplied a first drafting move sufficiently for that authoring use. E.8 still governs the pattern body; E.9.DA is not a mandatory authoring section, review card, or substitute for writing the Solution.

• Builds on: E.6, E.7

• Constrained by: Guard‑Rails E.5.1–E.5.4 (lexical firewall, notation independence, etc.)

• Coordinates with: E.21 when one authored FPF pattern version is evaluated as a scoped pattern-quality claim. E.8 governs authoring shape, recognition text, action guidance, worked cases, SoTA grounding, and conformance material; E.21 governs the pattern-quality evaluation, required coordinate values, PatternQualityStatus, and stop condition. Do not import E.21 as a mandatory authoring section or full review card.

• Coordinates with: E.23 when an authored FPF pattern body is being improved through repeated passes. E.8 still governs the authored pattern body; E.23 governs the repeated quality-improvement method; the object-under-improvement evaluation such as E.21 or E.9.DA supplies value meanings and stop meanings.

• Coordinates with: E.13 when an authored pattern claims practical payoff or uses a visible quality value, metric, checklist result, review result, or release posture as if it were the intended value. E.8 keeps the payoff in user-facing prose; E.13 repairs proxy-to-value substitution.

• Constrains: All patterns; the DRR template references the same section order.

#E.8:End

#Evaluation CharacteristicSpace FPF Pattern Publication Form

Type: Authoring method pattern Status: Stable Normativity: Normative

#Problem frame

Use E.8.ECSPF when an evaluation CharacteristicSpace constructed or repaired under A.19.ECS must be published as an FPF pattern. The question is not "what values should this evaluated object be judged by?" but "how do we write the FPF pattern publication form so those values remain usable, reviewable, and bounded?"

A.19.ECS governs the evaluation characteristic-space specification: evaluated object kind, use scope, contrast cases, coordinate set, value meanings, evidence basis, result-row shape, calibration points, coordinate-specific payloads, missingness, protected trade-offs, status meanings, and stop or reopen conditions. E.8 governs ordinary FPF authoring form. E.8.ECSPF governs their intersection: an FPF pattern whose main payload is a reusable evaluation.

Not this pattern when. Use A.19.ECS when the characteristic-space specification itself is missing or inadequate. Use E.8 when the pattern is not an evaluation-characteristic-space pattern. Use E.21, E.9.DA, E.2.DA, F.18, C.25, or a project-local evaluation when one already supplies the value meanings for the evaluated object and use. Use E.22 to frame one quality evaluation and E.23 to run repeated improvement. Use a local rubric, table, or project rule instead of an FPF pattern when the evaluation is not intended for durable FPF reuse.

First useful move. Start from the accepted A.19.ECS specification. Name the evaluated object kind, declared use, and first action-guiding evaluation use in the pattern's recognition text before presenting coordinate tables or conformance rows.

FPF-publication boundary. If the evaluation is local, temporary, or project-specific, do not publish an FPF pattern. Keep the A.19.ECS specification in the local publication form and cite the FPF neighbouring patterns named by value it uses.

What goes wrong if missed. An evaluation-characteristic-space pattern becomes a score sheet, review form, checklist, or taxonomy. The coordinate table appears before the working situation. Readers can see values but cannot tell when to use them, what to do after an evaluation result, which objects are outside the declared evaluated-object kind, or which neighbouring pattern governs evidence, assurance, gate, work, decision, naming, measurement, or improvement-loop claims.

What this buys. E.8.ECSPF lets FPF publish evaluations as real patterns: practitioner-readable first, exact enough for review, and bounded enough that E.22 and E.23 can consume them without stealing their values.

Primary EntityOfConcern in plain terms. The primary EntityOfConcern is the authored FPF pattern publication form for one evaluation CharacteristicSpace.

Primary working reader. The first reader is an FPF author or reviewer turning an accepted evaluation characteristic-space specification into a reusable FPF pattern for later practitioners, managers, and stewards.

#Problem

A.19.ECS can produce a good evaluation characteristic-space specification without saying how to publish that specification as an FPF pattern. E.8 can produce a good generic FPF pattern without saying how a coordinate set, object-kind-fit rule, evidence basis, result-row shape, calibration points, status set, and stop condition should be placed when they are the pattern's main payload.

Recurring failures:

1. Publication-form/content collapse. The FPF pattern is treated as the evaluation itself, instead of a publication form for an evaluation characteristic-space specification.
2. Table-first pattern. Coordinate rows arrive before evaluated object kind, use, first move, FPF-publication boundary, and object-kind boundary.
3. Checklist substitution. Conformance rows replace the Solution instead of checking a readable evaluation method.
4. Underpublished values. Coordinate names are present, but value meanings, missingness, polarity, protected trade-offs, status meanings, or stop conditions are missing.
5. Wrong-kind examples. Worked cases show only passing examples, so the pattern cannot teach below-floor and outside-declared-object-kind boundary outcomes.
6. Neighbour theft. Evidence, assurance, gate, work, decision, naming, measurement, OEE/NQD, or mathematical-lens claims are carried as if the evaluation-characteristic-space pattern governed them.
7. Pattern-quality confusion. The author uses E.21 to judge whether the FPF pattern version is good, but forgets that the new pattern must still publish the evaluation for one evaluated object kind by value.
8. Quality-carrier leakage. E.21 values, corpus projection, README/ToC/E.11/I.2 alignment, retrieval, cold-reader evidence, monolith parity, landing evidence, or developer/reviewer/executor correspondence for the publication form is written into the evaluation pattern as if it were the evaluated object's method.

#Forces

#Solution

When an A.19.ECS specification is selected for durable FPF publication, author the evaluation as an E.8 pattern with these additional placement rules:

1. Keep the evaluation characteristic-space specification separate from the publication form. The pattern publishes an evaluation CharacteristicSpace; it is not itself the evaluated object, the evaluation result, the improvement loop, or the evidence record.
2. Put recognition before coordinates. The opening text names evaluated object kind, declared use, first evaluation use, FPF-publication boundary, what goes wrong, and what the pattern buys before any dense table.
3. Place the A.19.ECS specification by value. The Solution carries the record shape, local names, object-kind-fit rule, coordinate set, value meanings, evidence-basis rule, result-row shape, adjacent-value rationale rule, calibration points, coordinate-specific evidence payloads, missingness rule, protected trade-offs, status meanings, and stop or reopen condition.
4. Use worked slices as the discriminating-case test. Archetypal Grounding and worked cases include a passing evaluated object, a below-floor evaluated object, and an outside-declared-object-kind boundary case.
5. Keep checklist rows secondary. Conformance checks verify that the evaluation is recoverable and usable. They do not become the user's method.
6. Keep outside claims with governing patterns. Relations and compact non-use boundaries name the governing pattern for evidence, assurance, gate, work, decision, naming, measurement, OEE/NQD, mathematical lens, E.22 quality-evaluation, and improvement-loop claims. They do so declaratively and do not replace the evaluation publication form with reference boilerplate, phrase apparatus, or architecture-placement rationale. If phrase-level apparatus appears, apply F.19; if remaining words still hide precision, apply E.10, E.10.ARCH, F.18, or the governing pattern. If a wording repair changes an FPF-governed phrase in the evaluation specification or publication form, the pre-repair and post-repair evaluated object kind, relation or claim kind, slot or use-position when live, admissible use, and scope must remain recoverable; lexical substitution without that check and governing-pattern reference when another pattern governs the kind under repair, relation, claim, or position is not a repair.
7. Evaluate the publication form with E.21. When the FPF pattern publication form is under quality improvement, E.21 evaluates the FPF pattern version's quality. The evaluation coordinates inside the pattern continue to judge the evaluated object declared by that evaluation. The E.21 result, corpus-projection evidence, README/ToC/E.11/I.2 alignment, retrieval or cold-reader evidence, monolith parity, landing evidence, and developer/reviewer/executor correspondence stay in the quality, review, projection, or release carriers unless the publication form's own EntityOfConcern and user move are that evaluation/projection work.

The authoring flow and the quality-improvement flow are different flows. This pattern publishes an evaluation for its declared evaluated object kind. A later E.21 evaluation of this pattern is evidence about the publication form as an FPF pattern, not part of the evaluation that the pattern publishes. That evidence may cause edits to recognition text, coordinates, cases, or boundaries, but it remains outside the pattern unless rewritten as user-facing evaluation guidance.

#Canonical placement table

#Local names and kind settlement

#Archetypal Grounding

Tell. An evaluation CharacteristicSpace becomes reusable in FPF only when a practitioner can recognize the evaluated object and use before reading the coordinate table. The publication form must teach the evaluation use, not merely list the values.

Show, pattern-quality evaluation. E.21 is an evaluation for one FPF pattern version. Its publication form must still open with the working question "is this pattern good enough for the declared use?" before showing coordinates such as first-move recoverability, boundary fit, and SoTA binding.

Show, local rubric that should not become an FPF pattern. A project team defines a temporary rubric for choosing a meeting room. The A.19.ECS specification may be adequate locally, but no durable FPF pattern is needed because the evaluated object kind and use do not recur across FPF practice.

Show, object-kind boundary. A nuclear-plant evaluation can judge nuclear plants and declared comparable power-generation alternatives. A chair or FPF pattern is outside that evaluated-object kind: before the evaluation is opened, select a suitable evaluation; after a forced invocation, record an object-kind-fit defect/value rather than treating it as a weak nuclear plant or skipping declared coordinates. The pattern publication form must show that boundary before readers try to use the coordinate table.

#Bias-Annotation

Evaluation-characteristic-space patterns are vulnerable to domain-example bias: the first examples can silently choose the evaluated object kind, use, and value family for later readers. A conforming publication form names known skew in examples, sources, reader family, domain tradition, measurement preference, benchmark preference, or FPF-internal reuse. When the evaluation claims broad use, the case bank must include heterogeneous evaluated object situations or explicitly narrow the claim.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

A conforming E.8.ECSPF publication form makes an evaluation findable, teachable, and reusable inside FPF. It lets E.22 frame quality evaluations and E.23 run improvement loops without re-inventing values. It also makes the cost visible: a reusable evaluation-characteristic-space pattern must publish more than a local rubric, because it must prevent wrong-kind use, hidden value drift, neighbour theft, and proxy-for-value substitution.

The pattern publication form does not certify the evaluated object, approve a release, prove evidence, or finish improvement. It only publishes a bounded evaluation.

#Rationale

The split between A.19.ECS and E.8.ECSPF preserves the FPF distinction between an evaluation characteristic-space specification and its publication form. A.19.ECS says what must exist for an evaluation to be adequate. E.8.ECSPF says how that adequate evaluation is authored as an FPF pattern when FPF publication is selected. This prevents two symmetric mistakes: stuffing FPF pattern-format requirements into a general characteristic-space construction method, and publishing an evaluation-characteristic-space pattern whose coordinate set is not recoverable by value.

#SoTA-Echoing

Source-use convention. This section uses source rows only where they change the publication form: evaluated object and use before checklist, coordinate meanings and missingness, worked cases, non-scalar comparison, protected trade-offs, or action-guiding recognition text. Reporting frameworks and standards are reference-only use unless they solve the publication-form problem named by value.

#Relations

#E.8.ECSPF:End

#Design‑Rationale Record (DRR) Method

Type: Governance and authoring pattern Status: Stable Normativity: Normative

#Use this when

• one proposed normative change needs an explicit by-value account of what FPF should say, why this decision is preferred, and which neighboring patterns or selected non-pattern FPF kind-reference pairs it affects
• several patterns or selected non-pattern FPF kind-reference pairs must move together and one external decision record is needed to keep one bounded coordinated change set (one mutually dependent change set) semantically complete while enduring Core text is redistributed
• one bounded content decision question would otherwise force authors to decide the same load-bearing answer separately across several patterns or selected non-pattern FPF kind-reference pairs
• one deprecation, narrowing, or cross-pattern amendment must stay reviewable without reconstructing intent from patch history, chat memory, or scattered notes

Not this pattern when. Do not use E.9 as the permanent location of normative Core law, as a campaign or process brief, or as the main vehicle for purely editorial Delta-0 or Delta-1 cleanup that fits the lightweight variant in CC-DRR.5. Use E.9.DA when one concrete DRR already exists and the question is whether its selected answer, selected-locus obligations, source use, lexical closure, and drafting actionability are adequate for a declared downstream authoring use.

#What goes wrong if missed

• Core text changes without one explicit rationale account, so later readers cannot recover which alternatives were rejected or which exclusions were intentional
• coordinated multi-pattern amendments drift apart because the temporary selected-answer account survives only in patches, handoffs, or reviewer memory
• future repairs overfit to local wording and silently lose Pillar, taxonomy-lens, impact-graph, practical-use, or pattern-placement discipline

#What this buys

• one external decision record that states the bounded FPF change by value before Core text is rewritten
• one minimum kernel that keeps Problem frame, Decision, Rationale, and Consequences recoverable for later review and replay
• one temporary convergence record for coordinated changes, while keeping enduring Core text in the selected patterns and selected non-pattern FPF kind-reference pairs rather than in the DRR
• one temporary convergence record that fixes the selected answer (the chosen content answer for the bounded content decision question) before later drafting fans out across several selected patterns or selected non-pattern FPF kind-reference pairs

First useful move. State the bounded FPF content decision question, the selected answer, the rationale for that answer, and the selected distribution across patterns or selected non-pattern FPF kind-reference pairs before drafting or landing the Core text.

Cheap stop. If the change is ordinary local wording repair, application of an already accepted pattern, or editorial cleanup that does not change FPF semantics, obligations, boundaries, names, admissible uses, or normative force, do not open a full DRR. Use the lighter governing pattern for the local repair: E.17.AUD.LHR for one overloaded local lexical head inside one publication unit, C.2.P for one episteme, publication, or source-use phrase requiring local epistemic precision restoration, E.10 for general lexical repair, F.18 only when a durable reusable name is being minted, and E.8 for authoring-form correction. Leave E.9 for bounded content decisions that need rationale by value.

Kind-or-boilerplate diagnostic. When a DRR proposes wording for selected patterns, apply F.19 to separate boilerplate apparatus from remaining content before any wording is treated as pasteable pattern prose. If the remaining content still hides wording-use, naming, relation, claim, admissible-use, selected-locus, user-move, or flow-role precision, the DRR names the applied E.10, E.10.ARCH, F.18, or governing pattern. Process, architecture, review, or reference apparatus belongs in its own carrier, not in pasteable pattern prose.

A DRR-proposed wording repair is not pasteable pattern prose until it carries a kind-restoration check. The DRR must show the pre-repair and post-repair object kind, relation or claim kind, slot or use-position, admissible use, and scope, or explicitly decide that the change is a semantic change rather than an editorial repair. A nicer head word, shorter phrase, or removed trigger word is not decision evidence when it narrows a graph into a sequence, turns a method into work, widens an evidence record into assurance, treats a use-position as a new kind, or otherwise changes the kind or use-position without an accepted decision. When the decision depends on slot, lens, role, method, work, evidence, assurance, gate, or decision ontology, the DRR cites the governing pattern rather than redefining that ontology locally.

Primary EntityOfConcern in plain terms. The primary EntityOfConcern here is one external decision-rationale record for one bounded FPF content decision or one bounded coordinated change set. The minimal lens is simple: the record must keep the problem frame, decision, rationale, consequences, and impact and boundary account recoverable enough that accepted content can be distributed into the selected Core patterns and selected non-pattern FPF kind-reference pairs without semantic invention.

Primary working reader. The first working reader is an FPF author, reviewer, or steward who must evaluate, challenge, or land one bounded content decision. Downstream pattern readers benefit from the landed Core text; they are not the primary reader of the DRR itself.

#Problem frame

FPF is engineered for Pillar P‑10 Open‑Ended Evolution: its normative rules must adapt as new calculi and insights arrive. But change without a record of why leads to conceptual erosion and undermines auditability. Hence FPF requires an explicit Design‑Rationale Record (DRR)—a durable conceptual record that precedes every normative change.

#Problem

Direct edits to the Core, absent a structured rationale, trigger three systemic hazards:

1. Lost provenance – future authors cannot infer the reasoning behind a rule; intent decays.
2. Implicit assumptions – discarded alternatives vanish from memory, so debates resurface and churn repeats.
3. Conceptual drift – incremental tweaks slip past the Eleven Pillars and Principle Taxonomy lenses, blurring the framework’s foundations.

#Forces

#Solution — the DRR as a structured argument and temporary convergence record

Any proposal to add, modify or deprecate a NORM, A, D, or GOV rule MUST be accompanied by a Design‑Rationale Record. By default, a conforming DRR contains at least four conceptual components (below); these form the minimum decision kernel recoverable by any conforming DRR. A lightweight editorial variant is permitted by CC‑DRR.5.

In this pattern, a bounded coordinated change set means one bounded group of mutually dependent content decisions whose enduring FPF expression will be distributed across several patterns or selected non-pattern FPF kind-reference pairs. In this pattern, the selected answer means the current set of chosen content decisions for that bounded content decision question: what FPF should say, which selected patterns or selected non-pattern FPF kind-reference pairs carry it, what stays outside, and which source-use row, evidence path, validation evidence obligation, or loss/recoverability regime applies. In this pattern, selected non-pattern FPF kind-reference pair is a tuple-like instruction, not one new kind: when a DRR selects a non-pattern publication, view, record, or relation to carry durable content, it must name the FPF kind named by value and reference by value, for example pattern profile, U.View, source map, source-use note, authoritySourceRef target, evidence-path record, review-finding record, or architecture-decision record. In this pattern, a temporary convergence record means one external decision record that temporarily holds the selected answer while the selected Core patterns and selected non-pattern FPF kind-reference pairs are still being updated.

A nontrivial DRR may therefore govern one bounded coordinated change set. In that case the DRR is the temporary convergence record for the selected answer until selected Core patterns and selected non-pattern FPF kind-reference pairs are updated; it is not a second permanent Core-law section.

#Minimum decision-inspection content blocks

A conforming DRR must also make the following decision-inspection content blocks recoverable. They may appear inside the four kernel components or inside one dedicated Decision grounds used or decision-inspection block, but they are part of substantive DRR adequacy rather than later review-only hardening.

These decision-inspection content blocks are not separate process paperwork. A DRR that keeps only the four labels while leaving decision grounds, first-minute use question, naming, selected content distribution, pattern or selected non-pattern FPF kind-reference pair sufficiency or necessity, overlap handling, impact, or unresolved uncertainty implicit is structurally labeled but still substantively immature.

Together these decision-inspection content blocks let the DRR act as one decision record for one bounded coordinated change set: enough semantic closure that later drafting distributes the selected answer into selected patterns and selected non-pattern FPF kind-reference pairs rather than inventing it for the first time pattern by pattern.

When one bounded decision coordinates several patterns or selected non-pattern FPF kind-reference pairs, or one cluster of mutually dependent pattern edits and selected non-pattern FPF kind-reference pair edits, the DRR MAY carry additional substantive sections beyond that minimum kernel. Typical substantive additions include obligations on selected patterns and selected non-pattern FPF kind-reference pairs, one explicit new-pattern vs existing-pattern decision, one impact or non-goal map across selected patterns and selected non-pattern FPF kind-reference pairs, coverage or agreement maps across selected patterns and selected non-pattern FPF kind-reference pairs, convergence classification, and one provisional decision-law account by value that keeps the bounded change account semantically complete until enduring Core text is distributed.

Such additions do not change the DRR’s kind. A DRR carrying them remains conforming only when it stays about the FPF content decision: what FPF should say, why, what is excluded, how selected patterns and selected non-pattern FPF kind-reference pairs are affected, and what practical use or authoring action improves. A DRR carrying richer convergence content MUST NOT become a campaign plan, process script, baton carrier, packet checklist, staging log, or other development-process brief.

When one selected answer could plausibly fit one already-existing pattern or selected non-pattern FPF kind-reference pair or require one newly proposed pattern or selected non-pattern FPF kind-reference pair, the DRR must decide that sufficiency/necessity question by value. It is not enough to list a tentative carrier list or leave downstream drafting to discover the selected pattern or selected non-pattern FPF kind-reference pair later.

When the accepted decision grounds or the DRR itself already names one pattern or selected non-pattern FPF kind-reference pair as part of the distribution question, that pattern or selected non-pattern FPF kind-reference pair is not a neutral future watch item. The DRR must classify it now either as one selected pattern or selected non-pattern FPF kind-reference pair with explicit obligation, one explicit boundary neighbor kept unchanged, one inherited-unchanged neighbor, or one outside-current-decision item with named pattern, selected non-pattern FPF kind-reference pair, or decision record. Conditional or time-relative pattern prose or prose for one selected non-pattern FPF kind-reference pair such as most likely, may need local hardening, if later touched, watch later, or one equivalent placeholder is non-conforming there because it marks one unmade current decision rather than one explicit current disposition.

When accepted decision grounds expose one potentially reusable selected non-pattern FPF kind-reference pair or neighboring source-use, evidence, assurance, validation, or architecture-decision mechanism, the DRR must not merely note that such content already exists. It must decide whether that content is generalized now, kept local with a substantive reason, rejected, or marked outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record.

When one selected answer involves source-loss mode, simplification, redaction, summarization, or other declared loss, the DRR must make the admissible-use template explicit by value. Explanation alone is not enough; the decision must say what remains preserved, what is dropped, which branch reading is admissible and which selected non-pattern FPF kind-reference pair carries it, which uses lack an admissible carrier or evidence path, what recoverability class applies, and what reopen or stop rule governs cases that exceed the declared source-loss or scope-narrowing state.

A nontrivial DRR is mature enough for downstream authoring only when material selected-answer branch choices about the EntityOfConcern, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-content disposition, and loss/recoverability regime have already been selected, rejected, inherited unchanged, or placed outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record. If those choices are still missing, the DRR is still decision-grounding work rather than one accepted design-rationale record.

The DRR lives outside the normative Core. An accepted DRR SHALL be landed by applying its Decision account and any stabilized enduring content to the relevant pattern or selected non-pattern Core kind-reference pair as explicit normative or informative text (the change is "in the Core"; the DRR is not). A richer DRR MAY remain the temporary convergence record while redistribution into selected Core patterns and selected non-pattern FPF kind-reference pairs is still incomplete, but it SHALL NOT remain the permanent sole semantic carrier once landed Core text exists.

Authors drafting from an accepted DRR MAY elaborate examples, SoTA‑Echoing, recognition sections, local wording inside the selected patterns and selected non-pattern FPF kind-reference pairs, and neighboring fit. They SHALL NOT silently revise the selected answer, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-content disposition, or declared loss/recoverability regime. Any such revision SHALL be handled through one successor DRR or other named successor decision record.

A DRR may itself be improved through E.23, but the DRR remains the selected decision record, not a full pattern draft. When SoTA is load-bearing in that improvement, it must mutate the selected answer, selected-locus obligation, boundary, example, validation obligation, or reopen condition; otherwise it is rationale-only or lineage-only for the DRR.

To preserve P‑2 Didactic Primacy without duplicating meta‑text, authors landing an accepted DRR SHOULD distill stable and reusable parts of its Rationale, Consequences, and other valid convergence sections into the appropriate informative sections of the affected pattern(s) (Rationale, Consequences, SoTA‑Echoing, Archetypal Grounding; per the Pattern Template, E.8). The full DRR remains external as provenance.

A substantive DRR is one current content decision object. It may carry selected content obligations only when they are part of the Decision or Consequences. It MUST NOT carry next-gate state, handoff/packet state, process-order state, monolith status, future campaign planning, or one hidden promise that the same current content decision question will be decided later inside the same decision object. Any undecided remainder must be marked outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record.

#Process-source method admission into FPF

When a DRR imports stable method from process-source document-carried method description into FPF, it must decide the admission by value rather than treating process prose as a second canon.

The DRR names:

• the process-source passage or accepted source named by value process-source decision-ground item being considered;
• the reusable FPF method recovered from that passage;
• the current FPF pattern, section, or accepted DRR that already carries the method, if any;
• the remaining delta that current FPF does not yet carry;
• the selected FPF pattern chosen to carry that delta;
• process-control material excluded from FPF pattern prose, such as role dispatch, seam state, helper behavior, Git recovery, packet transport, review transport, chat cadence, and mutable release state;
• the source-use result for that passage or decision-ground item: quote named by value, narrowed scope, instantiated case, decision-bearing use, draft-guidance source, example-only use, or retired source use;
• any meaning loss or addition created by that source-use result: changed scope, relation, evidence path, admissible use, non-admissible use, reader move, or recoverability condition;
• the first improved FPF use that the admitted method gives to an author, reviewer, or downstream FPF user;
• the current disposition: selected now, inherited sufficient, rejected now, or outside the current decision with the named evaluation pattern, accepted DRR, or accepted decision-ground item named by value.

Reusable process-source method is not limited to semio wording or pattern-authoring language. It may enter FPF only when it is separable from local process mechanics, improves FPF use, and has one exact evaluation pattern. After the method lands in FPF, process documents should cite the selected FPF pattern instead of keeping a parallel long-form rule.

#Archetypal Grounding (System / Episteme)

#Bias-Annotation

Scope: this bias annotation is universal for FPF semantic changes governed by E.9. It does not turn project-management state, helper state, or review logistics into DRR content.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

FPF evolves by explicit, reviewable deltas rather than silent edits. The DRR is the minimum structured argument—and, when several patterns or selected non-pattern FPF kind-reference pairs must move together, an allowed temporary convergence record that keeps P‑10 Open‑Ended Evolution compatible with P‑1 Cognitive Elegance and P‑2 Didactic Primacy.

E.9 sets a floor, not a ceiling: every conforming DRR must make Problem‑frame / Decision / Rationale / Consequences recoverable, but it may carry richer substantive coordination content when that prevents shadow documents or semantic invention during distribution into Core patterns and selected non-pattern FPF kind-reference pairs. The same floor also requires the decision-inspection content that later authoring and review otherwise reconstruct manually: exact decision grounds, use-value, first-minute working situation, scenario grounding, alternatives, current disposition map, naming/ontology obligation, selected content distribution, existing-pattern sufficiency/new-pattern necessity, overlap classification, selected-answer stability, impact/boundary graph, practical payoff, and any remaining uncertainty that materially shapes the decision.

Pointer-based DRRs (CC‑DRR.1a) prevent duplicated prose, and distribution into Core patterns and selected non-pattern FPF kind-reference pairs (CC‑DRR.4) keeps the specification itself learnable without turning the DRR into a permanent shadow canon. Process-law ordering, gate, and handoff records stay outside because they are not part of the content answer that FPF is selecting.

#SoTA-Echoing

E.9 aligns with contemporary architecture-decision and rationale-capture practice, but its contribution is not the existence of a decision record. ADR practice already carries compact context, decision, and consequence records. FPF uses the DRR as a decision-rationale record for one bounded FPF content decision, with enough by-value rationale to distribute durable content into selected patterns and selected non-pattern FPF kind-reference pairs.

The practical gain is content-selection quality under semantic load: the DRR decides the selected answer, alternatives, losses, boundary, and selected loci before pattern drafting begins. Any durable rule, example, or content obligation that remains useful after acceptance belongs in the selected FPF pattern or selected non-pattern FPF kind-reference pair, not in the DRR as a permanent shadow canon.

When a DRR relies on a source document, workstream plan, campaign queue, external review packet, standard, article, ADR-like note, or prior accepted decision, it states how the source is used and the source adoption/adaptation/rejection decision, then carries the selected payload by value: adopt, adapt, reject, lineage-only, rationale-only, selected payload, rejected or non-carried payload, source loss, selected locus, non-use boundary, and reopen condition. A cited source is not FPF doctrine, child DRR, review result, gate, evidence sufficiency, or monolith landing source by citation alone.

#Relations

• Instantiates: P‑10 Open‑Ended Evolution, P‑2 Didactic Primacy

• Template governed by: pat:authoring/pattern‑template (E.8)

• Interacts with: pat:guard/bias‑audit (E.5.4) via lens check

• Complemented by: E.9.DA when one concrete DRR follows E.9 form but its adequacy for downstream drafting, host amendment, accepted-decision carry-through, source-use carry-through, or selected-locus distribution is disputed or materially relevant. E.9.DA reads the DRR decision-adequacy claim; it is not a second DRR form, review gate, or mandatory ordinary editorial step. Also complemented by pat:authoring/code-of-conduct (E.12) for etiquette in DRR debate.

• Coordinates with: E.23 when one DRR is being improved through repeated quality-improvement passes. E.9 keeps the DRR kind and decision-record form; E.9.DA supplies the decision-adequacy object-under-improvement evaluation when adequacy is being improved; E.23 governs the repeated method rather than turning the DRR into final pattern prose.

#E.9:End

#DRR Decision-Adequacy Evaluation CharacteristicSpace

Status: Core.

#Problem frame

Use E.9.DA when one DRR must be reliable enough for a declared FPF authoring use: pattern drafting, host amendment, selected-locus distribution, accepted-decision carry-through, source-use carry-through, scope-boundary decision, split decision, or architecture-hold decision.

Not this pattern when the evaluated object is one authored pattern version, one admission or refresh review, one local wording repair, or a measurement-law problem. Use E.21, E.19, E.10 and its precision-restoration neighbours, or C.16, A.17, A.18, and A.19 for those objects.

First useful move: name DRRVersionRef by value, declared authoring use, selected-locus disposition map, and qualification window; then evaluate every decision-adequacy coordinate in this pattern. Missing decisions lower coordinates and produce repair, split, or hold status inside the same evaluation.

What goes wrong if missed: a formally valid DRR may still be too weak for drafting. It may summarize sources instead of deciding, mention neighbours without obligations, hide rejected alternatives, leave trigger words unresolved, or omit the first drafting action.

Primary EntityOfConcern in plain terms: the decision-adequacy claim of one DRR version for a declared FPF authoring use.

#Problem

E.9 defines the DRR kind and minimum decision-rationale form. It does not by itself say whether one concrete DRR is decision-bearing enough for downstream FPF authoring. Without E.9.DA, reviewers tend to approve headings, source volume, or clean prose while the pattern author still has to invent missing decisions.

Recurring failures:

1. The decision question is broad or implicit.
2. The selected answer is a summary rather than a decision.
3. Alternatives, rejected options, and outside-decision items are not closed.
4. Receiving loci are named but not assigned content obligations or non-obligations.
5. The selected FPF content architecture is explicit but wrong.
6. Source use is copied without saying what changed in the accepted decision.
7. Architecture descriptions, views, graphs, packets, or notes are treated as the FPF decision.
8. Administrative state becomes adequacy evidence.
9. Ordinal adequacy values become repair targets, so the DRR gains source rows, locus tables, boundary catalogues, or review proof while the selected answer and first drafting move do not become more decisive.

#Forces

#Solution

E.9.DA is the DRR decision-adequacy specialization of A.19.ECS. It evaluates whether one DRR version carries enough decision content for the declared authoring use.

There is no partial E.9.DA result. Once invoked, the evaluator assigns a value, short rationale, and evidence locus to every coordinate in E.9.DA:4.4, and states the evidence basis used for the result. If the DRR lacks a field, source row, selected-locus map, architecture decision, comparator, or currentness basis needed by a coordinate, the relevant coordinate receives a low value and the status states the repair, split, or hold.

#Local names and kind settlement

These names are local evaluation fields. They are not release state, review status, project evidence, gate result, assurance, or pattern-quality values.

#Evaluation record

DRRDecisionAdequacyEvaluation:
  DRRVersionRef: <DRR version named by value>

  DRRDeclaredAuthoringUse: <drafting | amendment | distribution | source-use carry-through | accepted-decision carry-through | split or hold decision>
  DRRSelectedLocusDispositionMap: <locus -> selected responsibility, explicit non-responsibility, sibling decision, or outside-decision disposition>
  DRRDecisionAdequacyQualificationWindow: <source, edition, neighbour, currentness window>
  DRRDecisionAdequacyEvidenceBasis: <checked DRR, source, accepted-decision, selected-locus, architecture, currentness, and neighbour loci; missing or unchecked loci named when they affect values>
  DRRDecisionAdequacyCoordinateTable: <all coordinates, values, short rationales, evidence loci>
  DRRPrecisionRestorationProfile: <word-use precision, phrase apparatus, repetition-and-distribution, ontic-slot clarity, description-publication-source boundary, and pattern-application profile; overall effect, affected coordinates, selected governing pattern, and no-repair or repair disposition with loci>
  DRRKindRestorationCheck: <required for each wording, naming, or precision-restoration repair proposal; pre kind, relation, claim, slot or use-position, admissible use, and scope -> post kind, relation, claim, slot or use-position, admissible use, and scope; not triggered | ordinary prose | already satisfied | preserved | split | intentionally changed | blocker, with loci>
  DRROnticCandidateDisposition: <if ontic or pattern-set architecture is at issue: selected, rejected, split, or declined candidate, sufficiency rationale, rejected alternatives, candidate-universe sanity sweep if broad, slot-relation boundary, description-publication boundary, and selected pattern placement>
  DRRDecisionAdequacyStatus: <status>
  StopOrRepairCondition: <local stop, first repair, split, or architecture hold>

[E.22](/generated/patterns/E.22) may frame whether the evaluation is floor-only, exceptional-improvement, trade-off, open-question, absorption, or proposal-producing. [E.23](/generated/patterns/E.23) governs repeated improvement of the DRR after evaluation findings exist.

#Ordinal coordinate scale

The value is a content evaluation of the DRR text and accepted source-use payload, not a reward for review, landing, popularity, citation volume, or absence of visible defects.

#Required decision-adequacy coordinates

Coordinate separation is by repair question. One DRR section may support several coordinates, but the rationale must state the distinct property supported for each. When two heads always fail and repair together, the DRR or the evaluation pattern needs characteristic-space repair through A.19.ECS.

#Result-row discipline and calibration

An E.9.DA result uses this table shape:

A prose summary, heading checklist, two-column coordinate-and-value table, or table without an EvidenceLocus named by value is not an E.9.DA result. It is draft evaluation material. Missing or unchecked evidence lowers the coordinate that needs it; it does not make the coordinate inactive.

Common calibration points:

#Status and stop condition

admissibleForDeclaredAuthoringUse states the first drafting move and the most expansive non-admissible overread. newFrameRequired is not a pass for the current declared use. Non-ready statuses state the first repair, split boundary, or architecture question.

#Compact result form

E.9.DA result:
  DRR version: <DRRVersionRef>
  Declared authoring use: <DRRDeclaredAuthoringUse>
  Qualification window: <window>
  Evidence basis checked: <DRRDecisionAdequacyEvidenceBasis>
  Precision-restoration profile: <DRRPrecisionRestorationProfile>
  Status: <DRRDecisionAdequacyStatus>
  Coordinate table: <Coordinate | Value | ShortRationale | EvidenceLocus for every required coordinate>
  First drafting move or first repair: <...>
  Most expansive non-admissible overread: <...>
  Reopen if: <smallest changed locus or condition>

The coordinate table may be short. It is still complete. Status is not assigned from a prose summary, two-column table, applied-finding count, review acceptance, or result missing evidence loci needed by its values.

#Finding row

E.9.DA finding:
  DRR version: <DRRVersionRef>
  Declared authoring use: <DRRDeclaredAuthoringUse>
  Coordinate or status affected: <coordinate | status | stop condition>
  DRR locus: <section, row, alternative, source-use row, accepted-decision row>
  Value or status effect: <value, status, floor, or stop impact>
  Correction direction: <selected answer | selected locus | source-use payload | architecture choice | example | boundary | stop or reopen>
  Closure test: <what changed DRR text would show>

Vague labels such as weak DRR, needs more evidence, or architecture unclear are not findings until rewritten into this row.

When [E.22](/generated/patterns/E.22), [E.23](/generated/patterns/E.23), absorption, or exceptional-improvement framing asks for improvement, below-floor coordinates return findings or repair. Above-floor coordinates receive proposal rows only for substantive non-dominated decision-content opportunities inside the declared authoring use: a more decisive selected answer, source payload mutation, selected-locus obligation, architecture split or merge decision, rejected-alternative closure, first drafting move, regression case, or deletion or relocation of apparatus that would otherwise become pattern prose. Do not treat every value below 5 as a defect. A 4 may be the correct stop value only with loci showing why further decision-content movement is dominated, unavailable, or outside scope.

#Worked slices

Weak precision-restoration DRR. A DRR says E.10, A.6.P, and C.2.P are relevant, but does not decide whether a new branch exists, what name it has, which repeated prose moves, or which regression cases test the split. SelectedAnswerDecisiveness, SelectedLocusObligationClosure, FPFContentArchitectureSelectionAdequacy, and DraftingActionability fall.

Adequate multi-locus DRR. The DRR selects a new precision-restoration pattern, assigns selected content responsibilities to selected loci, states rejected alternatives, gives first drafting moves, and carries source-use payload into examples and conformance. It can be admissible for host drafting without containing final pattern prose.

Architecture-impact DRR. A DRR uses diagrams, graphs, dashboards, or architecture notes. The evaluation asks whether the DRR decided the architecture or structure claim, structural view relation, preserved and lost structure, source-return condition, selected loci, and publication boundary. The description locates material; it is not the FPF decision.

#Bias annotation

This pattern biases FPF toward decisions before drafting. The bias is useful because missing decisions become expensive once they fan out into pattern hosts.

The bias is bounded. Small editorial decisions can use E.9 directly. Pattern quality remains under E.21; repeated improvement remains under E.23; wording repair remains under E.10 and precision-restoration neighboring patterns named by value.

#Conformance checklist

#Common anti-patterns and repairs

#Consequences

#Rationale

The cheapest place to repair missing FPF decisions is the DRR, before pattern prose spreads uncertainty across several hosts. A compact complete evaluation is better than a heavy preliminary audit: it gives every coordinate a value, identifies the first repair, and stops.

#SoTA-Echoing

#Relations

| E.19 | May return findings that expose upstream DRR defects. | | E.10, A.6.P, C.2.P, C.16.Q, F.18 | Govern wording, relation, episteme, quality-term, and naming repair. | | C.16, A.17, A.18, A.19, C.25 | Govern characteristic, scale, measurement, characteristic-space, and quality-bundle claims. | | Architecture-facing FPF patterns | Receive architecture, structure, view, graph, publication, and source-use distinctions when the DRR decision uses them. |

#E.9.DA:End

#Unified Lexical Rules for FPF

Status: Stable Definitional pattern; normative for all FPF pattern text and for any Context that claims FPF conformance.

Status and placement. Part E.10 (“Lexical Discipline and Stratification”); complements E.10.D1 (D.CTX), E.10.D2 (EntityOfConcern and Description-episteme boundary and specification-use gates), the DesignRunTag and CtxState boundary discipline (A.15; E.18), E.10.ARCH wording-use restoration architecture, A.6.P relation precision restoration, C.2.P epistemic precision restoration, A.19.SPR state-family precision restoration, and F.18 local-first naming. E.10:0.2 is the shared lexical trigger scan. The detailed LEX sections below supply register, naming, morphology, and local rewrite checks only for the selected wording problem; they are not a second wording-recognition table and do not replace E.10.ARCH, the selected precision-restoration realization patterns, governing patterns, or F.18.

Builds on: A.7 Strict Distinction (Clarity Lattice); E.5 Guard‑Rails (DevOps Lexical Firewall; Notational Independence; Unidirectional Dependency); F.5 Naming Discipline for U.Types and Roles. Coordinates with. A.2 and A.15 (Role–Method–Work alignment), A.10 (Evidence Graph Referring), B.1 and B.3 (Γ‑algebras and assurance), F‑cluster (context of meaning; Bridges).

#Use this when

What goes wrong if missed. Precision repair turns into taste or synonym replacement. A broad head such as support, surface, route, mapping, kind, basis, force, load, bearing, object, or record is replaced by another broad head, while the relation, source-use relation, admissible use, or neighbouring FPF pattern application remains unrecovered.

What this buys. E.10 gives one cheap trigger scan before heavier repair: ordinary wording stays ordinary, local lexical mistakes are repaired locally, relation-like wording applies A.6.P; episteme, publication, or source-use wording applies C.2.P; declarative-representation wording overread as imperative action, method, work, permission, release, evidence, or pattern dispatch applies C.2.P.DR; method, algorithm, program, proof, solver, workflow, process, procedure, access-path, query-plan, and control-strategy wording recovers the current ontic slot, relation position, use relation, or claim kind before any replacement; architecture or structure wording applies C.30.P; stratification or source-label wording such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate applies C.30.STRAT; characteristic or scale wording applies C.16.P; quality or evaluative wording applies C.16.Q; state-family wording applies A.19.SPR; and already recoverable cases apply the governing pattern directly. The result is precise enough to compose with FPF without making every phrase into a new pattern or review artifact.

Use E.10 when a word, head, or local phrase in conformant FPF text is starting to hide what kind it names, which register it belongs to, which context of meaning governs it, or which relation or action claim it carries.

First useful move. Restore the head kind and register of the local wording. If no FPF-governed use remains, make the small local rewrite under E.10 and stop. If an E.10:0.2 row selects a precision-restoration realization pattern or a governing pattern, apply that pattern instead of inventing a synonym. If the repaired wording becomes a durable reusable head, apply F.18 after the selected precision-restoration branch has recovered the kind and use. Governing FPF patterns are named only after that repair has made the EntityOfConcern, relation, claim, admissible use, project-side reference, or non-use disposition recoverable by value.

Cheap stop. If one local lexical repair restores kind, relation, and admissible use without changing the normative meaning of FPF, stop with the repaired wording; do not create or use a Name Card, DRR, review profile, or larger epistemic precision restoration note by habit. Ordinary application starts at E.10:0.2, applies only the row selected by the sentence under repair, and then stops at local repair, the selected restoration pattern or governing pattern, controlled precision reduction, or F.18 when a durable reusable head is actually being minted. Later LEX sections are detailed checks for the selected case, not a universal interpretation sequence.

Not this pattern when. Do not use E.10 as the ontology that governs the recovered claim. If the use under repair is evidence, assurance, work, gate, decision, causal use, publication, relation precision, or epistemic precision, the accepted text must make the governing FPF pattern application explicit; E.10 contributes only the wording-problem classification. For non-FPF source prose, use C.2.P source-expression unpacking mode and borrow E.10 only as a repair test, not as a conformance verdict.

#One-screen ordinary use

Ordinary E.10 use is one bounded FPF-governed wording repair, not a full lexical audit. The bounded complete accepted result is:

1. BoundedTextSpan: the exact sentence, row, section, pattern version, DRR slice, or project text deliberately using FPF-governed terms, pattern references, relation names, or conformance claims under repair.
2. TriggerSpan: the word or phrase that carries possible FPF-governed use.
3. SelectedInterpretation: ordinary no FPF-governed use, local head repair, register repair, morphology repair, relation-like precision restoration, episteme precision restoration, publication precision restoration, source-use restoration, durable naming, or not-triggered false positive.
4. FinalWordingOrBlocker: the accepted local wording, the governing-pattern result, or the blocker that remains.
5. StopBackToSubstance: after final wording or blocker is present, stop lexical work and return to the primary EntityOfConcern, relation or claim record named by value, source-use, mathematical-lens, architecture, project-action, evidence, assurance, gate, decision, or work problem that made the wording matter.

The detailed tables below are reference material for triggered cases. They are not a mandatory interpretation sequence. For a modest repair, one sentence, one trigger span, one selected interpretation, and one final wording or blocker is enough only when it discharges every FPF-governed use in that span.

When E.10 is applied beyond one sentence, add a bounded-text line: exact accepted DRR named by value, FPF pattern, monolith section, extracted host, review packet, pattern section, source span, or other named text span; trigger spans or grouped loci; selected interpretation; repair boundary; and expected non-use boundary. This prevents accidental whole-corpus sweeps and makes change impact inspectable.

When a wording-repair note needs formal fields, use only fields that preserve the current kind and relation: triggerSpan, boundedTextSpan, slotOrUsePosition, selectedInterpretation, LEX.TokenClass?, register, USM.Scope?, EntityOfConcern and Description-episteme boundary and specification use?, governingPattern, and finalWordingOrBlocker.

Local patterns may cite the relevant E.10 recognition row, but they should not reproduce large wording-recognition lists or create local lexical registries unless a named local application profile has its own primary EntityOfConcern, first useful move, and governing-pattern boundary. New recurring wording families enter E.10 only when they recur across FPF-governed texts and cannot be handled by one local pattern; specialized patterns carry the detailed ontology when the problem is no longer lexical. Stale or overly broad recognition rows are narrowed or retired.

Self-application is bounded. When E.10 is under improvement, use E.10 only for its own wording-trigger repairs; use E.21 for pattern-quality evaluation, E.22 for improvement-oriented quality-evaluation framing, E.23 for the improvement loop, E.2.DA for FPF-level Pillar effect, and neighboring pattern governing the claims for relation, episteme, publication, source-use, naming, or quality-word issues.

#Scope split

E.10 governs lexical conformance for FPF pattern text, extracted pattern hosts, FPF-Spec monolith text, FPF governing documents, accepted DRR text, and any project, product, research, engineering, or review text that deliberately uses FPF terms, pattern references, FPF relation names, FPF kind claims, FPF admissibility claims, or claims FPF conformance.

For ordinary source text, intake notes, seminar transcripts, external reviews, project documents, source publications, tool outputs, or other text that does not itself claim FPF-governed use, use C.2.P source-expression unpacking mode. That use may borrow E.10 tests, A.6.P relation repair, A.6.6 basedness repair, F.18 naming tests, or another governing pattern as methods, but it does not judge the source text as failed FPF wording.

#Problem and applicability table

E.10 is a lexical trigger scan and conformance pattern. Its primary EntityOfConcern for one pattern use is one wording use in conformant FPF text as a lexical or register sign: the head, register, morphology, local label, name candidate, kind-reference, relation-bearing cue, or replacement candidate used by the sentence.

E.10 recognizes which wording-use problem the sentence raises and selects the first applicable closure disposition. It does not itself become the ontology for the recovered relation, episteme, evidence, work, gate, decision, publication, architecture, characteristic, quality, or project-side FPF kind and reference named by value.

The full shared recovery order and applicability-row architecture belong to E.10.ARCH. E.10 keeps only the cheap scan, local rewrite option, direct known governing-pattern rule, compact applicability table, bounded complete result rule, and fail-closed non-use boundary.

exact is not a precision marker by itself. It is admissible only for literal identity or bounded source identity: exact sentence, source passage, trigger span, formula edition, same referent, or same declared CharacteristicSpace. When exact modifies an FPF pattern, kind, relation, record, object, field, use, claim, gate, source, or neighboring pattern, treat the phrase as trigger wording. Recover the governing pattern, FPF kind, relation record, source-use relation, admissible use, current ontic slot, relation position, use relation, or claim kind, value set, and scope by value, then write the recovered object. If recovery fails, use quote-only, reduced-use, blocked-use, or incomplete-rewrite disposition.

Classification is not closure. A conforming result must end in one of these by-value outcomes:

• local wording accepted or locally rewritten;
• selected precision-restoration pattern applied;
• neighboring FPF pattern governing that claim applied directly because the primary EntityOfConcern, relation record, or claim record is already recoverable;
• controlled precision-reduction result with declared loss and reopen condition;
• F.18 durable-name application after the kind under repair or relation is known;
• quote-only, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not-triggered disposition.

Grouping-mark self-application. Slash marks, paired-register marks, and, plus, &, and compact grouping marks are triggers only when the grouping itself carries FPF-governed meaning. Retain conventional notation, formula symbols, ratios, standard designations, discipline abbreviations, path-like quoted source tokens, product names, titles, URLs, or pattern-reference notation when the sentence's use is only notational; examples include ISO/IEC, ISO/IEC/IEEE, CI/CD, 1/2, ≡/⋈/⊂/⟂, and exact source tokens. Rewrite claim-bearing grouped heads into explicit lists, alternatives, relation sets, tuple-like records, or selected FPF kinds named by value. Do not let a slash hide one kind choice, a lazy and-or, a relation head, an admissible-use boundary, or a missing governing pattern.

| Source-expression, publication, publication form, face, PublicationUnit, FPF-governed use, or reading, read, or quality-read wording whose entity or construction is not yet recovered | Apply C.2.P first. If the recovered entity or construction is evaluation for improvement, then use the evaluation pattern governing that evaluation claim, such as E.22, E.21, or E.9.DA. | Source-local meaning, publication relation set, publication-form relation when that relation is being made, EntityOfConcern, project-side FPF kind, use disposition, evaluation claim or bundle named by value when that evaluation claim is being made, adjacent overread blocked, and reader move. | | Ontic, ontic candidate, concept cluster, semantic area, ontological neighborhood, slot relation, schema, data structure, record, card, table, or publication-form wording whose EntityOfConcern and publication boundary are hidden | Apply E.24.CD when repeated material may require an ontic candidate decision; apply E.24.PUB when the confusion is among ontic, ontic-description episteme, publication form, view, record, card, table, schema, or data-structure expression. Use E.24 or the direct governing pattern when the ontic or subject pattern is already recovered. | Candidate ontic cluster, EntityOfConcern, slot relation or slot-position, subject pattern, ontic-description episteme, publication form or source relation, admissible use, blocked publication-form overread, and remaining reader move. | | Admissibility-like, legal-looking, authority-looking, readiness-looking, validity-looking, pass-looking, fail-looking, or conformance-looking wording whose bearer, claim kind, source relation, value frame, bounded use, or governing pattern is hidden | Use the direct governing pattern when recoverable: evidence, assurance, gate, constraint validity, work, work plan, publication use, temporal use, source restoration, legal or external-rule claim, pattern-quality result, state-like value, or another claim-specific pattern. If the word is only the trigger, restore by E.10.ARCH and the claim-specific pattern; do not mint a generic admissibility object. | Bearer, claim kind, value frame or decision class, source relation when that relation is being made, bounded admissible use, non-admissible overread, reopen or stop condition, and governing pattern; otherwise quote-only, reduced-use, or blocked-use. | | Method, algorithm, program, solver, proof, recipe, workflow, process, procedure, access-path, query-plan, control-strategy, method algebra, method graph, selector calculus, or programming-paradigm wording whose slot or method-side relation is hidden | Recover the slot or method relation structure before rewriting: A.3.1 U.Method, MethodRelationStructure@BoundedContext when method composition or method-family relation is current, A.3.2 U.MethodDescription, A.6.0 formal-substrate declaration, C.29 mathematical-lens use, A.6.1 with E.20 mechanism claim, A.15.2 U.WorkPlan, A.15.1 U.Work, G.5 method-family registry or selector outcome, A.10 evidence relation, quote-only source wording, or another direct governing pattern. | Pre-repair and post-repair kind or relation position, current ontic slot, relation position, use relation, or claim kind, admissible use, blocked overread, and remaining reader move. Do not replace one umbrella with method, mechanism, algorithm, workflow, or method algebra by taste. | | Transformation, change, pipeline, dataflow, flow, network, circuit, path, slice, workflow, process, operation, or close change-situation wording whose object or slot is hidden | Apply A.3.4.P first. If U.Transformation, TransformationFlowStructure, mathematical description, method, method description, mechanism, work plan, dated work, functioning relation, temporal aspect, evidence, source, publication, gate, decision, assurance, result, or quote-only source wording is already recovered, use the direct governing pattern. | Recovered transformation identity or non-transformation value, recovered slot or filler, governing pattern, retained use, blocked overread, and remaining reader move. Do not replace one source label with flow, network, process, method, function, or transformation by taste. | | Declarative representation wording overread as imperative action, method, work, permission, release, evidence, or pattern dispatch: graph path, path slice, flow valuation, evidence path, state predicate, SQL-like query, checklist predicate, table, dashboard, publication face, mathematical representation, method-description representation, source-chain relation, file path, or FPF pattern relation | Apply C.2.P.DR unless the direct governing pattern already closes the repair. Accepted direct cases include E.18 graph path or PathSlice, A.10 evidence path for a claim, effect, or use, A.19.SPR state predicate or value, E.17 publication face, C.29 mathematical-lens use, A.3.1 method, A.3.2 method description, A.15.2 work plan, A.15.1 work occurrence, carrier file path, source-chain relation, and declarative pattern relation under E.8 or F.19. | Encountered representation, representation kind, represented object or claim, source expression or publication face when that relation is being made, tempting imperative overread, recovered governing pattern, admissible use now, non-admissible overread, stop or reopen condition. | | Architecture or structure wording with hidden selected structure, ArchitectureOf@Context relation, architecture-description use, structural-view use, source-return condition, or named C.30 subcase | Apply C.30.P. If A.22, C.30, C.30.ASV, or a named C.30 subpattern is already recoverable, use it directly. | Recovered selected structure, ArchitectureOf@Context, architecture description, structural view, source-return condition, governing-pattern result, or stop. | | Stratification or structure-source-label wording such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate when the FPF kind under repair, relation, claim-use, or source-use disposition is not yet recovered | Apply C.30.STRAT first. If a control-layer relation, module-interface relation, architecture-to-TransformationFlowStructure relation, mathematical scale relation, coarse-graining relation, publication relation set, gate relation, or neighboring use named by value is already recovered, use that governing pattern directly. | Recovered FPF kind, relation, claim-use, source-use disposition, and governing pattern; StratificationSourceLabelRepairNote; ordinary source label; quote-only, reduced-use, or blocked-use disposition; or stop. | | Characteristic, scale, score, coordinate, metric, indicator, threshold, comparison, or scalar-quality wording with hidden construction | Apply C.16.P. If A.17, A.18, C.16, A.19, C.25, C.29, E.21, or a governing pattern is already recoverable, use it directly. | Recovered Characteristic, Scale, Coordinate, Value, Score, unit, scoring method, comparison basis, indicator role, governing-pattern result, or stop. | | State-family wording with hidden bearer, state frame, value set, admissible use, or governing pattern: state, status, posture, readiness, stance, currentness, or close compounds | Apply A.19.SPR. If the governing pattern and state-like field are already recoverable by value, use that governing pattern directly. | Recovered bearer, state frame or governing pattern, value or classification, admissible use, non-admissible overread, reopen condition, governing-pattern result, or stop. | | Quality or evaluative characterization wording | Apply C.16.Q, C.25, E.21, or another characterization pattern governing the claim after any needed C.16.P repair. If the found problem is relation construction, apply A.6.P instead. | Quality-term repair, Q-bundle or pattern-quality coordinate use, relation split or bridge split when that relation or bridge claim is being made, and blocked scalar, gate, or release overread. | | Function-like wording with hidden FPF kind, relation, claim, view, or governing-pattern application: function, functional, functionality, effect, or close compounds | Apply A.6.F first when kind and relation recovery is needed. If the FPF kind named by value or pattern relation is already recovered by value, use the governing pattern directly. | FPF kind or relation named by value assignment, governing-pattern application, mathematical-lens use, quality pattern application, characteristic pattern application, module-interface pattern application, ordinary-prose demotion, or stop. | | Intentional loss of precision for a narrower admissible use | Apply the controlled precision-reduction pattern, normally A.6.3.CSC, with neighboring E.17.*, A.6.3.RT, F.9, or C.29 when that relation is being made. | Source-bearing side, declared loss, narrower admissible use, blocked downstream use, and reopen condition. | | Durable reusable head, lineage label, concept-set row, cross-context name-use, or UTS-facing name | Apply F.18 after the selected repair has recovered what the name would name. | Name card or naming row only for durable naming need; one-off local wording closes locally. | | Trigger found but kind, relation, substrate, governing pattern, admissible use, or remaining reader move cannot be recovered | Fail closed. | Quote-only wording, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not FPF-governed wording. |

reading, read, and quality-read are trigger wording only when the sentence uses the word to carry interpretation, publication use, source-use assignment, evaluation, comparison, evidence, gate, work, decision, release, assurance, or admissibility claim. Do not create ReadingPrecisionRestoration. Recover the actual EntityOfConcern, publication relation position, evaluation claim or bundle, relation, or work-side kind and apply C.2.P, E.17.ID.CR, E.22 plus object-under-improvement evaluation named by value, A.6.P, or the neighboring FPF pattern governing that claim.

function, functional, functionality, and effect are trigger wording when the FPF kind named by value, relation, claim, view, or governing-pattern application is hidden. Do not assign the wording by architecture default. A.6.F remains the function-like wording unpacker; mathematical function, mapping, relation, loss, objective, value functional, or operator goes to C.29 when mathematical-lens use is being claimed. Functional-architecture use goes to C.30 or C.30.ASV when the architecture or structural-view claim is recovered by value; architecture-to-TransformationFlowStructure use goes to the current Architecture Transformation-Flow Structure Relation (C.30.TFS-REL).

layer, level, tier, stack, ladder, rung, block, expert, cache, router, and gate are source labels when they first arrive from engineering, mathematical, publication, or project prose without a recovered FPF kind. Do not mint U.Layer, U.Level, U.Tier, U.Stack, or a universal stratification kind. Use C.30.STRAT to recover the governing pattern, or go directly to the governing pattern when the FPF kind under repair, relation, claim-use, or source-use disposition is already recovered by value: C.30.LCA for control-layer relations, A.6.M for module-interface relations, the current Architecture Transformation-Flow Structure Relation (C.30.TFS-REL) for architecture-to-TransformationFlowStructure claims, E.18 for selected transformation-flow structure, C.16.P or C.29 for scale relation, coarse-graining relation, or mathematical use, C.2.P for publication relation set or source-use relation, and gate patterns, work patterns, or decision patterns when those claims are being made.

Description, publication, and representation mediation source words need the same recovery discipline. Treat stack, lane, profile, mediation, binding, representation, publication, model, space, graph, latent, weights, embedding, vector store, carrier, dashboard, posture, route, path, surface, and close compounds as trigger wording when the sentence has FPF-governed use and the relation position is hidden. Recover the current EntityOfConcern, relation position, direct governing pattern, admissible use, blocked overread, and remaining reader move before writing the final phrase. Do not replace the trigger with another umbrella head; do not mint a durable name unless F.18 is explicitly selected.

Local patterns may cite the relevant E.10 recognition row, but they must not reproduce the wording-recognition table or create local lexical registries unless a named local application profile has its own primary EntityOfConcern, first useful move, and governing-pattern boundary. Specialized restoration patterns carry the detailed ontology when the problem is no longer lexical.

#Bounded complete result and direct known governing-pattern rule

The direct known governing-pattern rule is:

If the governing pattern and primary EntityOfConcern, relation record, or claim record are already recoverable by value, use that governing pattern directly.

Apply a precision-restoration realization pattern such as A.6.P, A.6.F, C.2.P, C.30.P, C.30.STRAT, C.16.P, C.16.Q, or A.19.SPR only when wording hides the EntityOfConcern under repair, relation, characteristic, scale, score, quality characterization, source-use disposition, state-family field, admissible use, or remaining reader move.

The bounded complete result is the shortest result that fully recovers the kind under repair and remaining reader move. Shortest is not lowest effort: every FPF-governed use has a by-value disposition, and not triggered or ordinary prose must be stated as such with the checked span.

• local rewrite for a one-sentence local ambiguity;
• compact repair note or row when one precision-restoration pattern is needed;
• governing-pattern application when the FPF kind under repair, relation, claim-use, source-use disposition, or admissible-use boundary is already recoverable;
• full restoration check only when several claims being made, admissible-use cases, source-currentness relations, cross-pattern authority, or downstream reliance remain under repair;
• fail-closed non-use when recovery is not possible.

After kind and governing pattern recovery, state the remaining admissible reader move: what the reader may now do, why the distinction matters, or which FPF pattern now carries the claim being made. If the repaired wording is type-correct but inert, the repair is incomplete.

Value-substitution check. A wording repair also fails when it optimizes lexical purity while making the working text worse: less readable for its declared reader, less affordable to apply, less semantically composable with neighbors, less clear about the primary EntityOfConcern, relation record, or claim record, or less action-guiding. In that case, narrow the repair, keep ordinary wording with an recovery note with recovered kind and use, use the direct governing pattern, or leave the issue blocking by value. Do not trade real kind, relation, source-use, or admissible-use recovery for smooth prose; this check prevents precision-restoration theatre, not ontology repair.

Tool-assisted trigger inventories may help find candidate spans, but they cannot close ontological precision repair. Closure remains recovered kind, recovered relation or substrate, admissible use, non-admissible overread, and remaining reader move by value.

Replacement-candidate closure. A repair that replaces one trigger word with another word or phrase is not closed until the replacement candidate itself passes the same E.10 trigger scan. If the candidate is another umbrella word, quasi-scale, process metaphor, role-free deontic word, or untyped head, recover the kind named by value, relation, admissible use, and governing pattern, apply F.18 when a durable name is being minted, or fail closed. A bounded repair may therefore require repeated E.10 passes until the candidate wording reaches a stable closure point: ordinary wording with no FPF-governed use, local repair with recovered kind and use, governing-pattern application, F.18 durable-name result, controlled precision-reduction result, or explicit blocker. Do not accept a smoother synonym as repair evidence.

#Wording-Use Trigger Check Registry

E.10:0.2 is the shared trigger scan. This section is the check registry for high-pressure wording in FPF-governed text and source prose being unpacked for possible FPF use. It does not create a second all-purpose ontology and does not create domain-pattern outcomes. It selects a closure disposition: local rewrite, selected precision-restoration realization pattern, governing pattern, controlled precision reduction, F.18 durable-name application, or fail-closed non-use.

The words below are frequent in conformant FPF text and in project texts that deliberately use FPF-governed terms, pattern references, relation names, or conformance claims. Files carrying FPF pattern text are useful search examples, not the boundary of language cleanup: the same rule applies wherever the text under repair is claim-bearing FPF, project guidance that deliberately uses FPF-governed terms, pattern references, relation names, or conformance claims, or source prose being unpacked for possible FPF use. They are not banned words. They are words that must trigger kind recovery when they carry ontology, authority, evidence, or admissibility claim. The table gives alternatives to recover from; it must not be copied as a group kind. The chosen result may be a local wording repair, a selected restoration pattern or governing-pattern application, controlled precision reduction, or an explicit not-triggered disposition.

#Lexical Trigger Rewrite Rules

#EntityOfConcern, primary entity of concern, and local topic wording

Do not replace every topic-like or object-like phrase with EntityOfConcern. Classify the sentence first.