FPF Reference

DevOps Lexical Firewall

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

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.

Keywords

  • lexical firewall
  • jargon
  • tool-agnostic
  • conceptual purity
  • DevOps
  • CI/CD
  • yaml.

Relations

E.5.1refinesFour Guard-Rails of FPF
E.5.1outline parentFour Guard-Rails of FPF
E.5.1outline next siblingNotational Independence

Content

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

ForceTension
TimelessnessConcepts must survive tool turnover.
Pedagogic clarityExamples need concreteness ↔ too much concreteness hard‑codes technology.
Cross‑domain reachPhysical‑system engineers and knowledge‑theorists use different stacks.

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)

ScenarioU.System exampleU.Episteme example
Normative text“A system boundary must expose at least one conserved‑quantity flow.” (No mention of modelling language.)“An episteme records its F–G–R assurance tuple.” (No mention of proof syntax.)
Illustrative linkA modelling profile resides in the Tooling family; Core cites it as “the reference system‑profile”.A linting routine lives in Tooling; Core cites it as “the reference episteme‑checker”.

Conformance Checklist

IDRequirement
CC‑LFW.1A Core pattern SHALL fail review if it contains implementation‑specific tokens.
CC‑LFW.2References to executable artefacts MUST use conceptual names, not file paths or command strings.
CC‑LFW.3Pedagogical examples inside Core MAY describe behaviour, but MUST NOT embed code snippets.

Consequences

BenefitsTrade‑offs / Mitigations
Core stays evergreen and cross‑domain.Authors must relocate concrete examples to Tooling or Pedagogy.
Reviewers can machine‑scan for banned tokens.Requires a small vocabulary allow‑list; maintained in Tooling Guide.

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