#Preface Catalog

#What this page is

This catalog lists generated reference pages from FPF preface and supporting sections. These pages explain how to read the specification; they are not FPF Reference product documentation.

#Methodology

Use these pages when you need interpretation guidance before applying a route or pattern. For active work, return to Start Here, a route, or a work packet after the reading burden is clear.

#First Principles Framework (FPF) - Core Conceptual Specification

• First Principles Framework (FPF) - Core Conceptual Specification

#Table of Content

• Table of Content

#First Principles Framework (FPF) Readme

• First Principles Framework (FPF) Readme
• Decide Whether FPF Fits
• First Practical Entries
• 1. Develop or review architecture
• 2. Write rules, methods, and work-process documents
• 3. Compare alternatives and make a local choice
• 4. Turn a vague situation into a usable problem statement
• 5. Define what "better" means and run improvement
• 6. Prepare evidence, assurance, or gate decisions before commitment
• 7. Check timing, freshness, rhythm, and action windows
• 8. Use causal explanations, interventions, responsibility, and model outputs safely
• 9. Compare descriptions, dashboards, explanations, and views of the same thing
• 10. Give things better names
• 11. Repair wording in technical documents before it changes action
• 12. Decide whether mathematics or formal modeling would help
• 13. Build a state-of-the-art or option portfolio
• One-Minute Example
• What FPF Is
• What FPF Is Not
• How to Use This Repository
• Citation

#Preface (non-normative)

• Preface (non-normative)
• What This Specification Is And How To Use It
• FPF As A Project, Not Only A Pattern List
• Why FPF Exists
• Creativity And Assurance Mature Together
• Local Closure Inside An Open World
• FPF As An Evolutionary Architecture For Thought
• Architectural Characteristics Of Thought
• Beyond Bias Hunting
• Thinking Through Writing
• Thinking-Oriented Architecture, Not A Descriptive Upper Ontology
• The Bitter Lesson Stance
• From Flat Documents To Multi-View Truth
• Architecture As Structure Of Holons
• Boundary Statements
• Raising Semantic Precision
• Big FPF Storylines
• Transdisciplinarity As A Meta-Theory Of Thinking
• The Culinary Architecture Of Collective Thought
• The Intellect Stack As A Pedagogical Map
• Purpose, Scope, And Non-Goals
• How To Continue After The readme

#Part A – Kernel Architecture Cluster

• Part A – Kernel Architecture Cluster
• 4.1 Plain one‑liners (normative on‑ramp; formal anchors in C.17–C.19)
• 4.2 Publication & telemetry duties (where these terms show up)
• 4.3 Minimal first-day construction
• A.0:End
• A.1:End
• A.1.1:End
• A.2:End
• A.2.1:End
• A.2.2 — U.Capability
• A.2.2:4.1 Definition
• A.2.2:4.2 Conceptual descriptors (not a data schema)
• A.2.2:4.3 Shorthand for everyday speech
• A.2.2:6.1 Physical system on a line (structural example)
• A.2.2:6.2 Software service in operations (structural, cyber-physical)
• A.2.2:6.3 Organizational unit (enterprise sense)
• A.2.2:End
• A.2.3:End
• A.2.4:End
• A.2.5:End
• A.2.6:17. 4 Rationale - F‑Cluster Unification for A.2.6 (F.17 and F.18)
• A.2.6:End
• A.2.7:End
• A.2.8:End
• A.2.9 — U.SpeechAct (Communicative Work Object)
• A.2.9:1 — Problem frame
• A.2.9:2 — Problem
• A.2.9:3 — Forces
• A.2.9:4 — Solution
• A.2.9:4.1 — Normative definition
• A.2.9:4.2 — Minimal structure (normative)
• A.2.9:4.3 — SpeechActRef discipline (normative)
• A.2.9:4.4 — Separation rules with U.Commitment and U.PromiseContent (normative)
• A.2.9:4.5 — Multi-function and multi-party support (normative)
• A.2.9:5 — Archetypal Grounding (Tell–Show–Show)
• A.2.9:5.1 — Tell (universal rule)
• A.2.9:5.2 — Show #1 (system archetype: change-control approval gates a deployment)
• A.2.9:5.3 — Show #2 (episteme archetype: publishing a spec edition without making the spec an agent)
• A.2.9:6 — Bias-Annotation
• A.2.9:7 — Conformance Checklist (normative)
• A.2.9:8 — Common Anti-Patterns and How to Avoid Them
• A.2.9:9 — Consequences
• A.2.9:10 — Rationale
• A.2.9:11 — SoTA‑Echoing (informative; post‑2015 alignment)
• A.2.9:12 — Relations
• A.2.9:End
• A.3:End
• A.3.1:End
• A.3.2:End
• A.3.3:End
• A.4:End
• A.5:End

#Cluster A.IV.A - Signature Stack & Boundary Discipline (A.6.)*

• *Cluster A.IV.A - Signature Stack & Boundary Discipline (A.6.)**
• Tell (universal rule)
• Show #1 (U.System): effectful API boundary (algebraic effects intuition)
• Show #2 (U.Episteme): published evaluation protocol boundary (multi‑view + evidence)
• A.6:End
• A.6.RSIG:End
• A.6.B — Boundary Norm Square (Laws / Admissibility / Deontics / Work‑Effects)
• A.6.B:0 — Conventions
• A.6.B:1 — Problem frame
• A.6.B:2 — Problem
• A.6.B:3 — Forces
• A.6.B:4.2 — The square
• A.6.B:4.3 — Canonical placements in the Signature Stack
• A.6.B:5 — Quadrant specifications
• A.6.B:5.1 — Quadrant L: Laws & Definitions
• A.6.B:5.2 — Quadrant A: Admissibility & Gates
• A.6.B:5.3 — Quadrant D: Deontics & Commitments
• A.6.B:5.4 — Quadrant E: Work‑Effects & Evidence
• A.6.B:6 — Cross‑quadrant link discipline
• A.6.B:6.1 — Explicit reference rule
• A.6.B:6.2 — Canonical cross‑quadrant dependency patterns
• A.6.B:6.3 — The “triangle decomposition” for mixed sentences
• A.6.B:6.4 — Dependency direction (no “upward” imports)
• A.6.B:7 — Mini-register: Claim Register (informative, recommended)
• A.6.B:8.4 — Worked Rewrite Kit (informative, recommended)
• A.6.B:9 — Bias‑Annotation
• A.6.B:10 — Conformance Checklist
• A.6.B:12 — Consequences
• A.6.B:13 — Rationale
• A.6.B:14 — SoTA‑Echoing (post‑2015 practice alignment)
• A.6.B:15 — Relations
• A.6.B:End
• A.6.C — Contract Unpacking for Boundaries
• A.6.C:1 — Problem frame
• A.6.C:2 — Problem
• A.6.C:3 — Forces
• A.6.C:4 — Solution
• A.6.C:4.1 — The Contract Bundle (four-part unpacking)
• A.6.C:4.2 — Routing recipe into A.6.B (L/A/D/E)
• A.6.C:4.3 — “Guarantee” disambiguation
• A.6.C:4.4 — MVPK faces are not second contracts
• A.6.C:4.5 — Default register: Contract Claim Register (recommended)
• A.6.C:5 — Archetypal Grounding (Tell–Show–Show)
• A.6.C:5.1 — Tell
• A.6.C:5.2 — Show (System archetypes)
• A.6.C:5.3 — Show (Episteme archetypes)
• A.6.C:6 — Bias-Annotation
• A.6.C:7 — Conformance Checklist
• A.6.C:8 — Common Anti-Patterns and How to Avoid Them
• A.6.C:9 — Consequences
• A.6.C:10 — Rationale
• A.6.C:11 — SoTA‑Echoing (informative; post‑2015 alignment)
• A.6.C:12 — Relations
• A.6.C:End
• A.6.0:End
• A.6.1:End
• A.6.2:End
• A.6.3:End
• A.6.3.CSC:End
• A.6.3.CR:4.5.a. Preservation rule
• A.6.3.CR:4.5.b. Loss and reliability rule
• A.6.3.CR:4.5.c. Authority and handoff rule
• A.6.3.CR:4.5.d. Composition and reopen rule
• A.6.3.CR:4.5.e. Non-collapse note for correspondence
• A.6.3.CR:4.5.f. Local conservativity witness for borderline textual cases
• A.6.3.CR:End
• A.6.3.RT:4.5.a. Preservation rule
• A.6.3.RT:4.5.a.1. Local conservativity witness
• A.6.3.RT:4.5.b. Loss and reliability rule
• A.6.3.RT:4.5.c. Authority and handoff rule
• A.6.3.RT:4.5.c.1. Same-entity entry condition for decode-mediated cases
• A.6.3.RT:4.5.d. Composition and reopen rule
• A.6.3.RT:End
• A.6.4:End
• A.6.P — Relational Precision Restoration (RPR) — Kind‑Explicit Qualified Relation Discipline
• A.6.P:0 — TERM and LEX token guards (local-first)
• A.6.P:1 — Problem frame
• A.6.P:2 — Problem
• A.6.P:3 — Forces
• A.6.P:4 — Solution — The RPR recipe (Lens → Slots → Change Lexicon → Guardrails), aligned to A.6 / A.6.B / A.6.S
• A.6.P:4.0a — Operational repair sequence (how repairs actually proceed)
• A.6.P:4.0b — Candidate‑Set Note (informative; review record)
• A.6.P:4.1 — Stable lens
• A.6.P:4.2 — Kind‑explicit relation tokens (no umbrella meaning‑surrogates)
• A.6.P:4.3 — Slot‑explicit qualified relation records (recover hidden arity)
• A.6.P:4.4 — Change‑class lexicon (operations are not adjectives)
• A.6.P:4.5 — Lexical guardrails (ban umbrella metaphors as meaning‑surrogates)
• A.6.P:4.6 — Progressive elaboration (the “precision dial” rule)
• A.6.P:4.7 — Two-view and polarity discipline (no silent role flips)
• A.6.P:4.8 — Disambiguation guide (rewrite/selection)
• A.6.P:4.9 — A.6.B classification template for RPR relation specifications
• A.6.P:4.10 — A.6.S compatibility note (ConstructorSignature is optional but canonical for engineered relation specialisations)
• A.6.P:5 — Archetypal Grounding (System / Episteme)
• A.6.P:5.1 — System archetype: “same system across environments”
• A.6.P:5.2 — Episteme archetype: “the models are synced”
• A.6.P:6 — Bias‑Annotation
• A.6.P:7 — Conformance Checklist (CC‑A.6.P)
• A.6.P:8 — Common Anti‑Patterns and How to Avoid Them
• A.6.P:9 — Consequences
• A.6.P:10 — Rationale
• A.6.P:11 — SoTA‑Echoing (informative; post‑2015 alignment)
• A.6.P:12 — Relations
• A.6.P:End
• A.6.A:End
• A.6.F:End
• A.6.M:End
• A.6.5:End
• A.6.6:End
• A.6.7:4.1 MechSuiteDescription (data model)
• A.6.7:4.2 SuiteObligations (canonical obligation vocabulary)
• A.6.7:4.3 SuiteSpecPins
• A.6.7:4.4 SuiteProtocols
• A.6.7:4.5 SuiteAuditObligations
• A.6.7:4.6 Examples (tell–show–show discipline)
• A.6.7:End
• A.6.8:4.0 — UTS + LEX preparation (mandatory for authoring/repair)
• A.6.8:4.1 — Trigger rule
• A.6.8:4.2 — Stable lens: the Service Situation Bundle
• A.6.8:4.3 — Facet headwords (mandatory lexical rule)
• A.6.8:4.4 — Addressability rule (the “can you call it?” test)
• A.6.8:4.4b — Method/mechanism rule (the “how does it work?” test)
• A.6.8:4.5 — Deontic rule (the “must/shall” test)
• A.6.8:4.6 — Speech‑act rule (the performative verb test)
• A.6.8:4.7 — Runtime/telemetry rule (the “actuals” test)
• A.6.8:4.8 — Change‑class lexicon (service‑specific narrations)
• A.6.8:4.9 — Disambiguation guide (rewrite/selection)
• Show 1 — System archetype (microservices + SRE)
• Show 2 — Episteme archetype (physical/human service)
• A.6.8:End
• A.6.9:End
• A.6.S:End
• A.6.H:End

#Cluster A.V - Constitutional Principles of the Kernel

• Cluster A.V - Constitutional Principles of the Kernel
• A.7:End
• A.8:End
• A.9:End
• A.10:4.3 SCR / RSCR (Symbol Carrier Registers).
• A.10:4.4 Scope alignment (A.4) across Role–Method–Work (A.15).
• A.10:4.5 External TransformerRole (A.12).
• A.10:4.6 Γ-flavour hooks (how each flavour evidences).
• A.10:End
• A.11:End
• A.12:4. Solution
• A.12:End
• A.13:End
• A.14:End
• A.15:End
• A.15.1:End
• A.15.2:End
• A.15.3:4.1 Definition
• A.15.3:4.2 Core conceptual descriptors (not a data schema)
• A.15.3:4.2.1 Canonical skeleton (Show)
• A.15.3:4.3 Relation to Work enactment (planned baseline vs actuals)
• A.15.3:4.4 Relation to suites or kits
• A.15.3:End
• Core stress-case rule
• Repair assignment rule
• Exact project-side FPF kind and reference lookup table
• Worked dashboard and approval examples
• A.15.4:End
• A.16:End
• A.16.0:End
• A.16.1:End
• A.16.2:End
• A.17:End
• A.18:End
• A.19:5.2.1.2 Embedding – Injection ι : CS₁ ↪ CS₂.
• A.19:5.2.1.3 Product – Combination CS₁ ⊗ CS₂ = CS⊗.
• A.19:5.2.2.1 Coordinatewise comparability (≼_coord)
• A.19:5.2.2.2 Normalization‑based comparability (≼_normalization)
• A.19:5.2.4.1 Direction & loss (Bridges).
• A.19:5.2.4.2 Confidence penalties for mapped comparisons.
• A.19:5.2.4.3 Declare “incomparable” when appropriate.
• A.19:End
• A.19.ECS:End
• A.19.SPR:End
• A.19.SOURCE-SET-SPACE-SUBSTRATE - Source-Set and Search/Outcome-Space Substrate
• A.19.SOURCE-SET-SPACE-SUBSTRATE:0 - Use this when
• A.19.SOURCE-SET-SPACE-SUBSTRATE:0.1 - What goes wrong if missed
• A.19.SOURCE-SET-SPACE-SUBSTRATE:0.2 - What this buys
• A.19.SOURCE-SET-SPACE-SUBSTRATE:0.a - TERM/LEX token-status guard (local-first)
• A.19.SOURCE-SET-SPACE-SUBSTRATE:0.b - First-minute operator cue and confusion guide
• A.19.SOURCE-SET-SPACE-SUBSTRATE:1 - Problem frame
• A.19.SOURCE-SET-SPACE-SUBSTRATE:2 - Problem
• A.19.SOURCE-SET-SPACE-SUBSTRATE:3 - Forces
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4 - Solution
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.1 - Declared relation-and-ref-position stack and outside work
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.2 - Minimal declaration stack
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.3 - Substrate declaration laws (SS-0..SS-7)
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.4 - Profiles
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.5 - Operational declaration sequence (fail-closed)
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.6 - Canonical rewrite forms
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.7 - Conditional fields stay conditional
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.8 - Qualifier refs stay substrate-side
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.9 - Descriptor maps and distance definitions dock here, but do not replace the space refs
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.10 - Publication and shipping remain downstream consumers
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.11 - Ordinary and heavier use
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.12 - Operator kit: choose, declare, self-check, apply governing neighbor
• A.19.SOURCE-SET-SPACE-SUBSTRATE:4.13 - Using the substrate with neighboring patterns
• A.19.SOURCE-SET-SPACE-SUBSTRATE:5 - Archetypal Grounding
• A.19.SOURCE-SET-SPACE-SUBSTRATE:5.1 - System
• A.19.SOURCE-SET-SPACE-SUBSTRATE:5.2 - Episteme
• A.19.SOURCE-SET-SPACE-SUBSTRATE:5.3 - Boundary anti-case
• A.19.SOURCE-SET-SPACE-SUBSTRATE:5.4 - Use-situation spread
• A.19.SOURCE-SET-SPACE-SUBSTRATE:6 - Bias-Annotation
• A.19.SOURCE-SET-SPACE-SUBSTRATE:7 - Conformance Checklist
• A.19.SOURCE-SET-SPACE-SUBSTRATE:8 - Common Anti-Patterns and How to Avoid Them
• A.19.SOURCE-SET-SPACE-SUBSTRATE:9 - Consequences
• A.19.SOURCE-SET-SPACE-SUBSTRATE:10 - Rationale
• A.19.SOURCE-SET-SPACE-SUBSTRATE:11 - SoTA-Echoing
• A.19.SOURCE-SET-SPACE-SUBSTRATE:12 - Relations
• A.19.SOURCE-SET-SPACE-SUBSTRATE:End
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW - Declared-Substrate Interpretive View
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:0 - Use this when
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:0.1 - What goes wrong if missed
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:0.2 - What this buys
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:0.a - TERM/LEX token-status guard (local-first)
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:0.b - First-minute operator cue and confusion guide
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:1 - Problem frame
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:2 - Problem
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:3 - Forces
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4 - Solution
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.1 - Declared-substrate interpretive-view record and outside work
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.2 - Minimal interpretive view declaration
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.3 - Interpretive-view declaration laws (IV-0..IV-8)
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.4 - Profiles
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.5 - Operational declaration sequence (fail-closed)
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.6 - Thin interpretation remains a complete admissible form
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.7 - Atlas form is fuller interpretation and needs a complete record
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.8 - No autonomous local view law is introduced here
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.9 - Qualifier refs stay substrate-side
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.10 - Publication, set-result, and pool-policy boundaries
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.11 - G.2 keeps the tradition-facing atlas specialization
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.12 - Operator kit: choose, record, preserve, apply governing neighbor
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:4.13 - Using the interpretive view with neighboring patterns
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:5 - Archetypal Grounding
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:5.1 - System
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:5.2 - Episteme
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:5.3 - Boundary anti-case
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:5.4 - Use-situation spread
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:6 - Bias-Annotation
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:7 - Conformance Checklist
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:8 - Common Anti-Patterns and How to Avoid Them
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:9 - Consequences
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:10 - Rationale
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:11 - SoTA-Echoing
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:12 - Relations
• A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:End
• A.19.CN:8.4.3 Alignment CN‑frame — Design-time reuse of states across Contexts
• A.19.CN:Close
• A.19.CN:End
• A.19.CHR:End
• A.19.UNM:End
• A.19.UINDM:End
• A.19.USCM:End
• A.19.ULSAM:End
• A.19.CPM:End
• A.19.SelectorMechanism:End
• A.20:Appendix A — CV Class Gloss (normative)
• A.20:Appendix B — LEX discipline (summary)
• A.20:End
• A.21 — GateProfilization: OperationalGate(profile) (GateFit core)
• A.21:End
• A.22:End
• B.1:End
• B.1.1:End
• B.1.2:End
• B.1.3:End
• B.1.4:End
• B.1.5:End
• B.1.6:End
• B.2:End
• B.2.2:End
• B.2.3:End
• B.2.4:End
• B.2.5:End
• B.3:5 Proof obligations (attach these when producing an Assurance tuple)
• B.3:End
• B.3.3 — Assurance Subtypes & Levels
• B.3.3:End
• B.3.4:End
• B.3.5:End
• B.4:End
• B.4.1:End
• B.5:End
• B.5.1:End
• B.5.2:End
• B.5.2.0:End
• B.5.2.1:End
• B.5.3:End

#Part C — Kernel Extensions Specifications

• Part C — Kernel Extensions Specifications
• C.2:End
• C.2.1:End
• C.2.P:End
• C.2.2:End
• C.2.2a:End
• C.2.3:End
• C.2.LS:End
• C.2.4:End
• C.2.5:End
• C.2.6:End
• C.2.7:End
• C.3:7.1 How typed reasoning plugs into F–G–R & USM
• 10 - Review & integration guidance
• C.3:End
• C.3.1:End
• C.3.2:End
• C.3.3:End
• C.3.4:End
• C.3.5:End
• C.3.A:Annex A - How typed reasoning plugs into Compliance & Regulatory Alignment (A/I)
• C.3.A:A.1 Purpose & fit
• C.3.A:A.2 Normative obligations
• C.3.A:A.3 Guard macros (ready to use)
• C.3.A:A.4 Worked examples (I)
• C.3.A:A.5 Design guidance & pitfalls (I)
• C.3.A:A.6 Migration checklist (I)
• C.3.A:A.7 Manager’s one‑page pattern (I)
• C.3.A:Annex B - How typed reasoning plugs into Assurance Lanes (VA/LA/TA) & Evidence design (A/I)
• C.3.A:B.1 What you get with typed assurance (I)
• C.3.A:B.2 Normative obligations for evidence design
• C.3.A:B.3 Designing the evidence matrix (I)
• C.3.A:B.4 VA lane — proofs that match the kind (A/I)
• C.3.A:B.5 LA lane — tests & monitoring that cover the right variants (A/I)
• C.3.A:B.6 TA lane — tool qualification where it belongs (A/I)
• C.3.A:B.7 Guard macros for evidence planning & attachment
• C.3.A:B.8 Anti‑patterns & remedies
• C.3.A:B.9 End‑to‑end example (manager’s cheat‑sheet) (I)
• C.3.A:Annex C. ESG guards
• C.3.A:C.1 ESG guard obligations (normative)
• C.3.A:End
• C.11:End
• C.13 — Constructional Mereology (Compose‑CAL)
• C.13:End
• C.16:5.7 Cross-references & source references
• C.16:End
• C.16.P:End
• C.16.Q:End
• C.17:15.4 What these cases illustrate (tie‑backs)
• C.17:26- Open questions (non‑normative, research hooks)**
• C.17:End
• C.18:End
• C.18.1:End
• C.19:End
• C.19.1:End
• C.20:End
• C.21:End
• C.22:End
• C.22.1:End
• C.22.2:End
• C.23:End
• C.24:End
• C.25:End
• C.26:End
• C.26.1:End
• C.26.2:End
• C.26.3:End
• C.27:End
• C.28:End
• Source and governing basis
• C.29:End
• C.30:End
• C.30.AD:End
• C.30.P:End
• C.30.STRAT:End
• C.30.ASV:End
• C.30.LCA:End
• C.30.ILC:End
• C.30.TGA-FLOW-REL - Architecture-TGA Flow-Structure Relation
• C.30.TGA-FLOW-REL:1 - Problem frame
• C.30.TGA-FLOW-REL:2 - Problem
• C.30.TGA-FLOW-REL:3 - Forces
• C.30.TGA-FLOW-REL:4 - Solution
• C.30.TGA-FLOW-REL:4.1 - Use trigger
• C.30.TGA-FLOW-REL:4.2 - Relation to functional structure
• C.30.TGA-FLOW-REL:4.3 - Claim-kind applications named by value
• C.30.TGA-FLOW-REL:4.4 - E.18:5.12 boundary statement
• C.30.TGA-FLOW-REL:4.5 - Worked slices
• C.30.TGA-FLOW-REL:4.6 - Lowering and currentness conditions
• C.30.TGA-FLOW-REL:5 - Archetypal Grounding
• C.30.TGA-FLOW-REL:6 - Bias-Annotation
• C.30.TGA-FLOW-REL:7 - Conformance Checklist
• C.30.TGA-FLOW-REL:8 - Common Anti-Patterns and How to Avoid Them
• C.30.TGA-FLOW-REL:9 - Consequences
• C.30.TGA-FLOW-REL:10 - Rationale
• C.30.TGA-FLOW-REL:11 - SoTA-Echoing
• C.30.TGA-FLOW-REL:12 - Relations
• C.30.TGA-FLOW-REL:End
• C.31:End
• C.31.RSA:End
• C.31.ASAP:End
• D.5:End
• E.1:End
• E.2:End
• E.2.DA:End
• E.3:End
• E.4:End
• E.5:End
• E.5.1:End
• E.5.2:End
• E.5.3:End
• E.5.4:End
• E.6:End
• E.7:End
• E.8:End
• E.8.ECSPF:End
• E.9:End
• E.9.DA:End
• E.10:End
• E.10.ARCH:End
• E.10.P:End
• E.10.D1:9.1 Enactment — process vs activity (two context of meaning).
• E.10.D1:9.2 Roles — behavioural mask vs access status.
• E.10.D1:9.3 Services & evidence.
• E.10.D1:End
• E.10.D2:End
• E.11:End
• E.12:End
• E.13:End
• E.14:End
• E.15:End
• E.16:End
• E.17.0:End
• E.17.1:End
• E.17.2:End
• E.17:End
• E.17.EFP:4.5.a. Preservation rule
• E.17.EFP:4.5.b. Loss and reliability rule
• E.17.EFP:4.5.c. Downstream-use and boundary rule
• E.17.EFP:4.5.d. Composition and reopen rule
• E.17.EFP:End
• E.17.ID.CR:End
• E.17.AUD:End
• E.17.AUD.LHR:End
• E.17.AUD.OOTD:End
• E.18:End
• E.18.1:End
• E.19:End
• E.20:End
• E.21:End
• E.22:End
• E.23:End
• F.0.1:9.1 Enactment × Provenance — process vs activity
• F.0.1:9.3 Measurement × Service — observation vs service metric
• F.0.1:9.4 Type reasoning — subclass‑of (OWL) vs is‑a (plain)
• F.0.1:9.5 Deontics × Access — permission vs role (RBAC)
• F.0.1:End
• F.1:12.1 Enactment (U.RoleAssignment + U.RoleEnactment) with sensing & execution (service acceptance)
• F.1:12.2 Method quartet with types & measurement (model state graph)
• F.1:12.3 Control & actuation with services (operational SLOs in plants)
• F.1:End
• F.2 — Term Harvesting & Normalisation
• F.2:6.2 -Move B — Name it in the Context’s idiom
• F.2:11.1 Enactment + sensing
• F.2:11.2 Sys‑CAL / LCA‑CAL + services
• F.2:11.3 Kind-CAL + Method‑CAL + KD‑CAL
• F.2:End
• F.3:End
• F.4:End
• F.5:End
• F.6:End
• F.7:End
• F.8:12.4 Subtype relation across OWL and a curated taxonomy (formalists)
• F.8:End
• F.9:End
• F.9.1:End
• F.10:End
• F.11:11.4 Incident response (services + enactment)
• F.11:End
• F.12 — Service Acceptance–Work Evidence Link
• F.12:15.3 Didactic distillation (60‑second recap)
• F.12:End
• F.13:12.2 -Local alias
• F.13:End
• F.14:End
• F.15:End
• F.16:End

#| Block | FPF U.Type | Unified Tech name | Unified Plain name | Plain‑Twin Governance (PTG) | Twin‑Map Id (LEX) | FPF Description

• | Block | FPF U.Type | Unified Tech name | Unified Plain name | Plain‑Twin Governance (PTG) | Twin‑Map Id (LEX) | FPF Description

#| Block | Base concept (EN / RU) | Scale‑map (Σ/Π/μ)

• | Block | Base concept (EN / RU) | Scale‑map (Σ/Π/μ)
• F.17:End
• F.18:End
• F.19:End
• G.Core - Part G Core Invariants
• G.Core:1 - Problem frame
• G.Core:2 - Problem
• G.Core:3 - Forces
• G.Core:4 - Solution
• G.Core:4.1 - Delegation-first citation for Part‑G‑wide invariants
• G.Core:4.2 - Mandatory G.Core linkage manifest requirement for every G.x
• G.Core:4.2.1 - GCoreLinkageManifest (canonical shape)
• G.Core:4.2.2 - GCoreConformanceProfileId catalogue (compression primitive)
• G.Core:4.2.3 - GCorePinSetId catalogue (compression primitive)
• G.Core:4.3 - RSCR Trigger Catalogue and docking discipline
• G.Core:4.3.1 - Definitions
• G.Core:4.3.2 - Governing-definition model
• G.Core:4.3.3 - Authoring rules
• G.Core:4.3.4 - Seed canonical catalogue (Phase‑2 minimum)
• G.Core:4.3.4.1 - Canonical kind definitions (normative, minimal)
• G.Core:4.3.4.2 - Canonical trigger sets (compression primitive)
• G.Core:4.3.5 - Initial alias maps
• G.Core:4.4 - Default Governing Definition Index
• G.Core:4.4.1 - Definitions
• G.Core:4.4.2 - Rules
• G.Core:4.4.3 - Seed Default Governing-definition assignment entries (Phase‑2 minimum)
• G.Core:4.5 - ID continuity protocol (Δ‑discipline)
• G.Core:4.6 - Explicit non-goals
• G.Core:5 - Archetypal grounding
• G.Core:6 - Bias-annotation (informative)
• G.Core:7 - Conformance checklist (normative) — CC‑GCORE
• G.Core:8 - Common anti-patterns and how to avoid them
• G.Core:9 - Consequences
• G.Core:10 - Rationale
• G.Core:11 - SoTA alignment (informative)
• G.Core:12 - Relations
• G.Core:End
• G.0:End
• M1 — CG‑FrameContext Card (scope anchor)
• M2 — SoTA_Set@CG‑Frame (harvester output card)
• M3 — VariantPool (candidate inventory + emitter trace)
• M4 — Shortlist (selector/assurer output)
• M5 — CG‑FrameLibrary (published bindings index)
• M6 — RefreshReadiness Card (telemetry hooks + wiring)
• GPatternExtension — G.1:Ext.HarvesterWiring
• GPatternExtension — G.1:Ext.ShortlistWiring
• GPatternExtension — G.1:Ext.CreativityCHR
• GPatternExtension — G.1:Ext.NQD
• GPatternExtension — G.1:Ext.OpenEndedFamilyWiring
• GPatternExtension — G.1:Ext.RefreshWiring
• GPatternExtension — G.1:Ext.ShippingWiring
• G.1:End
• G.2:End
• G.3:End
• G.4:End
• G.5:End
• G.6:End
• G.7:End
• G.8:End
• G.9 — Parity and Benchmark Harness
• G.9:0 — Use this when
• G.9:0.1 — What goes wrong if missed
• G.9:0.2 — What this buys
• G.9:1 — Intent
• G.9:2 — Problem frame
• G.9:3 — Forces
• G.9:4 — Solution
• G.9:4.0 — G.Core linkage (normative)
• G.9:4.1 — Objects and publication records
• G.9:4.2 — Parity planning (design‑time / WorkPlanning)
• G.9:4.3 — Execution protocol (run‑time / selector‑adjacent)
• G.9:4.3a — Worked parity slice
• G.9:4.3b — Conditional causal method rung parity
• G.9:4.9 — Extensions (pattern‑scoped; non‑core)
• G.9:5 — Interfaces (minimal I/O; conceptual)
• G.9:6 — Conformance Checklist (CC‑G9)
• G.9:7 — Anti‑patterns and remedies
• G.9:8 — Archetypal grounding (informative; SoTA‑oriented)
• G.9:9 — Cited Records (what this pattern publishes)
• G.9:10 — Relations
• G.9:11 — Working reading checks
• G.9:End
• GPatternExtension — G.10:Ext.QDArchiveShippingPins
• GPatternExtension — G.10:Ext.OEEShippingPins
• GPatternExtension — G.10:Ext.InteropCitation
• G.10:End
• G.11:Ext.LegacyTriggers
• G.11:Ext.DecayAndDebt
• G.11:Ext.QDRefreshWiring
• G.11:Ext.OEERefreshWiring
• G.11:End
• G.12 — DHC Dashboards (Discipline‑Health time‑series; admissible telemetry; generation‑first)
• G.12:1 — Intent
• G.12:2 — Problem frame
• G.12:3 — Forces
• G.12:4 — Solution — Compute and publish DHC series admissibly, with RSCR-ready telemetry
• G.12:4.0 — G.Core linkage (normative)
• G.12:4.1 — Objects (LEX heads; twin‑register discipline)
• G.12:4.2 — Method‑of‑Obtaining Output (generation‑first; design‑time → run‑time)
• G.12:4.9 — Extensions (pattern‑scoped; non‑core)
• G.12:Ext.SoTAPalette — SoTA palette & DHC alignment hooks (optional)
• G.12:Ext.PortfolioTelemetry — selector set-result integration panel
• G.12:Ext.QDTelemetry — illumination / archive telemetry panel
• G.12:Ext.OpenEndedTelemetry — open‑endedness / transfer telemetry panel
• G.12:Ext.MaturityLadderPanel — maturity ladder view (optional)
• G.12:Ext.PackInclusion — shipping inclusion stub (optional)
• G.12:Ext.ViewFamilySeed — advanced view families (Phase‑3 seed; governing pattern TBD)
• G.12:5 — Interfaces (conceptual; kit surface)
• G.12:6 — Conformance checklist (CC‑G12, normative)
• G.12:7 — Bias‑Annotation (informative)
• G.12:8 — Consequences
• G.12:9 — Relations
• G.12:10 — Author’s quick checklist
• G.12:11 — Worked micro‑examples (informative; SoTA‑oriented)
• G.12:End
• G.13:End

#Part H – Glossary & Definitional Pattern Index

• Part H – Glossary & Definitional Pattern Index

#Part I – Annexes & Extended Tutorials

• Part I – Annexes & Extended Tutorials
• I.2:End

#Part J – Indexes & Navigation Aids

• Part J – Indexes & Navigation Aids
• Mandatory replacement map for measurement terms
• Temporal claim lexical debt from C.27
• Migration debt from A.2.6 (Scope, ClaimScope, WorkScope)
• Deprecations (normative)
• Affected locations and required edits (normative)
• Migration playbook (informative)
• Alias and body-prose continuity (informative)
• Change Log (normative migration record)

---

Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)