fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 94426–94457

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 16:02:47 UTC · snapshot created 2026-10-03 16:03:51 UTC · last check 2026-10-03 16:25:20 UTC

E.17.1:15 - Worked family shapes, not shipped catalogue values

E.17.1:15.1 - Hypothetical TEVB project binding

E.17.2 supplies an authoring template, not a repository-shipped family. One project may constitute exact catalogue L and bind four local variables:

  • r_functional -> P_functional,
  • r_procedural -> P_procedural,
  • r_allocation -> P_allocation,
  • r_module -> P_module.

Only after those are exact U.ViewpointRef values resolving exact admitted P editions under L’s effective scheme can the project’s ordinary family designator retrieve a reusable local declaration. Another project with similarly spelled variables or labels has not imported this family unless it resolves the same exact L and references.

E.17.1:15.2 - Hypothetical governance and risk shape

A project may author a governance-oriented declaration with local reference variables such as:

  • r_risk -> P_risk,
  • r_control -> P_control,
  • r_compliance -> P_compliance,
  • r_operations -> P_operations.

This is an example of a possible declaration shape, not an exact current family. Each left-hand variable must be bound to an exact local U.ViewpointRef; each right-hand variable must be bound to one exact P independently admitted under E.17.0; and exact L, R_L, and the family designator must exist before reusable import is claimed. The four positions recur together but remain non-interchangeable.

E.17.1:15.3 - Hypothetical research-method shape

A project may likewise consider local variables r_theory, r_experiment, r_inference, r_limitations, and, where appropriate, r_reproducibility. This list teaches a candidate family shape only. A local inquiry note can import a subset only after the project has constituted exact L, bound each retained variable to an exact reference and P, and made omitted members visible in one actual declaration claim block.

E.17.1:15.4 - Cross-family description relation positions

A serious project may use one materialized local TEVB instance for its design family, another exact local governance family for program oversight, and another exact local publication-oriented family for publication faces and forms. E.17.1 keeps these relation positions reviewable by preserving which exact catalogue and declaration each viewpoint came from and by preventing a final publication face or form from masquerading as the catalogue itself.