FPF Reference

Notational Independence

E.5.2 · Stable · Part E - The FPF Constitution and Authoring Guides

About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a fpf-memory product feature page.

How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

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.

Keywords

  • notation
  • syntax
  • semantics
  • tool-agnostic
  • diagram
  • UML
  • BPMN.

Relations

E.5.2refinesFour Guard-Rails of FPF
E.5.2outline parentFour Guard-Rails of FPF
E.5.2outline prev siblingDevOps Lexical Firewall
E.5.2outline next siblingUnidirectional Dependency

Content

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

ForceTension
ExpressivenessDiagrams and formal grammars aid precision ↔ they should never become the definition itself.
LongevityA 20‑year horizon ↔ notation life‑cycles of 3‑5 years.
Cross‑discipline adoptionMathematicians prefer algebraic syntax; engineers prefer schematics.

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)

ScenarioU.System exampleU.Episteme example
DefinitionBoundary of a pump is expressed in prose plus set notation; a diagram is illustrative.F‑G‑R assurance components defined textually; a triple‑store serialisation is illustrative.
Alternate renderingSame pump semantics rendered in a lattice diagram or a tabular sheet remain valid.R‑scores plotted in a heatmap or listed in CSV remain equivalent.

Conformance Checklist

IDRequirement
CC‑NI.1A Core pattern MUST NOT embed semantics that hinge on one specific notation.
CC‑NI.2Illustrative renderings SHALL be marked “informative”.
CC‑NI.3When multiple official renderings exist, the pattern MUST declare the semantic mapping between them.
CC‑NI.4If a conceptual prefix appears in Core, its expansion (if shown) SHALL be marked informative and MUST NOT be required to interpret the semantics.

Consequences

BenefitsTrade‑offs / Mitigations
Ensures FPF survives notation turnover.Authors invest time describing mappings; mitigated by reusable mapping templates.
Lowers entry barrier for domains using different diagram traditions.Excessive illustrations can bloat pages; guidance in Pedagogical Companion limits scope.

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