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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 09:30:10 UTC

A.6:1 - Problem frame

Boundaries are where architecture lives: at the edge of a theory, an API, a protocol, a hardware connector, an organisational interface, or a published model. FPF already has the core building blocks to describe such edges:

  • U.Signature as a public, law‑governed declaration (with Vocabulary, Laws, Applicability).
  • U.Mechanism as a reusable operation declaration with OperationAlgebra, LawSet, AdmissibilityConditions and Applicability.
  • Multi-view describing through E.17.0 MultiViewDescribing, plus separate E.17 publication discipline for selected epistemes, face uses, forms, and carriers.
  • Recover each claim’s EntityOfConcern separately from its claim-bearing Description episteme and any publication carrier. The concern may itself be an episteme or carrier; its position does not establish agency, Work, evidence, or a decision.

Yet boundary descriptions in practice fail in a predictable way: authors blend several fundamentally different kinds of claims into one undifferentiated contract paragraph. The result is brittle architecture: signatures become entangled with runtime gates, deontic language is mixed into mathematical invariants, and “effects” are asserted without any disciplined carrier and evidence story.

This cluster overview makes one disciplined move:

  1. Treat a boundary as a stack of boundary layers (Signature → Mechanism → actual occurrences and their separately governed consequences/evidence) plus publication views and faces, and
  2. Provide a boundary discipline matrix (2×2) that classifies statements by boundary layer, so evolution remains controlled and substitutions are possible.

Terminology note (informative): In this pattern:

  • Layer names a stratum in the boundary stack (Signature → Mechanism → actual occurrences, separately governed consequences/evidence → Publication).
  • View (U.View) is the same C.2.1 episteme individual when E.17.0 conformance to at least one exact viewpoint episteme obtains; it is not a projection operation, publication file, or document.
  • Viewpoint (U.Viewpoint) is the same C.2.1 episteme individual when the fixed E.17.0 viewpoint-convention conditions obtain; its accountability use does not replace those membership conditions.
  • Face (MVPK sense) is a publication form for a bounded reader/use. PlainView, TechCard, InteropCard, and AssuranceLane are face designators, not additional publication-face kind values. A face may expose an episteme that independently has U.View membership; the form, rendering and carrier remain separate from that episteme.