#Section E‑I - The FPF Constitution

Preface node heading:section-e-i-the-fpf-constitution:38722

#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.

#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.

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; portfolio‑first 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 lawfulness 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, owner, 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): portfolio‑first 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.

#Relations

• Depends on: pat:constitutional/vision – pillars operationalise the mission.
• Refined by: All subsequent patterns in the Core Specification.
• 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

#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 (owner, 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). Portfolio‑first 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 contracts) 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 locus is sandboxed; leaving the sandbox requires an explicit GateCrossing with a published CrossingBundle (E.18 + F.9/A.27).

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 Artefact Architecture

#Problem frame

The FPF ecosystem produces a wide range of artifacts, from timeless, normative principles to rapidly evolving pedagogical materials and executable tools. If these different types of artifacts 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 artefact 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 pattern language of FPF. It is the single source of truth for all universal concepts, rules, and invariants. It is defined to be tool-agnostic and notation-independent. This family represents the timeless "law" of FPF.

2. The Tooling Reference: This family contains executable artifacts that implement or verify the normative rules of the Core. This includes reference linters, simulators, and data schemas. This family is the "instrument" that makes the law of the Core operational.

3. The Pedagogical Companion: This family contains non-normative, didactic materials designed to help humans learn and apply FPF. This includes tutorials, worked examples, and playbooks. This family is the "textbook" that explains both the law and the instruments.

#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 timeless "why" and "what" (the Conceptual Core) from the practical "how" (Tooling) and the educational "how-to-learn" (Pedagogy), 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 Artefact 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 artefact 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/ladder 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
   Core artefacts SHALL NOT import Tooling or Pedagogy artefacts. Tooling artefacts SHALL NOT import Pedagogy artefacts.

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 layer definition: pat:constitution/artefact‑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 home 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 not the same thing as first-practical entry

The macro-order of the document is a didactic scaffold, not a universal practical workflow. Route-bearing navigation surfaces such as the Preface, J.4, route-bearing owner patterns, and route-indexed walkthroughs are informative navigation only: they may cross Parts when that is the first honest entry for the burden at hand, and they do not create a second normative lifecycle.

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)

#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. Auditability – missing sections hide safety checks (Archetypal Grounding, Bias‑Annotation).

#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 top-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.
• The escape hatch Not applicable is permitted only where explicitly stated below; when used, it MUST include a short justification (1 paragraph).

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; System / Episteme; Not applicable allowed only with justification)
6. Bias‑Annotation
7. Conformance Checklist
8. Common Anti‑Patterns and How to Avoid Them (Not applicable allowed only with justification)
9. Consequences
10. Rationale
11. SoTA‑Echoing (post‑2015 practice alignment; terminology drift & deltas; Not applicable allowed only with justification)
12. Relations
13. Footer marker

Footer marker. End each pattern with a single visible sentinel heading line on its own: ### <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). Legacy text may use -; tooling SHOULD treat the two as equivalent, and authors SHOULD migrate to - when touching a heading.

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 legacy 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 live). Pattern kind (e.g., Architectural / Definitional) MUST be declared in the Header block, not encoded into the heading text. Normativity (normative / informative) MUST also live 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 artefacts) — 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/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 enforceable as part of a pattern’s contract, 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 while allowing explicit Not applicable statements when justified. 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.

S-0 (Narrative Flow Seven-Step Heuristic) — explanation Narrative flow is recommended to follow these steps: Hook -> Frame -> Weave -> Anchor -> 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 surface and assurance surface

Every canonical pattern SHALL stabilise one governed object 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 surface forms of one governed object and which would instead name a different act, process, work-product, or owner lane. Recognition and assurance surfaces may refine that object differently, but they must not silently swap the central object 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 governed object 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 surface and assurance surface. The earlier provisional recognition shell / assurance shell wording is retired. These names refer to two reading-order surfaces inside one pattern; they do not mint new owner kinds, new publication-surface kinds, or a second face family. A later third didactic support surface 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 surface is the first reading surface. 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 lives 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 governed object is actually being kept stable;
• and, when technical terms must appear early, a pairwise plain gloss for each early high-pressure term.

The assurance surface is the second reading surface. It carries the heavier load-bearing material that makes the pattern reviewable and auditable:

• declaration blocks and typed fields when those are part of the contract;
• representation ontology or object-of-talk discipline;
• any minimal modeling or mathematical lens that keeps the governed object stable;
• law, invariants, admissibility, and reroute or neighbouring-owner conditions;
• SoTA-Echoing when it is carrying live explanatory load;
• and the review hooks that let a stronger reading be checked explicitly.

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

If a pattern claims universal or transdisciplinary status, that claim must already be visible in the recognition surface. It is not enough for universality to appear only later in a law sheet, declaration block, or SoTA-Echoing rationale. A broad claim should therefore be demonstrated in the recognition surface 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 is load-bearing, the practical implication of those rows should be recoverable from the recognition surface and case bank rather than remaining a late-only justification layer.

A third didactic support surface means enough didactic and operational support that the pattern survives without nearby project documents. Typical signs include:

• at least one concrete source/result slice in Archetypal Grounding when the pattern governs transforms or publication change;
• at least one boundary-heavy example or anti-example when nearby owners are easy to confuse;
• reviewer guidance that tells what to inspect first and what failure mode forces reroute;
• local mini-definitions or glossary support 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 support 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 host-relation role-word discipline

FPF pattern prose is not free-form descriptive English. When authors name a package-form or a host 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 host 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.

• owner = the pattern that owns the primary semantic law surface for the family;
• specialization = a named refinement under an existing owner;
• overlay = a cross-cutting governance or reading layer over existing owners;
• profile = a declarative review/use surface derived from a host owner rather than a replacement owner;
• family = a recurring class of cases governed by one owner surface;
• bundle = a packaged set of defaults, allowances, or coordinated members;
• cluster = a navigation or reading grouping; not by itself an owner claim;
• suite = a coordinated set of members with explicit suite semantics under the right host law;
• pack = an editorial or review grouping, not automatically a semantic owner;
• kit = a reusable coordinated publication or contract surface with kit-level semantics under the right host law;
• record = a case/report/review artefact;
• umbrella = a provisional or review-stage head spanning possible subfamilies before final owner freeze.

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 host relation. When the host relation matters, it must be stated directly: specialization under ..., hosted profile under ..., overlay over ..., bundle under ..., or another equally explicit formulation.

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

#Reader-role discipline for live pattern prose

A live 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 load-bearing 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.

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-load-bearing guidance must not do the work of:

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

If architecture-placement commentary is still helpful, the default home is a separate companion note or ADR-like architecture surface. A live 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 surface correctness

Human-facing fit is also subject-domain fit. A recognition surface that starts from internal taxonomy, owner-lane convenience, or package-architecture wording before the problem-owning domain moment is still under-authored even if its later law surface is correct. When a broader umbrella name and a narrower operative branch are both live, the first surface 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 surface-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 lawful but does not yet make the working situation, practical payoff, governed object, or first reading surface visible enough.

For canonical patterns, the first reading surface should behave as a recognition surface and the heavier burden should remain in an assurance surface. 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 entry;
• a concrete working situation in Problem frame, not only taxonomic or owner-lane 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;
• a short Not this pattern when boundary for the ordinary nearby misroutes;
• 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 support is load-bearing, 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 high-pressure technical terms that must appear before the heavier declaration surface arrives;
• when SoTA-Echoing is carrying live explanatory load, 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 surface and the heavier declaration / review / assurance surface;
• and, if the draft implicitly serves several reader families, an explicit primary working reader, primary concern surface, or primary viewpoint.

Entry-bearing mini-block (informative). When a canonical pattern genuinely functions as a local front door for one first practical route, the recognition surface SHOULD add one short routing block near the top with: Start here when, First output, Typical next owners, and Common wrong escalations / reroutes.

This mini-block does not replace Use this when, Problem frame, Consequences, or ordinary Not this pattern when guidance. Its job is to shorten first-minute routing for a cold reader without silently widening owner scope, changing route-count decisions, or relocating semantics out of the pattern that actually owns them.

If the block points to neighbouring owners, it should name those owners as next moves or reroutes rather than as hidden co-owners of the current pattern.

If the pattern claims broad, universal, or transdisciplinary usefulness, that breadth should already be visible in the recognition surface. At minimum the recognition surface should show at least three heterogeneous reader or domain situations rather than one narrow lane 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, layering, and surface consistency: the recognition surface must help a working reader recognise the pattern early, while the assurance surface continues to carry the full semantic burden. If the pattern uses technical lexicon, ontological distinctions, or a mathematical lens, those supports must remain recoverable, but the first reading surface should not require the reader to decode that full stack before recognising the working situation. The assurance surface may tighten or discipline the recognition surface; it must not silently shift what the recognition surface claimed. 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/Work). Avoid “validity”, “process”, “actor”, “system”, “mechanism” unless mapped to kernel types.

#Archetypal Grounding (System / Episteme)

Note: Prefer examples that reuse FPF’s own 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 explicit optionality (Not applicable) and the requirement to justify omissions in‑text.

#Conformance Checklist

CC style (canonical). Conformance Checklist items are obligations/conditions in the authoring plane: they constrain artefacts that claim conformance (and the reviewers/validators that accept them). A CC clause of the form “X SHALL ...” is to be read as “In a conforming artefact, X SHALL ...”, not as a deontic statement about the modeled world.

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/contract patterns, prefer A.6.B-routed 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 & deltas to contemporary State‑of‑the‑Art)

Purpose. Make each pattern’s relationship to contemporary best-known 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 layer, but it is a load-bearing alignment surface: the Solution, Conformance Checklist, Relations, and other load-bearing sections must reflect the stance stated here or explicitly justify divergence.

Minimum contents (obligations).

1. Evidence binding (no duplicate SoTA). If a SoTA Synthesis Pack exists (G.2), this section SHALL cite its ClaimSheet IDs / CorpusLedger entries / BridgeMatrix rows as the source‑of‑truth for claims and report adopt/adapt/reject consistent with those IDs. Avoid forking an untracked SoTA narrative.
2. Sources (post‑2015). For Architectural patterns, cite ≥ 3 primary SoTA sources (standards/papers/books), with at least two independent Traditions. For Definitional patterns, cite ≥ 1 post‑2015 primary source and, where relevant, a short note on terminology drift/deprecations.
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-weaker practice, that divergence MUST be stated explicitly.
4. Practice alignment. For each cited item, state what is adopted/adapted/rejected and why (2–4 sentences).
5. Scale legality. If numeric operations are implied, bind to ComparatorSet/CG‑Spec and declare partial‑order stance (no hidden scalarisation).
6. Cross‑Context reuse. Any reuse across U.BoundedContext must surface Bridge+CL/Φ_plane policy‑ids (penalties affect only R_eff).
7. Lexical hygiene. Avoid “mapping” unless you mean an explicit Bridge/translation relation with loss notes.

Writing guidance (readability). Write short paragraphs, not tag lists. For each Tradition, provide (a) a one‑sentence capsule of the practice, (b) a one‑sentence comparison to the pattern’s Solution, (c) a one‑sentence 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–2 sentences as above. Vendor/tool tokens, file formats, or data schemas are out of scope.

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

#Relations

• Builds on: E.6, E.7
• Constrained by: Guard‑Rails E.5.1–E.5.4 (lexical firewall, notation independence, etc.)
• Constrains: All patterns; the DRR template references the same section order.

#E.8:End

#Design‑Rationale Record (DRR) Method

#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 artefact 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

Any proposal to add, modify or deprecate a NORM, A, D, or GOV rule MUST be accompanied by a Design‑Rationale Record. By default, it contains exactly four conceptual components (below); a lightweight editorial variant is permitted by CC‑DRR.5.

The DRR lives outside the normative Core. Upon acceptance, its Decision SHALL be applied to the relevant pattern(s) as explicit normative text (the change is "in the Core"; the DRR is not).

To preserve P‑2 Didactic Primacy without duplicating meta‑text, stable and reusable parts of the DRR’s Rationale and Consequences SHOULD be distilled into the 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.

#Archetypal Grounding (System / Episteme)

#Conformance Checklist

#Consequences

#Rationale

FPF evolves by explicit, reviewable deltas rather than silent edits. The DRR is the minimal structured argument that keeps P‑10 Open‑Ended Evolution compatible with P‑1 Cognitive Elegance and P‑2 Didactic Primacy: the Core stays succinct and teachable, while the “why” is recoverable. Pointer‑based DRRs (CC‑DRR.1a) prevent duplicated prose, and distillation into informative pattern sections (CC‑DRR.4) keeps the spec itself learnable.

#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: pat:authoring/code‑of‑conduct (E 12) – etiquette for DRR debate

#E.9:End

#Unified Lexical Rules for FPF (LEX‑BUNDLE)

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

Status & placement. Part E.10 (“Lexical Discipline & Stratification”); complements E.10.D1 (D.CTX), E.10.D2 (I/D/S), and the DesignRunTag / CtxState boundary discipline (A.15; E.18), and is referenced by F‑cluster naming practices (F.4–F.8). This bundle consolidates all lexical constraints in one place so authors can cite “LEX‑BUNDLE” instead of listing rules scattered across documents.

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 & Roles. Coordinates with. A.2/A.15 (Role–Method–Work alignment), A.10 (Evidence Graph Referring), B.1/B.3 (Γ‑algebras & assurance), F‑cluster (context of meaning; Bridges).

#Problem context

Intent. Provide one normative rule‑set that makes FPF language unambiguous, composable across contexts, and teachable by design. Authors, reviewers, and tooling can point to LEX‑BUNDLE as the single source of truth for:

• Vertical stratification (Kernel ↔ Extensions ↔ Context ↔ Instance);
• Twin registers (Tech/Plain) with safe synonyms;
• Naming morphology (allowed suffixes & style) for the kernel’s core objects;
• Minimal Generality tests (names are neither parochial nor vacuous);
• Canonical rewrites for overloaded words (e.g., process, function, service);
• Conformance checks and minimal examples.

Scope. Applies to: (a) Core (Parts A–G), (b) Extensions patterns specs (CAL/LOG/CHR), (c) Context glossaries that claim FPF conformity, and (d) Diagrams/prose in normative text. It does not constrain Tooling or Pedagogy wording other than where they quote Core semantics.

#Problem

1. Polysemy drift. Process, function, service, agent, activity slide between structure, recipe, execution, and promise.
2. Cross‑context collision. A label (e.g., Owner) is assumed “global” though meanings differ per U.BoundedContext.
3. Name bloat vs. parochialism. Either hyper‑specific domain names leak into core types, or vague umbrella names obscure invariants.
4. I/D/S collapse. Authors mix intension (the thing), description (how we describe it), and specification (testable criteria).
5. Register soup. Tech terms bleed into Plain pedagogy and vice‑versa, inviting category errors.

#Forces

#Solution — the LEX‑BUNDLE rule‑set (overview)

LEX‑BUNDLE aka ULR (Unified Lexical Rules) is a compact set of register, naming, and rewrite rules with conformance checks.

1. Vertical Stratification Ladder (E.10 → four strata);
2. Twin‑Register Discipline (Tech/Plain pairs);
3. Minimal Generality (MG) principle + tests;
4. Morphology & Style (suffixes, casing, reserved prefixes);
5. Canonical Rewrites for overloaded words (L‑rules);
6. Conformance Checklist (CC‑LEX) and Regression Stubs (RSCR‑LEX).

Below are the normative clauses

#Vertical Stratification Ladder (four strata; no cross‑bleed)

Rule V‑0 (Strata). Every lexical item in a conformant text belongs to exactly one stratum:

1. Kernel — U.* types, kernel relations, invariants (e.g., U.Holon, U.Role, U.Method, U.Work, U.PromiseContent).
2. Extension patterns — CAL/LOG/CHR exports (e.g., Sys‑CAL, KD‑CAL, Agency‑CHR) that extend but do not override Kernel.
3. Context — a U.BoundedContext with its Glossary, Invariants, Roles, and Bridges (local Context of meaning).
4. Instance — concrete identifiers (holders, role assignments, works, carriers).

V‑1 (Unidirectional meaning). Meaning flows downward only: Kernel → Extention patterns → Context → Instance. No stratum may redefine a higher stratum’s term; it may only specialise or bridge it.

V‑2 (Strata vs authoring stances). The four lexical strata above constrain tokens. They are independent of an artefact’s stance (its CtxState pins such as DesignRunTag, ReferencePlane, and Locus). Strata answer “what words mean here”; stance answers “where this claim lives in the flow” and which evidence‑lane expectations apply.

V‑3 (Citation style). When a Context term is used, its Context must be visible at first mention (e.g., OwnerRole:ITIL_2020). If an author needs Cross‑context reuse, they MUST cite a Bridge with a stated Congruence Level (CL) (see F.9).

V‑4 (Firewall). Tooling/Pedagogy idioms shall not leak into Kernel prose (DevOps Lexical Firewall). CI/CD jargon, file formats, or API names MUST NOT appear in Core definitions. (Pedagogy may use them as examples only, in the Plain register, with Tech anchors present.)

#Ontology Guards

#Tech register ontology guards

Purpose. This section stabilises the Tech register of the kernel lexicon by enforcing head‑anchored naming, explicit object‑of‑talk, I/D/S morphology, disciplined treatment of Role / Holder, and Domain usage consistent with D.CTX and UTS. It aligns with F.4 Role Description (RCS/RSG), F.11 Method Quartet Harmonisation, and F.17 UTS. Scope: Guidance is register‑agnostic and applies to the whole FPF; examples are illustrative and MUST pass Minimal Generality & Domain Anchoring (MG-DA) and other rules of lexical governance pattern E*. This guidance applies to kernel and non‑kernel components (including Part G and patterns in Part C) and SHOULD be reused across extensions.

Onto1 — Head‑anchoring (use Kernel heads + pass LEX.TokenClass / I/D/S gates)

• Rule: The head noun of a term MUST explicitly signal the kind (System, Holon, Role, Work, Episteme, Tradition, Lineage, Characteristic, Method, Profile, Description, Spec, Flow, Card, Pack, Dashboard, …).
• Figurative heads with obvious overload (“Tradition”, “family”, “process”, “function”) are forbidden in the kernel. Use plain twins only with a 1:1 Tech mapping and declare LEX.TokenClass for the Tech token. They MAY appear only in the Plain register as 1:1 twin‑mappings to a Tech token, but MUST NOT appear in the Tech register. Plain language should minimise lexical error from overloaded terms; use plain‑twin lexical guards.
  • Do: IncidentDashboard, MethodSpec, TraditionProfile, FlowDescription.
  • Don’t: IncidentBoard, TDD Tradition, Production Process (kernel), Service Function (kernel).

Onto2 — I/D/S on the surface (Intension/Description/Specification morphology) (ref. E.10.D2)

• Rule: Any intensional object is a bare head: Method, Tradition, Characteristic. Any description appends …Description: MethodDescription, TraditionDescription. Any testable specification appends …Spec and presupposes acceptance criteria and harnesses (normative in E.10.D2). E.g., Algorithm is a species of MethodDescription for a computer (a system in the role of information transformer); If expressed in a formal language and bundled with acceptance tests, it is MethodSpec (per F.11). If expressed as pseudo‑code, it is MethodDescription.
• Extension: Apply the same pattern to non‑method objects where appropriate: FlowDescription/FlowSpec, SystemDescription/SystemSpec.
• Do: SamplingMethod - SamplingMethodDescription - SamplingMethodSpec.
• Don’t: SamplingAlgorithm (when it is just prose), SamplingProcessSpec (head not signalling kind).

Onto3 — Roles, Holders, and Carriers (holonic) (ref. F.4 / F.5)

• Rule: The playable intention is named …Role and described through F.4 Role Description (RCS/RSG), e.g., SafetyOfficerRole, ReviewerRole. The party assuming a role is the Holder. Use the Holder#Role:Context pattern to type the assumption (where Context is a U.BoundedContext), e.g., Team‑Alpha (U.Holon) is Holder#SafetyOfficerRole:Plant‑Ops. Carrier is reserved for a system that bears a symbol of episteme (U.Episteme, Tradition, Lineage, Profile, repertoire) independent of any concrete role assumption, e.g., LeanTraditionCarrier, CalibrationLineageCarrier. Avoid Artefact as a head in the kernel: it is ambiguous between a Carrier (e.g., document), a system “made by” some transformer, or an episteme abstracted from its carrier.
• Register note: Job titles (Reviewer, Owner, Lead) belong in the Plain register and MUST twin‑map to explicit Tech …Role tokens.
• Why: This resolves the inconsistent “role carrier vs role holder” usage: use “Holder” for holonic role assumption, keep “Carrier” for the system that bears a symbol of episteme.
• Migration note. Legacy …CarrierRole MUST be rewritten to Holder#…Role:Context. Use SCR‑LEX to enforce the rewrite.
• Do: ReviewerRole (or AssessorRole), Holder#ReviewerRole:Journal‑Issue‑42 (or Holder#AssessorRole:Procurement‑Lot‑42); LeanTraditionCarrier (U.Holon), independent of any particular role. Don’t: Reviewer (as a kernel type), ReviewerCarrier (to mean a role holder), SystemReviewer (role collapsed into a type).

Onto4 — Domain only as a catalog mark (ref. E.10.D1 D.CTX; publish stitching on UTS)

• Rule: Domain is not a kernel kind and carries no semantics, inheritance, or reasoning rights. It is a catalog mark that groups several U.BoundedContext entries.
• Required stitching (see D.CTX & UTS). Any use of Domain MUST present: 1. the enumerated list of ContextId in D.CTX, and 2. the corresponding UTS strings (F.17) with twin labels.
• “Discipline ≠ Domain.” Domain labels are catalog‑only (D.CTX + UTS); Discipline is a CG‑Spec‑governed holon (U.Discipline). Cross‑use requires Bridge (F.9) + CL; LexicalCheck MUST fail texts that equate Domain with Discipline.
• Governance. No “Domain … governance”. Rules of comparability/aggregation belong to Discipline/CG‑Spec (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Γ‑fold, CL‑routing), not to Domain. Prefer DomainFamily + stitching over inventing new “Domain” types.
• Do: DomainBundle: ClinicalSafety → {ContextId: AdverseEvents, DeviceLabelling, …} + UTS twins.
• Don’t: ClinicalSafetyDomain as a type with inheritance; Domain Governance sections in Tech.

**Onto5 — Always state the object‑of‑talk

• Rule. The definition or first line of a gloss MUST state what the term is about: a U.Holon/U.System, a U.Episteme (Tradition, Lineage, Profile), a Role, a Work execution, a Characteristic, or a Carrier.
• Do: “Object‑of‑talk: ReviewerRole — a role intention playable by a holon within an editorial context.”
• Don’t: “Reviewer — a person who …” (blurs kind and object‑of‑talk).

Onto6 — Bans and canonical rewrites (mirror E.10 § 9 L‑rules; do not duplicate tables)

• process / function / activity → Work / MethodDescription / Flow (context‑dependent).
• Tradition → Tradition (Tech); leave “Tradition” only as a Plain twin with an adjacent Tech label.
• domain → DomainFamily + {ContextId list} + UTS twins.
• legacy …CarrierRole → Holder#…Role:Context.
• ambiguous Owner in role names → prefer StewardRole / CustodianRole / explicit responsibility head.
• job titles (owner, lead, champion) in the kernel → use explicit …Role names; keep titles in Plain with twin‑labels.
• Do: FlowDescription: ReturnsHandling, Tradition: Test‑Driven, Holder#CustodianRole:Asset‑Ledger.
• Don’t: Returns Process, TDD Tradition (kernel), Ledger Owner (underspecified).

Worked mini‑examples across arenas

1. Software engineering: BuildFlowDescription, CIHarnessSpec; Holder#MaintainerRole:Repo‑X. Avoid Build Process, Repo Owner.
2. Applied research / experimentation: SamplingMethodSpec, CalibrationLineageCarrier; Holder#ReviewerRole:Grant‑Call‑Y. Avoid Sampling Algorithm (if prose), Lab Owner.
3. Production / service management: ShiftWork, SafetyOfficerRole; Holder#SafetyOfficerRole:Plant‑Ops. Avoid Safety Officer as a type, SafetyDomain Governance.
4. Operations research / optimisation: RoutingMethodDescription, CostCharacteristic; Holder#ModelStewardRole:OR‑Program. Avoid Routing Function, Model Owner.
5. Healthcare / clinical ops: CarePathwayFlowDescription, MedicationAdministrationWork; Holder#AttendingPhysicianRole:Ward‑12. Avoid Care Process, Ward Owner.
6. Finance & accounting: ReconciliationMethodSpec, JournalPostingWork; Holder#TreasuryStewardRole:Liquidity‑Book. Avoid Reconciliation Process, Account Owner (underspecified).
7. Legal / compliance: RetentionPolicySpec, InvestigationWork; Holder#DataProtectionOfficerRole:Org‑X. Avoid Compliance Function, Data Owner (underspecified).
8. Cloud / IT operations: IncidentFlowDescription, RunbookMethodSpec; Holder#OnCallEngineerRole:Service‑Y. Avoid Incident Process, Service Owner (underspecified).
9. Logistics / supply chain: PickingWork, RoutingMethodSpec; Holder#DispatcherRole:Hub‑Z. Avoid Picking Process, Fleet Owner.
10. Construction / civil engineering: PermitAcquisitionFlowDescription, InspectionMethodSpec; Holder#SiteStewardRole:Project‑Lot‑17. Avoid Inspection Process, Site Owner.
11. Emergency response: TriageMethodDescription, EvacuationFlowDescription; Holder#IncidentCommanderRole:Event‑R. Avoid Triage Function, Incident Owner.
12. Agriculture: IrrigationFlowDescription, SoilSamplingMethodSpec; Holder#FieldStewardRole:Plot‑17. Avoid Irrigation Process, Field Owner.

Checklist before minting a KernelToken

• Head noun signals kind (Onto1).
• I/D/S morphology correct (Onto2).
• If role‑related: Role vs Holder vs Carrier separation observed; holonic scope explicit (Onto3).
• Any Domain mention stitched to D.CTX and UTS; no norms on Domain (Onto4, Onto6).
• Object‑of‑talk declared (Onto5).
• SCR‑LEX rewrites checked / legacy forms migrated (Onto6).

Note on registers. Keep figurative or business‑casual terms in the Plain register only, with strict twin‑label links to the Tech token (LEX‑BUNDLE). In the Tech register, speak in KL‑CAL: episteme‑about‑epistemes (Tradition, Lineage, Profile), not in catalogue‑admin idioms.

• Onto‑Deon — Deontic lexicon guard (Core register)
  Rule. In the Conceptual Core, avoid using “Standard” as the head noun of an intensional object name unless the object is an explicit deontic speech-act under the Gov lens (cf. E.3).

For interface/boundary invariants and public commitments of things (holons, interfaces, ports), prefer intensional names like InterfaceContract, ComplianceProfile, AcceptanceSpec, InteropProfile, etc.

Use the word standard for an artefact (Description/Specification) that is intended to be complied with (and that has explicit compliance checks).

If an intensional object is currently named … Standard, rename it to a proper intensional name, and (optionally) add a separate Description/Specification artefact that contains the standard text and the intended compliance checks. Rewrite hints (Tech → Tech).
publication Standard → publication standard;
frame Standard → frame standard;
measurement Standard → measurement standard;
Method Interface Standard (MIC) → Method Interface Standard (MIS) (alias acceptable during transition);
Boundary‑Inheritance Standard (BIC) → Boundary‑Inheritance Standard (BIS) (alias acceptable during transition).
Rationale. Keeps Core prose centred on intensional objects and their boundary invariants; reserves deontic obligations for governance contexts and U.PromiseContent‑like promises. Do not misuse “plane”: deontic speech‑acts are analysed via the Gov lens, while ReferencePlane remains {world | concept | episteme}.

#Twin‑Register Discipline (Tech / Plain)

Plain twin (LEX). A registry entry pairing the authoritative Tech label with a display‑only Plain label for one U.Type in one U.BoundedContext; governed by PTG (Plain Twin Governance; in the LEX registry) and referenced by Twin‑Map ID (LEX). “Plain twin” ≠ the Plain register (the register is where twins may be used; the twin is the 1:1 mapping). Convention. In this spec, Plain (capitalized) names the register; plain twin (lowercase) names the 1:1 mapping entry.

Rule R‑0 (Registers). Every Kernel and Extenstion patterns concept has a Tech label (the testable semantic token) and an optional Plain label (didactic synonym). The Tech label is authoritative; the Plain label is permitted only in expository text and must map 1:1 to the Tech meaning inside the current Context.

#Allowed pairs (normative table; examples)

R‑1 (Plain first‑use). At first use in a section, show Tech label and (optionally) the Plain twin: “…a U.Method (the how‑to), described by a U.MethodDescription (the recipe) …” R‑2 (No unpaired Plain in CC). Conformance Checklists must use Tech labels only.

Domains can mint aliases inside their U.BoundedContext glossary; all aliases must map 1:1 to a Tech label (SenseCell row in the Context’s Concept-Set Table), and if exported across Contexts, via an Alignment Bridge (with CL/Loss).

Make “plain twins” (reader‑friendly labels) safe by construction, not just style. The plain twin must not change kind, scope, or reader expectations versus the canonical Tech name; it is display‑only and context‑local.

• Tech name (tech) — the canonical, kernel‑conformant label used in normative clauses (e.g., U.RoleAssignment, TransformerRole).
• Plain twin (plain) — a didactic display alias permitted in expository prose and UI surfaces inside one U.BoundedContext.

Principle: Meaning lives in the Tech name; the plain twin may never move meaning. (Locality is enforced by U.BoundedContext and Bridges.)

#Plain Twin Safety constraints (normative)

CC‑TWIN‑1 - One‑to‑one & local. Each Tech name has at most one plain twin per U.BoundedContext; the same plain twin MUST NOT point at more than one Tech name in the same Context.

CC‑TWIN‑2 - Sense‑equivalence proof. A plain twin MUST bind to the same SenseCell as its Tech name in that Context (F.3/F.7). Authors MUST record at least one counter‑example test showing how the twin could be misread and why it still passes in this Context (SenseCell notes).

CC‑TWIN‑3 - Head‑term discipline (HND). The plain twin MUST preserve the head term of the Tech name, or append an explicit bracketed head on first use:

• Roles keep “(role)”, Services keep “(service)”, Methods keep “(method)”, Work keeps “(work record)”, Capability keeps “(capability)”. Examples: TransformerRole → “Transformer (role)”, U.PromiseContent → “Service (service)”, U.Work → “work (work record)”.

CC‑TWIN‑4 - Kind‑consistent. A plain twin MUST NOT map across Kinds (C.3). If the twin’s everyday reading could denote a different Kind (e.g., Tradition = organization, corpus, domain), it is forbidden unless qualified by a bracketed head and Context gloss on first use (see CC‑TWIN‑7).

CC‑TWIN‑5 - Ambiguity stop‑list. The following base nouns are reserved and MUST NOT be used as unqualified plain twins: Tradition, service, process, function, model, system, method, standard, library, dataset, evidence, activity, task, action. They are allowed only with an explicit head per CC‑TWIN‑3 and a Context gloss (CC‑TWIN‑7). (This list MAY be extended in the registry.)

CC‑TWIN‑6 - No cross‑context by label. Plain twins are not portable. Reuse in another U.BoundedContext requires a Bridge with CL and loss notes; names alone carry no authority.

CC‑TWIN‑7 - First‑use gloss. At first occurrence in a document or screen, a plain twin MUST be shown as “Plain twin [Tech name] — Context gloss”, e.g.: “Transformer (role) [TransformerRole] — mask borne by a system to enact a method step in OR_2025”.

CC‑TWIN‑8 - Normative surface ban. Plain twins MUST NOT appear in Conformance Checklists, predicates, type signatures, or acceptance clauses. Only Tech names are normative. (Plain twins are strictly didactic.)

CC‑TWIN‑9 - Twin budget. At most one plain twin per Tech name per Context. Synonym piles are prohibited (control vocabulary sprawl; see F.14).

CC‑TWIN‑10 - Registry entry & DRR. Every plain twin MUST have a registry entry (in the LEX registry) recording: tech, plain, context, head, SenseFidelity = {3,2,1,0}, ambiguity notes, counter‑examples, DRR id. Any change requires a DRR.

CC‑TWIN‑11 - Tests. Twin entries MUST pass the Twin Harness (see F.15): Head term, Kind consistency, SenseCell match, Stop‑list compliance, and First‑use gloss.

#Minimal Generality & Domain Anchoring (MG-DA) — names neither parochial nor vacuous

Principle (MG-DA). A minted name is as general as necessary and no more, and its head noun is anchored to the object‑of‑talk. First classify the NameToken (name of a concept: term, lexical unit) itself using LEX.TokenClass, then apply the guardrails corresponding to that class: kernel tokens must unify across domains; discriminator/context tokens must make the domain legible from the name itself. Names too general to have obvious domain are banned.

#LEX.TokenClass (meta‑lexical; not a USM Scope)

Definition. LEX.TokenClass : NameToken → {KernelToken | ContextToken | DiscriminatorToken}.
This is a Characteristic on NameTokens (symbols), used by the LEX registry and MG-DA checks. It is not a USM scope and carries no truth/validity semantics.

#KernelToken — Minimal Generality (MG‑K)

MG‑K1 (Tri‑domain witness, MUST). Maintain a DRR/Glossary note with ≥ 3 heterogeneous arenas where the invariants hold (e.g., manufacturing, healthcare, cloud ops). If you cannot, narrow to a Context name or move qualifiers into RCS (Role Characterisation Space). MG‑K2 (No parochial nouns, MUST). Kernel names MUST NOT contain domain nouns (Ticket, Microservice, Patient, Developer). Such nouns belong in Context or as RCS Characteristics. MG‑K3 (No vacuity, MUST). Avoid vacuous heads (Thing, Event, Process, Resource). Use existing kernel heads (U.Holon, U.Work, U.Method, U.Resrc, …). MG‑K4 (Intent over mechanism, MUST). Kernel type/role names encode intent, not mechanism. Mechanisms (algorithms, hardware form, recipe flavors) live in RCS or Capability. MG‑K5 (Notation independence, SHOULD). The intensional meaning is separable from any one notation/toolchain. MG‑K6 (Refactoring safety, MUST). If a name fails MG, do not mutate it silently. Record a DRR and apply F.13 Lexical Continuity & Deprecation (aliases; Bridges for Cross‑context mappings).

#DiscriminatorToken / ContextToken — Domain Anchoring (DA‑D)

DA‑D1 (Object‑of‑talk anchoring, MUST). The head noun names the object being classified (e.g., Sense, Context, Role, Bridge, Characteristic). Readers can answer “X of what?” without external context. DA‑D2 (Characteristic, not axis, MUST). Enumerated properties are named as Characteristic within a CharacteristicSpace (MM‑CAL). Avoid spatial metaphors (axis, dimension, plane, lane, tier, layer) unless the metaphor is a pattern‑defined primitive in this spec. DA‑D3 (Enum clarity, MUST). If the term denotes an enumeration, (a) the value set is small and closed, (b) membership criteria are obvious from the definition, (c) the object‑of‑talk is explicit in the name (e.g., SenseFamily, not bare Family, RowPlane or overly general Facet). DA‑D4 (Anti‑recipe, MUST). Do not bake how‑to or local methods into discriminator names; those belong in U.Method/MethodDescription or Capability. DA‑D5 (Mapping discipline, MUST). Cross‑context readings go through a Bridge (F.9). Discriminator names must not suggest global identity. DA‑D6 (Register discipline, SHOULD). Keep normative tokens stable; synonyms live in Plain register only and must not appear in constraints/tests. DA‑D7 (Ban generic combinators, MUST). Reject vague composites like NameUseMode, NamingScope, RowFacet/RowPlane/RowLane. Each candidate must pass DA‑D1 and DA‑D3 (object‑anchored head and explicit CharacteristicSpace).

#Global tests (apply after 7.2/7.3)

MG-DA‑T1 (Three‑arena witness). If LEX.TokenClass(t)=KernelToken, you MUST provide the tri‑domain witnesses (7.2‑MG‑K1). Otherwise this is SHOULD (document at least one contrasting arena). MG-DA‑T2 (Object‑of‑talk). The head noun uniquely signals the subject area; avoid free‑floating metaphors. MG-DA‑T3 (Anti‑recipe). Remove mechanism/implementation words; relocate to Method/Capability/RCS. MG-DA‑T4 (Enum clarity). For enumerations, list the closed value set and its CharacteristicSpace. MG-DA‑T5 (Collision & Uniqueness, MUST). Before merge, run a full‑text search over the corpus and the Reserved‑Names registry. The candidate MUST NOT collide with any existing token used in another sense anywhere in FPF. If a collision exists, either rename or raise a DRR to deprecate the prior token. MG-DA‑T6 (Teaching swap). In didactic prose (E.10.D2), the term can be swapped in without caveats. MG-DA‑T7 (Intensional ground, MUST). The definition card states the intensional criterion for membership explicitly; reviewers can check membership without reading external narrative.

#Compatibility with USM (how tokens and scopes meet)

USM applies to acts, not tokens. Mint/rename/use are LexicalActs that carry a USM scope. LEX.TokenClass constrains where a token may be used via an AllowedScopes policy: Conformance rule. For any usage u of a token t: LEX.TokenClass(t)=c ⇒ USM.Scope(u) ∈ AllowedScopes(c).

The LEX registry defines AllowedScopes(c) (e.g., KernelToken usage in normative kernel constraints is allowed; in Plain register outside a glossary is restricted; Context emissions of KernelToken require a Bridge/alias, etc.).

Audit. Violations are flagged as SCR‑LEX‑Sxx (see acceptance tests below).

#Metaphor guidance (non‑binding heuristics)

Prefer object‑anchored heads to metaphors. If a metaphor is unavoidable, ensure it is (a) explicitly defined by a pattern here, and (b) unambiguous within the NameClass. Example families (use sparingly):

• Progression metaphors (level, tier, ladder): only where a gate/upgrade is defined by the pattern.
• Separation metaphors (lane, track): only where parallel, non‑interfering flows are enforced by rules.
• Grouping metaphors (family, class): only for small, closed enumerations attached to a clearly named object‑of‑talk (e.g., SenseFamily rather than bare Family).

#Short‑form and acronym discipline

SF‑1 (First expansion, MUST). On first use, expand the term; place the short‑form in parentheses (e.g., “Minimal Generality & Domain Anchoring (MG-DA)”).
SF‑2 (Uniqueness, MUST). Register short‑forms in the Reserved‑Names list; run the collision check (7.4‑MG-DA‑T5).
SF‑3 (Form, SHOULD). Prefer typographic separators (MG-DA) to fused acronyms (MGDA). Use the fused form only in code or identifiers where punctuation is disallowed, and only after registration.

#Examples (illustrative, canonical)

Prefer U.PromiseContent (promise) over BusinessService; U.Capability over Function; U.Dynamics over NaturalProcess; U.WorkPlan over ScheduleProcess.
Do not mint ETLService at kernel level—model ETL as MethodDescription; the Service is “data delivered under acceptance.”

#Acceptance & regression checks (LEX/USM)

SCR‑LEX‑S01 (TokenClass declaration). Every normative token has a declared LEX.TokenClass. SCR‑LEX‑S02 (Collision & uniqueness). Full‑text + Reserved‑Names check passes (no other meaning in FPF). SCR‑LEX‑S03 (Object‑of‑talk anchoring). Heads name the object classified (DA‑D1). SCR‑LEX‑S04 (CharacteristicSpace). Enumerations declare their value set and space (DA‑D2/3). SCR‑LEX‑S05 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass). SCR‑LEX‑S06 (Slot/Ref suffix discipline). Any token with suffix …Slot or …Ref is either (a) a SlotKind/RefKind declared under A.6.5, or (b) a episteme field whose type is a RefKind; no ValueKind or other type class may end with these suffixes. SCR‑LEX‑S07 (Manifest provides covers SlotKinds/RefKinds). If a SignatureManifest is present (A.6.0), its provides list MUST include any public SlotKinds (…Slot) and RefKinds (…Ref) introduced by that signature/mechanism (in addition to types/relations/operators), so SD/lexical linters can treat them as exported API surface. RSCR‑LEX‑E01 (Banned generics). Reject tokens matching the banned combinators list (DA‑D7). RSCR‑LEX‑E02 (Metaphor hygiene). If a metaphor is used, show the pattern that defines it; otherwise rename. RSCR‑LEX‑E03 (Strategy token minting). Reject new Kernel tokens named Strategy/Policy as kinds; model them as lenses/flows/compositions inside G.5 or as …Description/…Spec in Contexts. (Prevents kernel overloading; aligns with C.22 “no minted Strategy head”.)

#Morphology & Lexical Form (LEX.Morph)

Principle. Form follows object‑of‑talk. A token’s morphology (suffix/prefix/casing) must (a) express what kind of thing it names, (b) respect MG-DA (Minimal Generality & Domain Anchoring), and (c) pass LEX.TokenClass gates: LEX.TokenClass(token) ∈ {KernelToken | ContextToken | DiscriminatorToken}. Morphological choices never override I/D/S layers or CHR:ReferencePlane semantics.

#Casing & basic forms

M‑0 (Casing and categories). Types & role kinds: UpperCamelCase (IncisionOperatorRole, MethodDescription). Relations/verbs: lowerCamelCase (performedBy, isExecutionOf, bindsMethod). IDs/instances: flat with delimiters (context‑defined) but never collide with type forms (e.g., W#Seam134, ctx:Hospital.OR_2025). Register discipline: normative tokens use the Technical register; Plain synonyms are allowed in prose only, never in constraints.

#Reserved suffixes (gated by LEX.TokenClass and I/D/S)

Use tables as a whitelist. Rows indicate when a suffix is permitted and what it means. “Layer gate” prevents I/D/S confusion; “Examples” are illustrative.

Notes. • Kernel‑only ban list remains in § 8.3. • CHR guard: the only token that may use the word plane is CHR:ReferencePlane. • Axis/dimension metaphors are deprecated; use Characteristic / CharacteristicSpace where an enumeration is intended (see § 7).

Not only suffix guard

• Suffixes are strongly related to kinds and should be clearly guarded by MG-DA.
• Other morphemes (not only suffixes) also must respect kinds. For example, Space is a geometric concept — never use it as a suffix (…Space…) or other morpheme in beginning or in the middle of a term to name non‑geometric entities (e.g. prefer Set/Kid/Kit instead of Space where membership is intended).

**L‑SURF — disciplined use of Surface **

• Definition. Surface is reserved for publication/interoperability surfaces (UTS, shipping, interop) that present lawful, plane‑aware summaries for human/selector consumption. A Surface is a bundle of views (ISO 42010 sense) packaged for a stated audience and purpose, with declared viewpoint. Surfaces are conceptual (E.5.2); serialisations live in Annex/Interop. Surfaces package D/S projections produced via Describe_ID / Specify_DS (A.7) and do not change object ontology.
• Allowed: PublicationSurface, InteropSurface (G.10/G.13).
• Forbidden: StructureSurface, MechanismSurface, any …Surface that denotes a structural, mechanistic or measurement object.
• Preferred alternatives: use …Boundary (structural border), …View (publication view), or …Card (UTS record).

**L‑SPACE — disciplined use of Space **

• Use Space only for CHR‑grounded measurement/state constructs (e.g., CharacteristicSpace per A.19). Do not coin generic …Space for sets/portfolios or publication artefacts. Publish portfolios/archives as sets via lawful selectors; surface them on UTS as views/cards, not as spaces.
• Field‑name guard (Kernel blocks). In Kernel conceptual blocks (e.g., A.6.0/A.6.1 lists), do not name a field …Space; reserve Space to the types (CHR/ReferencePlane families). Use BaseType as the field name and let the referenced U.Type carry …Space where appropriate; otherwise, for set‑valued universes, use …Set.
• Space is geomertic concept, neve use it even not as a suffix for naming non-geometric spaces (e.g. instead of Sets with membership)

L‑ROLE — disciplined use of Role

• Role is always Role Enactment for the U.Holon/U.System kind (agentive use).
• Param‑slot / relation‑endpoint guard. Do not use the morpheme Role for formal parameter positions in operator algebra declarations (OperationAlgebra) or Signature arguments. Reserve Role for agentive kinds only (A.2/F.4/F.6). Prefer SlotKinds + SlotSpecs (A.6.5) to type formal slots; if a didactic list is useful, use a ValueKindView (name→ValueKind) projection derived from SlotSpecs/SlotIndex. Same for similar situations (table columns, tuple placements): use MG-DA with domain‑specific terminology, never “Role”.

#Forbidden suffixes & the DevOps, Data Governance and Repository-Workflow Lexical Firewall

M‑F (Forbidden in Kernel tokens). In KernelToken names, do not use: …Function, …Process, …Task, …Activity. These are ambiguous or vacuous—map using § 6 typing rules (often to Method, MethodDescription, or Work).

M‑FW (Tool/file markers). Tooling/file suffixes (…API, …JSON, …YAML, …CI, …Kafka, …Postgres) are not part of conceptual names. Place them in Context glossaries or operational configs (DevOps Lexical Firewall). Kernel names never carry tool/format/notation marks. It is pure conceptual, no data management and data governance intended.

#Prefix discipline

M‑P1 (Reserved prefixes). U. reserved for Kernel types; Γ_ for algebraic operators; CAL/LOG/CHR for pattern packages. Never mint U.* inside a Context.

M‑P2 (Edition markers). Apply explicit edition/version markers to Contexts and to MethodDescription / Service—not to Method (e.g., BPMN_2.0_BoundedContext, JS_Schedule_v4_MethodDescription, PassportIssuanceService_v2025). Authors MAY annotate Context or Service names for didactics. Norms (edition vs release vs version).

1. edition — the content phase of an episteme (Concept/Object/Symbol where Symbol‑only notation swaps do not force a phase). Lives in U.EditionSeries. Never embedded in labels (see R‑RD‑7); bind via data: …Ref.edition.
2. release — a Work of making a Carrier public; may carry tags/dates; does not change episteme identity or phase.
3. version — a tooling/carrier identifier (file/package/code). Use only in Tooling/Pedagogy families; not in Core names.

Property discipline. When a field pins a referenced artifact’s phase, write it as <Thing>Ref.edition (dot notation), never as a standalone …Edition key. E.g., replace DHCMethodEdition with DHCMethodRef.edition.

#Morphology tests (apply with § 7 MG-DA)

M‑1 (Slot test). The candidate fits one slot in the Strict Distinction lattice (Object ≠ Description ≠ Carrier; Role ≠ Method ≠ Work). If not, rename or split.

M‑2 (Object‑of‑talk anchoring). The head noun names the object being classified (Role/Method/Service/Work/Context/Characteristic). No free‑floating metaphors.

M‑3 (Family congruence). Where eligibility clarity is needed, add a Context‑specific characteristic (RCS) as a qualifier (e.g., NormativeStandardRole). Do not fake families with bare metaphors (no RowPlane, senseFamily, …Lane).

M‑4 (Run vs design). Use Work only for executions; use MethodDescription for recipes; never cross.

M‑5 (Kernel parochiality). KernelToken names carry no domain nouns; push domain markers to Context or RCS.

M‑6 (Vacuity ban). Avoid vacuous heads (Thing, Event, Process, Resource). Use established kernel heads (U.Holon, U.Work, U.Method, U.Resrc, …).

M‑7 (Notation independence). Intensional meaning survives notation/tool swaps.

M‑8 (Collision & uniqueness). Before merge, run full‑text + Reserved‑Names checks; the token must not collide with any other meaning anywhere in FPF (cf. § 7 MG-DA‑T5).

#Alias hygiene

Aliases live only inside a Context Glossary and map to one technical label with an equivalence note (≡). No global aliases.

#Compatibility with USM (acts vs tokens)

LEX applies to tokens; USM applies to acts. Mint/rename/use are LexicalActs that carry a USM scope (e.g., ClaimScope, WorkScope). LEX constrains where a token form may appear via AllowedScopes policies:

LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c).

Example: using a KernelToken in a Context constraint may require a Bridge/alias; logging Work inside a MethodDescription violates M‑4 and the policy.

#Acceptance & regression checks (LEX/USM)

• SCR‑MOR‑S01 (Suffix whitelist). Every normative token with a reserved suffix matches § 8.1 row semantics and passes Layer gates.
• SCR‑MOR‑S02 (Kernel bans). KernelToken names contain none of the forbidden suffixes (§ 8.2).
• SCR‑MOR‑S03 (Prefixes). Reserved prefixes obey § 8.3; no U.* minted in Context.
• SCR‑MOR‑S04 (Run/design gate). Work appears only for executions; MethodDescription has no runtime actuals.
• SCR‑MOR‑S05 (Collision). Full‑text + Reserved‑Names checks pass (no other sense of the token elsewhere).
• SCR‑MOR‑S06 (Object‑of‑talk). Heads pass M‑2; no bare metaphors as heads.
• RSCR‑MOR‑E01 (DevOps firewall). Tool/file suffixes quarantined to Context; none leak into KernelToken names.
• RSCR‑MOR‑E02 (USM compliance). For each LexicalAct, verify USM.Scope ∈ AllowedScopes(LEX.TokenClass) (see § 7.5).

#Autonomy lexicon (L‑AUTO )

Forbidden (Core): bare “validity”, “actor/agent” (as free‑standing nouns), “kill switch”, “process” for behavior, “envelope” when used as scope. Use instead: Scope (G) for epistemic scope; WorkScope for capability bounds; RoleAssignment for who acts; SpeechAct for overrides; SafeStop instead of “kill switch”. Named prefixes (policy & registry):

• aut: for AutonomyBudgetDecl fields (e.g., aut:action_tokens, aut:risk_bands);
• guard: for guard checks bound to AdmissibilityConditionsId;
• ovr: for override SpeechActs (ovr:PauseAutonomy, ovr:ResumeAutonomy, …).

Notes.

1. Scope‑sensitive guards must declare the Γ_time window selector used for admission checks.
2. Proper names of patterns/components that already include “Agent/Agency” (e.g., Agency‑CHR, Agent‑Tools‑CAL) are permitted as titled terms; avoid re‑introducing “agent” as a free‑standing noun in new prose.

#LEX-CHR-STRICT — Reserve Characteristic for CSLC-measurable aspects

Intent. Prevent calling non-measurable objects (sets, statuses, scopes, policies, bridges, contexts, guards) “characteristics”.

Rule L-CHR-S1 (Reservation). Use Characteristic only for variables that declare a CSLC scale (nominal/ordinal/interval/ratio) with admissible values/units/polarity (Part C.16/A.17–A.18).
Rule L-CHR-S2 (USM). U.Scope / U.ClaimScope (G) / U.WorkScope are USM scope objects, not Characteristics; they must not appear in any CharacteristicSpace.
Rule L-CHR-S3 (Status). ESG/RSG statuses and deontic/epistemic statuses — not Characteristics; its statuses/states.
Rule L-CHR-S4 (Lexical classifiers). Lexical classifiers/tags — Facets/attributes; do not name them as Characteristics, if not declared CSLC. Checks.
— CC-L-CHR-1. scope characteristic(s) is banned in Core/Context.
— CC-L-CHR-2. CharacteristicSpace near Scope — error.
— CC-L-CHR-3. Canonical rewrite: F–G–R characteristics → F–G–R components.

#LEX‑QA‑1 — Using “‑ility/‑ilities” terms (availability, reliability, …)

Rule. Tokens ending with ‑ility/‑ilities or widely used quality names (Availability, Reliability, Security, Safety, Scalability, Maintainability, Usability, …) are Quality‑Family labels, not automatically CHR Characteristics.

Authoring choice:
— To use such a term as a CHR characteristic (axis), bind it to a named U.Characteristic with one CSLC Scale (A.18) and refer to that Characteristic in guards/UTS;
— Otherwise publish a Q‑Bundle (see C.25) that includes Measures (CHR) (the measurable slots) and, where relevant, Scope (USM set over U.ContextSlice) and windows/mechanism/status fields.

Rationale. Scope is set‑valued (USM) and not a CHR measurement; mechanisms/statuses are governance artefacts. Keeping them outside the CHR CSLC avoids illegal scalarisation and preserves set‑algebra semantics for scope. (A.2.6 § 6.2; A.6.1; C.16/A.18).

#Canonical rewrites for overloaded words (LEX L‑rules; normative)

What this section does. LEX L‑rules standardise how we speak in Core/Context by mapping overloaded everyday words to canonical FPF concepts. What this section does not do. It does not restate naming (see § 7 MG-DA) or morphology/casing/suffix rules (see § 8 LEX.Morph); it depends on them. Guards. Tokens are classified by LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken} (§ 7.1). Only CHR:ReferencePlane may use the bare word plane; I/D/S are layers; enumerations are Characteristics in a CharacteristicSpace only when a CSLC scale is declared; otherwise treat such slots as non-measurable attributes (not Characteristics).

#Guarded-head cross-reference (normative lexical caution)

When one surface head already carries several load-bearing local readings, lexical cleanup should prefer a guarded-head note over silent flattening. The note may record that the head remains risky, name the lawful local owners, and point readers to the local canonical reading in each owner.

If cleanup reveals that no lawful existing token can carry the needed meaning, the editor must route the naming question through F.18 MintNew / DocumentLegacy rather than inventing an ad hoc synonym by feel.

This cross-reference is lexical only. It does not create a new repair owner, does not establish Cross-context equivalence, and does not overrule owner-local definitions. It simply keeps overloaded heads from being normalized into one false global reading.

projection is the main current example: A.16 keeps it as a move name for route-bounded partialization, while F.9.1 keeps it as a bridge stance label. E.10 therefore requires deconfliction notes and owner-explicit prose, not one umbrella rewrite that erases the distinction.

#Quick substitutions (common rewrite hints)

Use these as quick rewrite hints; accept only if the transformed sentence passes § 7 MG-DA and § 8 LEX.Morph gates.

#Acceptance tests (LEX‑AC)

A text passes LEX if all answers are Green:

1. Context named. Polysemous terms appear inside a named U.BoundedContext (or the page declares a local context card).
2. Right layer. I/D/S layer respected: types/roles on I; recipes/docs on D; actuals on runs (cf. § 8.1 gates).
3. Promise vs ability vs performance. PromiseContent (promise clause), Capability (ability), Work (performance) are not conflated.
4. No anthropomorphism. Documents/datasets/models do not “do”; Systems do.
5. Scheduling hygiene. No actuals on WorkPlan; all actuals live on Work.
6. Cross‑context reuse. Any reuse across Contexts cites a Bridge id with kind/dir/CL/Loss/scope (apply A.6.9 (RPR‑XCTX) when the surface prose uses “same/equivalent/align/map/…”).
7. MG-DA ok. New or refactored tokens pass § 7 MG-DA (anchored head noun; collision check; CharacteristicSpace for enums).
8. Morphology ok. Suffix/prefix/casing respect § 8 LEX.Morph (e.g., …Role, MethodDescription, Work, reserved prefixes).
9. Banned tokens absent. No process/function/task/activity in Kernel senses; no tooling/file suffixes in Kernel tokens.
10. State gating present (when needed). Readiness is expressed via RSG state + StateAssertion, not vague “approved/ready”.

#Coordination map (how LEX plugs into the rest of FPF)

• With E.10.D1 D.CTX (Context discipline). ULR–CTX‑1: Every Core meaning that can vary names its U.BoundedContext. ULR–CTX‑2: Same‑spelled labels are distinct senses across Contexts; reuse requires a Bridge (F.9) with CL & loss notes.

• With E.10.D2 (I/D/S discipline). Speak in the right I/D/S layer. ULR–IDS‑1..3 apply (types/roles = I; descriptions/specs = D/S; work/state assertions = evaluations/occurrences). Upgrades D→S only when checkable acceptance exists.

• With A.2 / A.15 (Role–Method–Work alignment). Role = assignment; Method = way‑of‑doing; MethodDescription = documented recipe; Work = dated occurrence. Sentences must keep this split.

• With F‑cluster (Unification) & UTS (F.17). Harvest in one Context → SenseCell → Concept‑Set row with relation (≡/⋈/⊂/⟂) and losses. UTS is the human‑readable roll‑up.

Acts vs tokens. LEX applies to tokens; USM applies to acts (mint/rename/use). Conformance: LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c) (see § 7.5).

#Conformance checklist (LEX‑CC)

1. LEX‑CC‑1 (Bans). Any banned token in Core/Arch fails unless the canonical appears (or the token is a registered Context alias).
2. LEX‑CC‑2 (Context). Each polysemous term names its U.BoundedContext.
3. LEX‑CC‑3 (Layer/Morph). Usage passes § 8 gates (suffix/prefix/casing) and I/D/S layer checks.
4. LEX‑CC‑4 (Bridge). Cross‑context reuse cites Bridge id and CL; same‑spelled labels without a Bridge are non‑conformant.
5. LEX‑CC‑5 (MG-DA). New tokens pass MG-DA tests, including full‑text collision and Reserved‑Names checks.
6. LEX‑CC‑6 (Service & evidence). Service acceptance computed from Work; evidence is an EvidenceRole on an Episteme with provenance.
7. LEX‑CC‑7 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass).
8. LEX‑CC‑8 (Minting discipline). If overload cleanup requires a new or replacement token, the text records lawful reuse or a full F.18 MintNew / DocumentLegacy procedure; intuition-first partial Name Cards are non-conformant.

#Worked micro‑examples (short, cross‑domain)

Factory. ✗ “The process failed; the service restarted itself.” ✓ PLC_17#ObserverRole:PipelineOps logged Observations; CAB_Chair#ApproverRole:ChangeControl performed a SpeechAct “approve restart”; OpsBot#DeployerRole:CD_Pipeline_v7 executed Work RestartRun‑4711 which claimsPromiseContent(CoolingUtility); post‑run Evaluation shows the Service acceptance passed.

Cloud. ✗ “The process owner approved; the API service deployed.” ✓ ProductLead#AuthorizerRole:Rollout_2025 performed a SpeechAct; sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7 performed Work Deploy‑F123; API = accessSpec : MethodDescription#REST_v12; promise content “Feature Access” declares acceptance; telemetry Work shows fulfilPromiseContent.

Research. ✗ “Dataset X proves the theory; the process is reproducible.” ✓ DatasetX#ModelFitEvidenceRole:Theory_Context supports claim C within scope S; reproducibility via StateAssertions on ReplicationEvidenceRole; procedures are U.MethodDescription; re‑runs are Work.

Semioarchitecture. ✗ “projection means the same thing in routing and bridge prose.” ✓ A.16 keeps projection as a move name for route-bounded partialization; F.9.1 keeps projection as a bridge stance label. If a new token is really needed, route the naming question through F.18 MintNew / DocumentLegacy rather than flattening both readings into one umbrella rewrite.

Editorial note. This section inherits § 7 MG-DA (anchored head nouns; Characteristic/CharacteristicSpace for enums; collision checks) and § 8 LEX.Morph (suffix/prefix/casing). It deliberately omits their details to avoid duplication. The only legitimate uses of plane in the Core are CHR:ReferencePlane and the derived operators CL^plane and Φ_plane; policy flags MUST NOT introduce new “planes”. To distinguish pre‑operational vs operational states within ReferencePlane=world, use WorldRegime ∈ {prep|live} (formerly PlaneRegime).

#Guarded-head cross-reference (normative lexical caution)

When one surface head already carries several load-bearing local readings, lexical cleanup should prefer a guarded-head note over silent flattening. The note may record that the head remains risky, name the lawful local owners, and point readers to the local canonical reading in each owner.

If cleanup reveals that no lawful existing token can carry the needed meaning, the editor must route the naming question through F.18 MintNew / DocumentLegacy rather than inventing an ad hoc synonym by feel.

This cross-reference is lexical only. It does not create a new repair owner, does not establish Cross-context equivalence, and does not overrule owner-local definitions. It simply keeps overloaded heads from being normalized into one false global reading.

projection is the main current example: A.16 keeps it as a move name for route-bounded partialization, while F.9.1 keeps it as a bridge stance label. E.10 therefore requires deconfliction notes and owner-explicit prose, not one umbrella rewrite that erases the distinction.

#Migration playbook — turning messy language into ULR‑clean prose (informative)

A pragmatic three‑pass routine. Works with plain text, diagrams, or models; no tools required.

#Pass 0 — Pre‑flight (2 minutes per page)

0.1 Name the Context card you’re writing in (title, edition, scope note). 0.2 For every new or renamed token, declare LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken}. 0.3 Run MG-DA pre‑check (anchored head noun; no metaphor heads; if enum → declare its CharacteristicSpace). 0.4 Run collision/uniqueness: full‑text grep + Reserved‑Names registry (see § 7). If collides → rename or DRR deprecate.

#Pass 1 — Harvest in the Context

1.1 Underline overloaded words (process, service, function, workflow, ticket, approval, spec, plan, …). 1.2 For each, write a one‑line intent in Plain register (what object‑of‑talk is meant). 1.3 Mark any cross‑Context reuse candidates.

#Pass 2 — Map to Core anchors (mechanical)

2.1 Replace underlined words via § 9 L‑rules table:  • recipe → U.Method / U.MethodDescription  • scheduled run → U.Work / U.WorkPlan  • promise → U.PromiseContent  • ability → U.Capability  • actor‑mask → …Role / RoleAssignment  • document/evidence carrier → Episteme with EvidenceRole/RequirementRole 2.2 Apply LEX.Morph (§ 8): suffix gates (…Role/…Work/MethodDescription/Service), casing, reserved prefixes. 2.3 Pass I/D/S layer check: types/roles on I; recipes/docs on D; actuals on runs. 2.4 Attach Context tags on first use; set twin labels (Tech/Plain) in the local Glossary.

#Pass 3 — Stitch & publish

3.1 Add safe rewrites for any anti‑patterns you found (use § 9.2 quick table). 3.2 If sameness is needed across Contexts, create a Bridge (F.9) with explicit kind/dir/CL/Loss/scope (apply A.6.9 (RPR‑XCTX) when the source text uses umbrella “same/equivalent/align/map/…” language). 3.3 Publish a one‑page UTS (F.17) for the Context (columns: Context, Tech label, Plain label, Kernel anchor, Warnings). 3.4 Log a short DRR when renames/aliases occur (F.13), linking to grep results that motivated the change.

#ULR conformance prompts (normative, concept-only questions)

Use these prompts during review. They reference § 7 (MG-DA) and § 8 (LEX.Morph) instead of repeating them.

1. Context prompt. Does each potentially polysemous noun live inside a named U.BoundedContext?
2. Layer prompt. Is each sentence in the correct I/D/S layer (I: type/role; D: description/spec; run: actuals)?
3. Token prompt. For new/renamed tokens, is LEX.TokenClass declared and consistent with where the token appears?
4. Head-kind prompt. Does the head noun name what kind of thing the phrase is actually about (Role/Method/Service/Work/Context/Characteristic/publication artifact/reading/process/authority use)? A narrowing qualifier alone does not answer this question.
5. Qualifier-burden prompt. If an adjective, participle, genitive, or comparative modifier is doing semantic work, has that burden been restored explicitly rather than left inside the modifier alone?
6. Comparison-axis prompt. If the sentence compares, ranks, escalates, or downgrades something, is the comparison axis ontologically homogeneous after head-kind and qualifier restoration?
7. Morphology prompt. Do suffix/prefix/casing pass LEX.Morph gates (e.g., …Role, MethodDescription, Work)?
8. Promise vs ability vs performance. Are Service (promise), Capability (ability), and Work (performance) distinct?
9. Plan vs execution. Are WorkPlan windows separated from Work actuals?
10. Evidence prompt. Do documents hold roles and justify, while systems act?
11. Bridge prompt. If sameness spans Contexts, is there an explicit Bridge with CL and loss notes?
12. Collision prompt. Did we run full-text + Reserved-Names checks (no other meaning of this token anywhere in FPF)?
13. Naming-procedure prompt. If no lawful existing token carried the needed meaning, did we run the full F.18 MintNew / DocumentLegacy procedure rather than picking a label by intuition and filling a partial Name Card afterward?

Working order for precision repair on load-bearing prose. Restore the head kind first; a narrowing qualifier such as comparative, safe, interactive, or reliable does not by itself restore that kind. Then unpack qualifier burden, then check whether the comparison or escalation axis is homogeneous. Only after that may a later Plain, didactic, or coarsened rendering lawfully relax the sentence, and even then the more precise upstream reading must remain recoverable.

#ULR regression cues (concept-only “diff” triggers)

Re-review your prose when any of these happen:

• Context edition changes → re-affirm twin labels, Bridges, and acceptance wording.
• A role/type name grows (“and/plus/--”) → apply MG-DA: split or bundle (A.2).
• A “service” statement broadens scope → check that acceptance terms cover the new target; else split the Service.
• Recipes gain/lose steps → update MethodDescription, not Service or Role names.
• Evidence verbs creep into actor sentences → re-apply L-rules (documents do not act).
• A generic head acquires a strong qualifier (comparative, safe, interactive, reliable, and similar burden-carrying modifiers) → restore the head kind first, then unpack the qualifier burden before stronger publication.
• New token minted → ensure LEX.TokenClass declared; run collision checks; add CharacteristicSpace if enum.
• Suffix drift (e.g., …Work on a plan) → fix via LEX.Morph.
• Cross-Context reuse by label appears → require a Bridge (F.9) or split senses.
• A guarded head needs a new label → prefer a guarded-head note first; if no lawful existing token remains, route the naming question through full F.18 MintNew / DocumentLegacy.

#Teaching deck — the ULR quick card (reusable in any Context)

Say it cleanly, once (memorise): Role = assignment (mask) - Method = way‑of‑doing - MethodDescription = recipe (document) - Work = run (dated) Capability = can‑do within bounds (envelope + measures) - Service = promise (access + acceptance) I/D/S are layers; documents don’t act; Contexts own meanings; Bridges move meanings.

Name forms (allowed morphology): • Types/roles: <Noun><Role/Type> (IncidentCommanderRole, NormativeStandardRole, WorkItemType). • Statuses: <Noun>Status inside the Context’s role space (ApprovedStatus) — status‑only; not enactable. • No suitcase nouns: avoid “and/plus/&” in names; use bundles (A.2) or separate roles. • Acronyms: first expansion + register; short‑form registered per § 7.7.

#Three worked micro‑examples — ULR across domains (informative)

#Healthcare (OR context)

Messy: “The surgical process is scheduled at 08:00; the SOP approves the incision and the service documents recovery.” ULR rewrite: “WorkPlan OR‑Case‑221 starts 08:00 and will execute MethodDescription Incision_v4. SOP_OR_v4 holds RequirementRole; a SpeechAct Work by QA_Officer#ApproverRole authorises the run. The hospital offers Service ‘Post‑op monitoring’ (access = ward protocol; acceptance = vitals envelope).”

#Manufacturing (assembly line)

Messy: “The welding function provides air‑tight seams; the process costs 3 min.” ULR rewrite: “Robot_SN789 has Capability ‘execute Weld_MIG_v3 within envelope E at measures M’. Work instances that fulfil Service ‘Provide seam S’ average 3 min; acceptance bounds are in Seal_Acceptance.md. The MethodDescription is Weld_MIG_v3; the Role is WelderRole.”

#Cloud/SRE (production Context)

Messy: “The storage service wrote logs and the deployment process failed after 2 min.” ULR rewrite: “sCG‑Spec_ci_bot#DeployerRole:CD_v7 performed Work ‘Deploy r4711’ (failed at T+120 s). The platform offers Service ‘Object Storage’ (access = S3_API_Spec_vX; acceptance = durability/availability targets). LogWriter is a System bearing TransformerRole that wrote the records; the service did not act.”

#Closing notes (governance & purity)

• Notation‑agnostic. ULR is a language constitution, not a scanner or template. Apply it in prose, sketches, or formal models.
• Where checks live. Convenience checks belong to Tooling; ULR itself stays notation‑agnostic. Conformance code lives in SCR‑LEX / RSCR‑LEX as referenced above.
• Acts vs tokens. LEX applies to tokens; USM applies to acts (mint/rename/use). Conformance: LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c) (§ 7.5).
• Guards honoured. DevOps Lexical Firewall and Unidirectional Dependency remain intact.
• Reserved “plane”. Only CHR:ReferencePlane uses the bare word plane; I/D/S are layers; all other category talk is expressed as Characteristics in a CharacteristicSpace.

One‑line memory: “ULR keeps words honest so ideas stay composable.”

#E.10:End

#Conceptual Prefixes policy & registry

Intent. Provide a compact, notation‑neutral registry and minting policy for conceptual prefixes — short shorthands that signal cognitive namespaces used throughout the Core.

Policy (normative).

1. Purpose. A conceptual prefix exists to aid reasoning, not to name files, serialisations, or APIs. It labels a role in thought (e.g., meta‑type, calculus operator, relation family).
2. Anchoring. Every prefix MUST be anchored to a Core extension patterns (CAL/LOG/CHR) or Kernel construct and documented in its Relations.
3. No tool lock‑in. A prefix MUST NOT imply a particular notation or machine binding (see E.5.1–E.5.2).
4. Minting rule. New prefixes are introduced by a DRR (E.9) that demonstrates (a) cross‑pattern need, (b) non‑overlap with existing prefixes, (c) alignment with Pillars P‑1/P‑5.
5. Scope. Prefixes are globally reserved within the Core; domain patterns MAY mint local shorthands only inside their Contexts and MUST NOT collide with this registry.

Registered conceptual prefixes (Core).

• U. — U.Types meta‑namespace (holons & primitives). Anchor: Kernel Part A.
• Γ_ — Calculus operator family (by flavour: Γ_sys, Γ_epist, …). Anchor: Part B umbrella on Γ.
• ut: — Universal relation family (e.g., PartOf sub‑relations). Anchor: A.14 (Mereology) — informative alias vocabulary.
• tv: — Trace & Validation vocabulary (CT2R‑LOG): tv:AliasOf, tv:groundedBy. Anchor: B.3 (Trust & Assurance, LOG‑use).
• ev: — Evidence hooks (bindings/roles). Anchor: A.10 / B.3 (Evidence Graph Referring).
• mero: — Mereology trace types (internal labels: SumTrace / SetTrace / SliceTrace) used informatively in examples. Anchor: B.1 (Γ‑aggregation).

Conformance Checklist (E.10.P).

• CC‑LEX‑P.1 New Core text SHALL NOT introduce an unregistered conceptual prefix.
• CC‑LEX‑P.2 Each occurrence of a registered prefix SHALL cite its anchor pattern on first use in a section.
• CC‑LEX‑P.3 Examples that expand a prefix into a concrete URI or syntax MUST mark the expansion informative and locate it in Tooling/Pedagogy.

Relations. Constrains E.5.1 (Lexical Firewall) & E.5.2 (Notational Independence); Depends on E.9 (DRR).

#E.10.P:End

#Lexical Discipline for “Context” (D.CTX)

One‑sentence summary. Make the word Context unambiguous: in FPF it only denotes the formal primitive U.BoundedContext; remove the term anchor; reserve Problem Frame for situational narrative; treat Domain as an informative family label, not a type.

Status. Discipline definitional pattern. Depends on. C‑6 Strict Distinction; C‑7 Temporal Duality; G‑1 Minimal Generality; G‑2 Contextual Specification. Coordinates with. E.10.U1 Domain‑Family Landscape Survey; E.10.U2 Term Harvesting & Normalisation; E.10.U7 Concept‑Set Table; E.10.U9 Alignment/Bridge; RoleAssigning patterns (e.g., E.10.U4). Aliases (informative). Context Discipline; No‑Anchor Rule.

#Intent & Applicability

Intent. Eliminate ambiguity around “context” by (a) fixing one formal meaning—U.BoundedContext; (b) removing “anchor” from the vocabulary; (c) reserving Problem Frame for prose about situations; and (d) clarifying Domain as an informative family (workflow, provenance, services, …) that groups several U.BoundedContexts.

Applicability. Mandatory across all FPF patterns (Role Assignment & Enactment, Sys-CAL, KD-CAL, Kind-CAL, planned LCA-CAL). Apply at the start of any unification effort and whenever documentation introduces or refactors “context”, “domain”, “anchor”.

Non‑goals. No governance, workflow, or tool mandates; no storage formats; no team roles.

#Problem Frame

1. Polysemy. “Context” is used for formal scopes, narrative situations, and even runtime modes.
2. Extra token (“anchor”). “Anchor” pretends to be “where meaning is attached”, duplicating context semantics.
3. Domain overreach. “Domain context” conflates families (disciplinary areas) with formal contexts.
4. Plane mixing. Runtime/design stances and deontic/behavioural notions are smuggled into “context”.

#Forces

#Solution — Name one thing “Context” can mean

D‑CTX‑1 (Canonical meaning). In all FPF materials, Context denotes the formal primitive U.BoundedContext only. The short form Context is permitted in the Tech register strictly as an alias of U.BoundedContext.

D‑CTX‑2 (Remove “anchor”). The term anchor is prohibited. When you need “the place where a meaning lives”, use:

• SenseCell := (U.BoundedContext, Local‑Sense) — the cell of meaning inside a specific Context; or
• a ConceptSet.Row + column reference (see E.10.U7).

D‑CTX‑3 (Domain is informative). Domain (workflow, provenance, services, access, sensing, …) is not a U.Type. It is an informative family label grouping several U.BoundedContexts. There is no “domain context”.

D‑CTX‑4 (Narrative is Problem Frame). Use Problem Frame (or Frame) for situational narrative in patterns. Do not use “context” for narrative sections.

D‑CTX‑5 (Time is a tag, not a context). design / run are TimeScope tags (C‑7) on artefacts or sources; they do not create separate contexts.

D‑CTX‑6 (No context inheritance). U.BoundedContexts have no is‑a or containment relations. Any cross‑context relationship appears only via E.10.U9 Alignment/Bridge with explicit loss policies.

D‑CTX‑7 (Language/edition discipline). Different languages or editions may be distinct U.BoundedContexts when meaning or usage can diverge. Where an official source binds multilingual labels to the same semantics, record them as labels of the same Context.

D‑CTX‑8 (Reference forms). Use one of the following when pointing to meaning:

• ContextId:LocalLabel (e.g., BPMN_2_0:process), or
• SenseCell(ContextId, Local‑SenseId), or
• ConceptSet(RowId).Column(ContextId) (E.10.U7).

#Structure — Minimal reference shapes (informative)

Shapes shown do not prescribe formats; they are naming conventions.

• Context Id. Stable short handle (e.g., BPMN_2_0, PROV_O_2013, ITIL4_2020, NIST_RBAC_2004, SOSA_SSN_2017).
• SenseCell. (ContextId, Local‑Sense) where Local‑Sense is the Context‑local preferred label (from E.10.U2).
• ConceptSet Row. A table row keyed by a row id; columns are SenseCells per Context (E.10.U7).

#Core Invariants (normative)

1. LCTX‑INV‑1 (Uni‑meaning). The word Context in formal text equals U.BoundedContext.
2. LCTX‑INV‑2 (No anchor). The token anchor does not appear in normative prose; use SenseCell or ConceptSet reference.
3. LCTX‑INV‑3 (No domain contexts). “Domain context” is invalid; use Domain family + list of U.BoundedContexts.
4. LCTX‑INV‑4 (Frames, not contexts). Pattern headers use Problem Frame for narrative.
5. LCTX‑INV‑5 (No hierarchy). Contexts are flat; relationships are declared only via E.10.U9 Bridges.
6. LCTX‑INV‑6 (Plane hygiene). Contexts describe context of meaning for sources; they are not roles, statuses, executions, or types (C‑6).
7. LCTX‑INV‑7 (Time tags). DesignRunTag is a tag on artefacts/sources; it does not multiply contexts.
8. LCTX‑INV‑8 (Language/edition). Multilingual or multi‑edition handling follows D‑CTX‑7.

#Conformance Checklist (normative)

• CC‑LCTX‑1. Grep‑style check: every “Context” in formal sections expands to U.BoundedContext.
• CC‑LCTX‑2. The token anchor is absent from normative text; where needed, occurrences are replaced by SenseCell or ConceptSet reference.
• CC‑LCTX‑3. Pattern headers use Problem Frame; none use “Context” for narrative.
• CC‑LCTX‑4. References to meaning are in one of the reference forms (Sec. 5).
• CC‑LCTX‑5. No file defines “domain context”; Domain appears only as an informative family.
• CC‑LCTX‑6. No is‑a edges between contexts; any cross‑context relation is located in E.10.U9.
• CC‑LCTX‑7. Language/edition handling matches D‑CTX‑7 (separate Contexts when semantics can diverge).

#Anti‑patterns & Remedies

#Worked Examples

#E.10.D1:9.1 Enactment — process vs activity (two context of meaning).

• Use BPMN_2_0:process and PROV_O_2013:activity as SenseCells.
• In a Concept‑Set row, code the provisional relation ⋈ (overlap), not an equality.
• Role Descriptions later reference the specific SenseCell, not “an anchor”.

#E.10.D1:9.2 Roles — behavioural mask vs access status.

• BPMN_2_0:participant vs NIST_RBAC_2004:role.
• Mark ⟂ (incompatible) in the Concept‑Set row to prevent conflation.
• Any cross‑use requires E.10.U9 with explicit loss policy.

#E.10.D1:9.3 Services & evidence.

• ITIL4_2020:service / ITIL4_2020:service‑level‑objective with KD‑CAL cells SOSA_SSN_2017:observation.
• References in acceptance patterns point to SenseCells; provenance stays within the PROV Context.

#Reasoning Primitives (conceptual judgements; notation‑agnostic)

Pure thinking moves; no APIs, no storage, no governance.

• (J1) Context expansion. ⊢ Context ≡ U.BoundedContext Reading: wherever “Context” appears in formal prose, it denotes U.BoundedContext.

• (J2) Anchor ban. uses("anchor") ⊢ violation(D‑CTX‑2) Reading: usage of “anchor” flags a discipline violation.

• (J3) Sense reference. ref(ContextId, LocalLabel) ⊢ SenseCell(ContextId, Local‑Sense) Reading: a well‑formed reference identifies a SenseCell.

• (J4) Narrative frame. header("Context") ⊢ replaceWith("Problem Frame") Reading: headings “Context” in patterns must become “Problem Frame”.

• (J5) Domain family. label ∈ {workflow,…} ⊢ DomainFamily(label) Reading: Domain labels are families, not contexts.

• (J6) Time tag. stance ∈ {design, run} ⊢ TimeScopeTag(stance) Reading: time is a tag, not a new context.

#Relations (with other patterns)

Builds on: C‑6, C‑7, G‑1, G‑2. Constrains:

• E.10.U1 — lists only U.BoundedContexts; no “domain contexts”; context records never encode pattern semantics.
• E.10.U2 — Seeds and Occurrences are always Context‑anchored; references use forms from Sec. 5.
• E.10.U7 — Columns are SenseCells; row notes never call them “anchors”.
• E.10.U9 — All cross‑context relations live here; no implicit equivalences elsewhere.
• RoleAssigning patterns (E.10.U4, …) — Context points to SenseCell or Concept‑Set columns, never to “anchors”.

#Migration Notes (conceptual playbook)

1. Rename headings. Replace any “Context” section title with Problem Frame.
2. Delete “anchor”. Replace with SenseCell or Concept‑Set references.
3. Split domain vs context. Where “domain context” appears, rewrite as Domain family + explicit list of U.BoundedContexts.
4. Audit references. Ensure every semantic reference is ContextId:LocalLabel or SenseCell(ContextId, …) or Concept‑Set column.
5. Flatten contexts. Remove any inheritance among contexts; move relations to E.10.U9.
6. Tag time. Replace “design/runtime context” with TimeScope tags.
7. Language/edition pass. Split or merge Contexts per D‑CTX‑7; document rationale.

#Acceptance Tests (SCR/RSCR stubs)

SCR — Static discipline checks

• SCR‑DCTX‑S01. No occurrence of the token anchor in normative sections.
• SCR‑DCTX‑S02. All formal uses of “Context” resolve to U.BoundedContext.
• SCR‑DCTX‑S03. Pattern headers contain Problem Frame instead of “Context”.
• SCR‑DCTX‑S04. All semantic references use the forms in Sec. 5.
• SCR‑DCTX‑S05. No “domain context” strings; Domain appears only as family metadata.
• SCR‑DCTX‑S06. No is‑a or containment relations between contexts outside E.10.U9.

RSCR — Regression discipline checks

• RSCR‑DCTX‑E01. Adding a new family or edition does not introduce “domain context” or context hierarchies.
• RSCR‑DCTX‑E02. Refactors of E.10.U1/U.2/U.7/U.9 do not re‑introduce “anchor”.
• RSCR‑DCTX‑E03. Multilingual updates follow D‑CTX‑7 (split/merge rationale recorded informatively).

#E.10.D1:End

#Intension–Description–Specification Discipline (I/D/S)

Definitional pattern — normative, notation‑agnostic

One‑sentence summary. For every intensional FPF object (e.g., U.Role, U.Method, U.System, U.Work, U.PromiseContent), clearly distinguish the thing itself (Intension), its context‑bound Description (KU), and its formal Specification (KU). Use –Spec only when strict, testable invariants and an acceptance harness exist; otherwise use –Description. This keeps semantics clean, didactic, and testable across all FPF patterns.

Status. Definitional pattern. Builds on: A.7 Strict Distinction (Clarity Lattice); E.10.D1 D.CTX (Context ≡ U.BoundedContext); C.2.1 U.EpistemeSlotGraph (DescriptionContext, IDS‑13); C.2.3 Unified Formality Characteristic (F). Coordinates with. F.4 Role Description; F.5 Naming Discipline; F.10 Evaluation; F.15 SCR/RSCR Harness. Non‑goals. No editors, workflows, registries, or storage formats. No tooling commitments.

#Problem frame

Intent. Prevent perennial confusions such as “the role contains the checklist” or “the method is the document.” Establish a universal discipline so that:

• Intensions (e.g., U.Role, U.Method) remain I/D/S layer‑pure and context‑agnostic entities in the kernel.
• Descriptions (KUs) capture human‑readable, Context‑local semantics (labels, glosses, characterisations, state graphs, checklists).
• Specifications (KUs) exist only when there are verifiable invariants, an acceptance harness, and a declared Formality F adequate for checkability (C.2.3; default F ≥ F4), making claims testable.

Applicability. Whenever an FPF text introduces or uses an intensional U.Type (e.g., U.Role, U.Method, U.PromiseContent, U.System, U.Work, U.RCS, U.RSG, U.RoleEnactment) in any part (A–H).

#Problem

1. Plane/layer mixing. Intensions are routinely conflated with their documents and with runtime facts.
2. Name drift. “Spec” gets used for any write‑up; “status” drifts between states of a role and epistemic/deontic statuses over knowledge units.
3. Didactic friction. Inconsistent naming raises cognitive load and impedes reuse across FPF patterns.
4. Unverifiable claims. Without a clear gate to –Spec, normative wording appears without testability.

#Forces

#Solution — the I/D/S layer + a formal Spec‑gate

#E.10.D2:4.1 The triad (applies to any intensional U.T)

Terminology discipline (normative). Say I/D/S layers when you mean the stratified order with a Spec‑gate; say I/D/S triad only to note three‑ness without order or dependency. Do not call I/D/S a “plane”. Reserve plane for uses explicitly defined elsewhere (e.g., CHR:ReferencePlane and status families). Layer semantics (clarity). I‑layer = kernel/intensional type (non‑epistemic; not a episteme) . D‑layer and S‑layer = epistemic Knowledge Units (KUs). The Spec‑gate upgrades a Description to a Specification only under declared checkability and harness conditions (unchanged).

For every intensional type U.T:

• Intension — U.T. The thing itself (e.g., U.Role, U.Method, U.PromiseContent, U.System, U.Work, U.RCS, U.RSG). It does not contain documents, checklists, or carriers; it is not a runtime event or a file.

• Description episteme — U.TDescription(@Context) A Context‑local knowledge unit that characterises U.T with labels (Tech/Plain), glosses, and, when applicable, Role Characterisation Space (U.RCS), Role State Graph (U.RSG), and state conformance checklists. Readable, precise, didactic; may reference evaluation criteria but does not assert testable “shall”s by itself.

• Specification episteme — U.TSpec(@Context) A Context‑local knowledge unit that states testable invariants for U.T and is bound to an acceptance harness. Normative, verifiable, suitable for SCR/RSCR (F.15).

Key phrasing discipline. Intensions are characterised by (not “contain”) RCS/RSG/checklists, which live in the Description/Spec. Terminology guard. To avoid collisions with ReferencePlane and other semantic planes, the I/D/S triad is referred to as I/D/S Layers (Intension Layer - Description Layer - Specification Layer). The word plane is reserved for semantic planes (Role/Status/Measurement/Type‑structure/Method/Work, etc.) and for the ReferencePlane field used in describedEntity/assurance.

#E.10.D2:4.2 The Spec‑gate (when “–Spec” is allowed)

Use the –Spec suffix only if all of the following hold:

1. Formality F (C.2.3): the artefact declares F ≥ F4 (or a context-defined higher threshold) so predicates are checkable.
2. Verifiability: invariants are stated as checkable predicates or thresholds.
3. Harness bound: there is a linked acceptance harness (SCR/RSCR matrices per F.15).
4. Context anchoring: all wording is explicitly local to a named U.BoundedContext (E.10.D1).

If any condition is missing, the artefact must be a …Description.

#E.10.D2:4.3 Where RCS/RSG and evaluations sit

• U.RCS (Role Characterisation Space) and U.RSG (Role State Graph) are intensional types that structure the space of role characteristics and permissible state transitions.
• Their human presentation (characteristics, dimensions, node labels, admissible transitions) lives in the RoleDescription, and becomes part of RoleSpec only when the transitions and state predicates are made testable and harness‑bound.
• U.Evaluation operates on evidence against the conformance checklist (from the Description/Spec) to produce a state attestation (“X is in state S @Context within window W”).
• Epistemic/deontic statuses (e.g., Evidence, Requirement, Standard) are roles over Epistemes (not states of the role). They are governed elsewhere (F‑R family) and must not be conflated with U.RSG state names.

#E.10.D2:4.4 Plain‑language memory hook

Thing vs words vs rules. The thing (U.Role, U.Method) is clean and abstract. The words (labels, glosses, RCS/RSG pictures, checklists) live in the Description. The rules (testable “shall”s with harness) live in the Specification. If you can’t test it, don’t call it Spec.

#Minimal vocabulary & naming discipline (this pattern only)

Core trio (per intensional U.T).

• U.T — the Intension. Kernel object (e.g., U.Role, U.Method, U.PromiseContent, U.System, U.Work, U.RCS, U.RSG). Never a document, never an event, never a file.

• U.TDescription(@Context) — the Description Episteme. Context‑local characterisation of U.T: Tech/Plain labels, gloss, notes; for roles, may characterise with an U.RCS (characteristics/traits), an U.RSG (states/transitions), and state conformance checklists (per state). Readable; precise; not yet a set of testable “shall”s.

• U.TSpec(@Context) — the Specification Episteme. Context‑local, testable invariant set for U.T, explicitly bound to an acceptance harness (SCR/RSCR matrices per F.15). Use –Spec only through the Spec‑gate (Sec. 4.2).

Suffix rules.

• Use …Description by default (M‑mode or F‑mode without harness).
• Use …Spec only when all Spec‑gate conditions (Sec. 4.2) hold.
• No alternative suffixes (“Profile”, “Definition”, “Guide”) inside the Core; such epistemes live in pedagogy/tooling layers, not in the I/D/S discipline.

Naming morphology (recap of F.5 as it applies here).

• Two registers: Tech and Plain labels on every Description/Spec.
• Roles use count nouns (e.g., Operator); states use state nouns (e.g., Approved).
• Statuses over knowledge (e.g., Evidence/Requirement) are not role states; they name roles over Epistemes (F‑R family), not nodes in U.RSG.

Context anchoring. Every Description/Spec is local to a U.BoundedContext (E.10.D1). Phrases in the episteme must read correctly once prefixed by the Context name (e.g., “(ITIL4) Acceptance criteria …”).

Carriers. U.Carrier holds encodings of a Description/Spec; the Episteme’s identity is not the file. Never say “the role contains the checklist in the PDF”; say “the RoleDescription characterises the role with checklists; this carrier encodes them.”

Time stance. Descriptions/Specs must declare DesignRunTag when inherent (e.g., RoleDescription is design‑time; state attestation via U.Evaluation is run‑time).

#Invariants (normative)

IDS‑1 (Plane purity). An intensional U.T MUST NOT be conflated with its Description/Spec or with any U.Carrier or U.Work.

IDS‑2 (Context locality). Every …Description/…Spec MUST name a U.BoundedContext. Wording inside is read as‑local; no global meaning is implied.

IDS-3 (Spec-gate). A episteme MUST NOT use the –Spec suffix unless: (a) the artefact declares U.Formality = Fk with k ≥ 4 per C.2.3, (b) invariants are testable predicates, (c) an acceptance harness is linked (F.15), (d) Context is explicit.

IDS‑4 (Characterisation verbs). Texts MUST say: “U.Role is characterised by U.RCS/U.RSG in the RoleDescription”. They MUST NOT say: “the role contains the RCS/RSG”.

IDS‑5 (RCS/RSG scope). U.RCS/U.RSG are intensional structures. Their presentations (characteristics, state names, admissible transitions, checklists) live in the RoleDescription, and in RoleSpec only when transitions and state predicates are fully testable.

IDS‑6 (Evaluation semantics). U.Evaluation MUST operate over evidence against conformance checklists from the Description/Spec and MUST produce a state attestation (who/what is in state S @Context within window W). Evaluation does not mutate the intensional object.

IDS‑7 (Status separation). Epistemic/deontic statuses (Evidence/Requirement/Standard) are roles over knowledge units; they MUST NOT be used as state names in U.RSG.

IDS‑8 (Register discipline). Every Description/Spec SHOULD include both Tech and Plain labels. Symbolic aliases are optional and informative.

IDS‑9 (No stealth bridges). Descriptions/Specs MUST NOT import meanings from other Contexts by shared labels. Cross‑context relations exist only as F.9 Bridges.

IDS‑10 (Window honesty). When an evaluation is time‑bounded, the window MUST be stated in the attestation.

IDS‑11 (Ladder clarity). A Description may mature into a Spec by satisfying IDS‑3; the opposite move requires a rationale (loss of testability) and must drop the –Spec suffix.

IDS‑12 (Didactic bound). A RoleDescription SHOULD fit on one screen per state graph plus one screen of notes; sprawling documents belong to pedagogy, not to the core Description.

#Reasoning primitives (judgement schemas, notation‑free)

Judgements are mental moves—they assert what follows when premises hold. They do not imply queries, storage, or workflows.

1. Description link (with DescriptionContext)

   U.T, C, Vp ⊢ isDescriptionOf(TDesc, U.T, C, Vp)

   Reading: TDesc is the Context‑local Description of U.T in Context C under Viewpoint Vp. Its subjectRef decodes to DescriptionContext = ⟨DescribedEntityRef(U.T), C, Vp⟩ (IDS‑13, C.2.1 §6.1).

2. Spec link (Spec‑gate, viewpoint‑local)

   isDescriptionOf(TDesc, U.T, C, Vp) ∧ U.Formality(TSpec) ≥ F4
      ∧ testableInvariants(TSpec) ∧ harnessBound(TSpec)
      ∧ sameDescriptionContext(TSpec, TDesc)
      ⊢ isSpecOf(TSpec, U.T, C, Vp)

   Reading: Only when F‑mode, testability, harness, and a matching DescriptionContext are present may we judge TSpec a Specification of U.T in C under Viewpoint Vp.

3. Role characterisation

 isDescriptionOf(RoleDesc, U.Role, C, Vp)
 ∧ characterises(RoleDesc, U.RCS) ∧ characterises(RoleDesc, U.RSG)
 ⊢ characterisedBy(U.Role, {U.RCS, U.RSG}) @C

Reading: The role is characterised by the RCS/RSG as presented in the Description (which is pinned to (C, Vp)), not that it “contains” them.

4. State conformance predicate

   checklistFor(RoleDesc, state S) = χ
   ∧ evidence E within window W
   ⊢ conformsToState(E, χ, W) ⇒ attestation(subject ∈ S @C, W)

   Reading: Evidence satisfies the checklist for state S, yielding a state attestation.

5. Transition admissibility

   U.RSG allows (S → S') @C
   ∧ attestation(subject ∈ S @C, W)
   ∧ conformsToState(E', checklistFor(S'), W')
   ⊢ admissibleTransition(subject : S → S' @C)

   Reading: A move from S to S' is admissible when RSG permits it and S' is satisfied.

6. Status / state separation guard

   statusOverKU(KU, σ) ∧ stateInRSG(ρ)
   ⊢ σ ≠ ρ  (distinct planes)

   Reading: A status over a knowledge unit is not a role‑state.

7. No Cross‑context import

   isDescriptionOf(TDescA, U.T, CA, VpA) ∧ isDescriptionOf(TDescB, U.T, CB, VpB) ∧ CA≠CB
   ⊢ ¬equateByLabel(TDescA, TDescB)  (bridges required in F.9)

   Reading: Identical wording across Contexts (and Viewpoints) does not grant equivalence; only Bridges may relate them.

#Anti‑patterns & remedies

#Worked examples (didactic)

Each vignette shows intension ↔ Description/Spec ↔ Evaluation with context‑local wording. No workflows; only thinking moves.

#Enactment (Role Assignment & Enactment line) — Change Authority role (ITIL 4 Context)

Contexts. ITIL4_2020 (services/deontics), PROV_O_2013 (run‑time traces). Intension. U.Role :: ChangeAuthority — a behavioural mask that may be worn by a system (person/team/tool) to authorise a change.

RoleDescription@ITIL4.

• Tech/Plain. ChangeAuthority / “change approver”.

• RCS (characteristics). CredentialLevel ∈ {L1,L2}; Scope ∈ {Service, Platform}; SeparationOfDuty ∈ {Clean, Violates}.

• RSG (states). Proposed → Designated → Authorized → Active → Suspended → Revoked.

• State checklists (sketch).

  • Authorized: { valid nomination, SoD=Clean, credential ≥ required, mandate window set }.
  • Active: Authorized ∧ { current shift/roster entry ∧ no conflicting active duty }.

Evaluations. U.Evaluation@ITIL4 over evidence (roster entries, mandate doc, SoD list, PROV Activities of approvals) yields attestations:

• subject=Team‑X ∈ Authorized@ITIL4 in ⟨2025‑08‑01, 2025‑12‑31⟩.
• Later, subject=Team‑X ∈ Active@ITIL4 at 2025‑09‑14T10:05Z.

Didactic hooks.

• The role is characterised by RCS/RSG in the RoleDescription; it does not contain them.
• The attestation is a statement about state‑in‑window; it does not mutate the role.

#Method (Essence‑language Context) — Backlog Refinement method

Contexts. OMG_Essence_Language_2023 (method language), PROV_O_2013 (runtime). Intension. U.Method :: BacklogRefinement.

MethodDescription@Essence.

• Tech/Plain. BacklogRefinement / “tidy backlog”.
• Inputs/Outputs (informative). Work items (ideas) → clarified items (ready/not‑ready tags).
• RCS (characteristics). Cadence ∈ {weekly, continuous}; CollaborationMode ∈ {sync, async}.
• RSG (states). Sketched → Defined → Adopted.
• State checklist (Adopted). { team agreed practice note exists, cadence set, entry/exit criteria published }.

Spec‑gate outcome. No acceptance harness yet → remains MethodDescription, not MethodSpec.

Run‑time echo. U.Work instances (calendar sessions, chat threads) are traced in PROV; Evaluation can check whether an Adopted practice is being followed in window W without ever reifying the method as a workflow.

#Service (SLO/SLA) — Calibration Service (ITIL 4 + SOSA/SSN Contexts)

Contexts. ITIL4_2020 (service), SOSA_SSN_2017 (observation), ISO_80000_1_2022 (units). Intension. U.PromiseContent :: CalibrationService.

ServiceDescription@ITIL4.

• Tech/Plain. CalibrationService / “we calibrate your sensor”.
• Acceptance facet (informative). SLO: error ≤ 0.5% FS under ISO 80000 units; formal criteria live in ServiceSpec only if harness exists.

Evaluation@ITIL4+SOSA. Observations (SOSA) from test runs compared with thresholds → ServiceEvaluation attests Met/Not‑Met in a stated window. No Cross‑context import: ISO units cited as context‑local references.

#Epistemic (KD‑line) — Evidence status vs role state

Contexts. PROV_O_2013 (provenance), FPF_Evidence_Status (status family). Intensions. U.KnowledgeUnit :: Report_42; U.EvidenceStatus :: SupportsClaim.

Separation.

• SupportsClaim@C is a status over a Episteme (classifies the report).
• It is not a node of any role’s U.RSG.
• U.Evaluation produces attestation(Report_42 has EvidenceStatus=SupportsClaim@C, W).

Didactic point. State names in role graphs do not duplicate statuses; planes stay disjoint.

#Control (Sys‑CAL line) — Control‑Operator role (IEC 61131‑3 Context)

Contexts. IEC_61131_3 (control languages), ISA_95 (integration). Intension. U.Role :: ControlOperator.

RoleDescription@IEC61131‑3.

• RCS. StationLevel ∈ {Cell, Line}; TaskMode ∈ {Cyclic, Event}; AlarmPrivileges ∈ {Ack, Ack+Shelve}.
• RSG. Onboarded → Authorized → ConsoleActive → Paused → Suspended.
• Checklists (ConsoleActive). { Authorized ∧ current console login ∧ task watchlist loaded }.

Attestation (run‑time). subject=Operator‑A ∈ ConsoleActive@IEC at 2025‑09‑14T08:00Z based on log evidence. No “workflow” required in the Description.

#Relations (with other patterns)

Builds on:

• E.10.D1 — Lexical Discipline for “Context” (D.CTX). Provides the Context primitive and bans “anchor” talk.
• A.7 — Strict Distinction (Clarity Lattice). This pattern concretises SD for intension vs description/spec vs carrier vs work.
• C.2.3 — Unified Formality Characteristic (F). Supplies the F anchors and ΔF moves that gate …Spec.

Constrains:

• F.1–F.3 (Contexts → seeds → local senses). Descriptions must cite context‑local senses (SenseCells) rather than global words.
• F.4–F.5 (role/service naming). Tech/Plain labels on Descriptions obey F.5 morphology rules.
• F.8 (Service Acceptance Binding). Evaluations of services read acceptance from Description/Spec, compare against Observations.
• F.9 (Alignment & Bridge). No Description/Spec may imply Cross‑context equivalence; Bridges carry all Cross‑context semantics.
• F.15 (SCR/RSCR Harness). Any …Spec must link to its harness; RSCR re‑checks verdict stability across editions/windows.

Is used by.

• Part C Extention Patterns. Sys‑CAL, KD‑CAL, Kind-CAL, Method‑CAL cite …Description/…Spec epistemes explicitly and consume state attestations from U.Evaluation.
• Part B trust calculus. Uses the presence/absence of harnessed Specs and the windowed nature of attestations in confidence roll‑ups.

#Migration notes (conceptual refactor playbook)

Goal: remove conflations and normalise names without changing underlying models.

1. Rename by default. Any XSpec lacking a bound acceptance harness becomes XDescription. Keep content intact; change suffix and preface with a “Description, not Spec” note.
2. Promote selectively. For epistemes that are testable and declare F ≥ F4, add harness links (F.15) and re-label as XSpec via the Spec-gate.
3. Fix the verbs. Rewrite “Role contains RSG/RCS” → “Role is characterised by RSG/RCS in RoleDescription”.
4. Detach carriers. Replace identity‑by‑file with U.Carrier encodes …Description/Spec wording.
5. Add Contexts. Where a Description drifts globally (“the backlog refinement is…”), prefix with the Context and adjust wording to be local.
6. Split planes. Move any Evidence/Requirement statuses out of role state lists; keep them as roles over knowledge units.
7. Window‑ise verdicts. Ensure every evaluation statement adds an explicit window (instant or interval).
8. Document maturity. Declare each Description’s F (C.2.3) and track ΔF promotions/demotions as part of change notes (no governance implied).

#Acceptance tests (SCR/RSCR — concept‑level)

#E.10.D2:12.1 Static conformance checks (SCR)

• SCR-D2-S01 (Suffix discipline). Every episteme with suffix –Spec passes the Spec-gate (F ≥ F4 ∧ testable invariants ∧ harness link ∧ Context named). Otherwise it bears –Description.
• SCR‑D2‑S02 (Characterisation verbs). Texts never say an intension “contains” RCS/RSG; they say it is characterised by them via the Description/Spec.
• SCR‑D2‑S03 (Plane purity). No episteme mixes role states and knowledge statuses; each appears only on its correct plane.
• SCR‑D2‑S04 (context‑locality). Every Description/Spec names its U.BoundedContext; wording reads correctly when prefixed by the Context.
• SCR‑D2‑S05 (Two registers). Tech and Plain labels present on all Descriptions/Specs.
• SCR‑D2‑S06 (Carrier separation). Identity statements refer to Epistemes; files are referenced only as U.Carrier encodings.
• SCR‑D2‑S07 (Windowed evaluation). All state attestations cite a window W (instant or interval).

#E.10.D2:12.2 Regression checks (RSCR)

• RSCR‑D2‑E01 (Spec demotion guard). If a –Spec loses its harness or testability, it is demoted to –Description; diffs show no lingering “shall” claims.
• RSCR‑D2‑E02 (Bridge drift). If two Contexts begin to share identical labels, verify no Descriptions/Specs imply Cross‑context identity; add or revise F.9 Bridges instead.
• RSCR‑D2‑E03 (Edition churn). When a Context’s canon updates, previously valid attestations remain historical (windowed); new Specs/Descriptions cite the new edition.
• RSCR‑D2‑E04 (Verb hygiene). Automated grep over corpus finds “contains RSG/RCS” phrasing; none remain after refactor.
• RSCR‑D2‑E05 (Status bleed). Spot‑audit a random sample of role graphs to ensure no epistemic/deontic statuses appear as role states.

Didactic takeaway. Think in three layers: Intension (what the thing is), Description/Spec (how we state its character and, when mature, test it), and Evaluation (what we can attest about it in a window). Keep Contexts local, planes separate, and “contains” out of your vocabulary.

#Author’s pocket guide (carry‑in‑mind rules)

Use these as thinking cues, not as paperwork. Each cue is a one‑breath test you can apply while writing.

1. Name the Context. Write “Role (ITIL4)”, “Method (Essence‑language)”, “Execution (PROV)”. Never speak global words.
2. Pick the object-of-talk. Am I talking about an intension (Role/Method/Service), a Description/Spec, an Evaluation, or a Carrier? Stay on one object-of-talk per sentence.
3. Prefer –Description. Use …Description by default. Switch to …Spec only after the Spec‑gate (testable invariants + harness + F‑mode).
4. Characterised by… Say “Role is characterised by RCS/RSG recorded in RoleDescription”, never “Role contains its states”.
5. Window every verdict. An Evaluation must read “X ∈ State@context in W”. No naked, timeless verdicts.
6. Status ≠ state. Role states live in U.RSG; Evidence/Requirement statuses classify knowledge units. Do not mix.
7. Bridge later. If two Contexts “feel the same”, write the itch down and leave it for F.9 Bridge.
8. Two registers. Every Description/Spec has Tech and Plain labels; prefer the shortest tech term that matches the invariants.
9. Carrier humility. Files and records are Carriers of Descriptions/Specs; they don’t equal the thing you reason about.
10. Spec = test. If you can’t point to a harness that would falsify it, it isn’t a Spec yet.

#Phrasebook & pitfall table (say this, not that)

#Naming & alias policy (normative, notation‑free)

#Suffix discipline (recap).**

• Preferred default: …Description for Role/Method/Service/Work.
• Reserved: …Spec only if the item passed the Spec‑gate (F‑mode, testable invariants, harness id, Context named).
• Banned: Using –Spec as a synonym for “detailed description”.

#Canonical/alias map (current edition).**

#Verb & morphology rules.**

• Verbs. Use characterised by, recorded in, encoded by; avoid contains, is stored in, is implemented by when speaking at the conceptual level.

• Morphology.

  • Roles name masks as count nouns (Operator, ChangeAuthority).
  • States as state nouns/participles (Authorized, Active).
  • Status names are classifiers over knowledge (SupportsClaim, NormativeStandard).
  • Descriptions/Specs use neutral nouns (RoleDescription, MethodSpec).

#Deprecations (effective now).**

• MethodSpec (as a general name) → MethodDescription unless Spec‑gate is met.
• WorkSpec (alias for WorkPlan) → WorkDescription (allowed alias), or U.WorkPlan (preferred).
• Texts must avoid “contains RSG/RCS” phrasing (see RSCR‑D2‑E04).

#Quick templates (fill‑in‑mind, not forms)

Copy these lines into your prose as thinking scaffolds. They are not schemas, fields, or checklists to fill; they are didactic prompts.

#Role (default).

• Intension. U.Role :: <TechName> in <ContextId>.

• RoleDescription@context. Tech/Plain: <TechName> / <PlainName>.

• RCS characteristics. <characteristic₁ ∈ {… }>; <characteristic₂ ∈ {… }>.

• RSG nodes (→). <S₀ → S₁ → … → Sₙ>.

• State checklist (one node). <StateX : {criterion₁, …}>.

• Evaluation attestation. subject=<Holder> ∈ <StateX>@<ContextId> in <Window> (evidence: <cue₁,…>).

#Method (Essence‑language Context).

• Intension. U.Method :: <TechName>.
• MethodDescription@context. Inputs/Outputs (informative), RCS/RSG (if you track adoption).
• Spec upgrade (optional). “Becomes MethodSpec when harness <id> exists.”

#Service (acceptance‑bearing).**

• ServiceDescription@context. Tech/Plain; Acceptance facet (informative until harnessed).
• Evaluation. Service ∈ Met/Not‑Met@context in <Window> based on observations and acceptance criteria.

#Alignment reminder.

• “No Cross‑context identity is implied; if needed, add F.9 Bridge: <ContextA:TermA> ↔ <ContextB:TermB> with CL/loss notes.”

#Didactic distillation (90‑second script)

“Three layers; one context; no leakage.”

1. Pick the Context. Every word lives inside a U.BoundedContext.
2. Pick the I/D/S layer. Speak about the Intension (I), or about its Description/Spec (D/S)—but never mix layers. If your sentence also asserts describedEntity or evidence, name the ReferencePlane (world|concept|episteme).
3. Describe, then test. Start with Role/Method/ServiceDescription. Only when you can falsify it with a harness do you call it a Spec.
4. State is attested. Role states are attested by Evaluations as “X ∈ State@context in W”. Evidence/Requirement statuses classify knowledge, not roles.
5. Carriers carry. PDFs and repos are Carriers of the Description/Spec; they aren’t the thing itself.
6. Bridges are explicit. Cross‑context sameness is never assumed; you declare a Bridge with CL/loss. Follow these six lines and SD (Strict Distinction) stops being an abstraction—you feel it in every sentence you write.

#E.10.D2:End

#Didactic Primacy & Cognitive Ergonomics

#Problem Frame

The FPF is designed as an "Operating System for Thought," a tool intended to augment and clarify human (and artificial) reasoning. This mission places a unique demand on its architecture: the framework's internal elegance and formal power are secondary to its primary function of being understandable and usable. A perfectly consistent but incomprehensible system fails in its didactic purpose. As formal mechanisms like Assurance Levels and epistemic scores are introduced, there is a significant risk that the pursuit of these metrics becomes an end in itself, overshadowing the ultimate goal of fostering clearer thought.

#Problem

If the framework's design prioritizes theoretical purity or formal completeness over cognitive ergonomics, it becomes vulnerable to two critical failure modes:

1. Goodhart's Law: When a measure (like AssuranceLevel:L2) becomes the primary target, it ceases to be a good measure of genuine understanding. Teams may start "gaming the metrics," producing artifacts that are formally perfect but conceptually shallow or pragmatically useless.
2. Cognitive Overload & Rejection: The framework becomes so dense, jargon-laden, and procedurally complex that its users—the very agents it is meant to serve—either burn out or abandon it in favor of simpler, albeit less rigorous, methods. The "Operating System for Thought" devolves into a bureaucratic machine for certification.

#Forces

#Solution

FPF elevates Didactic Primacy (Pillar P-2) to a normative architectural principle, operationalized through two conceptual mechanisms designed to act as a permanent counterbalance to excessive formalism.

#The Principle of Didactic Primacy (Expanded Definition)

The primary purpose of the FPF is to enhance the cognitive capabilities (U.Capability/Mastery) of an Agent (U.Agent) in service of its Objectives (U.Objective). The creation of artifacts with high assurance levels and epistemic scores is a means to that end, not the end itself. Any architectural decision that increases formal rigor at the cost of clarity or usability must be explicitly justified by a demonstrable gain in the agent's ability to reason effectively.

#Mechanism 1: The Rationale Mandate

Every key assurance artifact (such as a U.AssuranceCase or Proof) MUST contain a mandatory, human-readable rationale component.

• Nature: The rationale is not a technical description but a narrative explanation.
• Content: It MUST answer the question: "How does achieving this level of formal assurance tangibly help the agent better understand the problem or make a more reliable decision?"
• Purpose: This mandate forces a moment of reflection, formally linking the act of formalization back to its pragmatic, cognitive purpose. An empty or perfunctory rationale indicates that the assurance work may be an exercise in formalism for its own sake.

Didactic Note for Managers: The "So What?" Test

The Rationale Mandate is FPF's built-in "So What?" test. When your team presents a complex, formally verified artifact (AssuranceLevel:L2), the rationale is where they answer your fundamental question: "This is impressive, but so what? How does this help us ship a better product, make a smarter investment, or avoid a critical risk?" If the answer isn't clear and compelling in the rationale, the formal work may have been a waste of resources. It keeps your most brilliant minds focused on creating value, not just elegant proofs.

#Mechanism 2: The Human-Factor Loop (HF-Loop)**

To provide a continuous, self-correcting mechanism against cognitive overload, FPF introduces a conceptual feedback loop.

• Core Concept: The HF-Loop is a formal method of inquiry designed to distinguish between the essential complexity of the problem being solved and the incidental complexity introduced by the FPF itself.
• Trigger Concept: A review is triggered when the subjective cognitive workload associated with using the framework exceeds a conceptual threshold. This is not about performance metrics, but about the perceived mental effort required to use FPF's concepts and structures.
• Review Concept: When triggered, a formal review is conducted by individuals in roles that specialize in human-centric perspectives, such as the Ethicist and UX Design Critic.
• Output Concept: The review produces a set of proposed conceptual simplifications or didactic improvements to the framework's patterns. These are then submitted as formal change proposals (DRRs).

#Conformance Checklist

• CC-E12.1 (Rationale Mandate): Every U.AssuranceCase or Proof artifact at AssuranceLevel:L2 MUST contain a non-empty rationale component that satisfies the "So What?" test.
• CC-E12.2 (HF-Loop Trigger Condition): Each pattern that defines a significant workflow SHOULD specify a conceptual condition for triggering an HF-Loop review, based on the principle of managing cognitive load.
• CC-E12.3 (HF-Loop Review Mandate): If a trigger condition is met, a review involving the designated human-centric roles MUST be initiated. Its outcome MUST be a documented set of conceptual refinement proposals.
• CC-E12.4 (Didactic Primacy in DRRs): Any DRR proposing a change to a normative pattern MUST include a section analyzing its impact on cognitive ergonomics and didactic clarity.