FPF Reference

Unidirectional Dependency

E.5.3 · 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 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.

Keywords

  • dependency
  • layers
  • architecture
  • modularity
  • acyclic
  • Core
  • Tooling
  • Pedagogy.

Relations

E.5.3refinesFour Guard-Rails of FPF
E.5.3constrainsFPF Artefact Architecture
E.5.3outline parentFour Guard-Rails of FPF
E.5.3outline prev siblingNotational Independence
E.5.3outline next siblingCross-Disciplinary Bias Audit
E.5.3explicit referenceFPF Artefact Architecture
E.5.3explicit referenceLEX-BUNDLE: Unified Lexical Rules for FPF
E.5.3explicit referenceFour Guard-Rails of FPF

Content

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

ForceTension
Agility vs StabilityTooling must iterate quickly ↔ Core must remain slow and deliberate.
Reuse vs IsolationAuthors want to reuse helper concepts ↔ Core cannot depend on volatile code.
SimplicityRule must be testable and unambiguous ↔ must allow legitimate upward imports.

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)

LayerU.System illustrationU.Episteme illustration
CoreDefinition of U.System and boundary invariant.Definition of F‑G‑R assurance components.
Tooling“Reference system‑profile” that checks boundary flow; imports Core invariants.“Episteme‑scoring routine” that calculates R‑score; imports Core characteristics.
PedagogyTutorial using the system‑profile to model a pump; imports profile and Core term.Case study explaining R‑score evolution; imports scoring routine and Core term.
ForbiddenCore pattern importing measurement script.Core pattern importing R‑score web dashboard.

Conformance Checklist

IDRequirement
CC‑UD.1Dependency graph among all artefacts MUST be acyclic.
CC‑UD.2An artefact SHALL import only from its own family or any family above it in the order.
CC‑UD.3A DRR that introduces a downward edge SHALL be automatically rejected.

Consequences

BenefitsTrade‑offs / Mitigations
Core stays free of tool churn and tutorial bias.Authors must create abstraction layers in Tooling instead of inserting hooks into Core.
Release cadence decoupled: Core (slow), Tooling (medium), Pedagogy (fast).Slight duplication when multiple tools target same concept; mitigated by shared Core definitions.

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