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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 05:50:20 UTC

C.30.AD:1 - Problem frame

Architecture practice needs descriptions that remain useful over time: multi-view documents, view models, generated relation graphs, transformation-flow views, control sketches, module or interface diagrams, deployment views, model cards, system cards, and architecture-decision description sets. Teams use them to compare, reuse, refresh, and inspect architecture claims. If a project also claims a system-role assignment, Work attribution, authority, or responsibility, keep that as a separate claim: use A.2.1 for assignment, A.15.1 for Work admission, and F.6 only for assignment-bound Work attribution; use an admitted domain relation for authority or responsibility, or return an A.6.RCD missing governor if a rule needed to state or test that claim is absent. VP.AllocationResponsibility is only a clue to the concern.

A description is not the architecture, an architecture relation that actually holds, or the selected structure. The same holon or relation occurrence can have several descriptions, and a description set can contain several separately identified epistemes. A description counts as U.View only while the E.17.0 conformance relation actually holds between that same episteme and one viewpoint episteme. Different views can hide, lose, coarsen, or emphasize different structures: for example functional, flow, control, module, interface, placement, information-custody, evidence-reuse, assurance, or scale structure.

The first-minute practitioner can ask:

  • What holon, obtaining ArchitectureRelation occurrence, or selected structure is this description about?
  • Which ClaimGraph, EntityOfConcern, and reference scheme identify the description?
  • Which structures and structure kinds does it describe?
  • If it is called a U.View, which viewpoint and which conformance relation make that true?
  • What claim or relation connects it to architecture claims and other views without pretending that proximity creates correspondence?
  • Which sources, representations, or publications enter this use, by what path, and when must stronger use return to a source?
  • After using the description, what architecture move remains admissible?