FPF Reference

    FPF.Preface:12 - From Flat Documents To Multi-View Truth

    Preface node heading:fpf-preface-12-from-flat-documents-to-multi-view-truth:1079

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    Traditional document practice often treats one file as "the truth". Contemporary projects rarely fit that shape. A product, organization, architecture, safety case, research program, model, or AI-agent arrangement may need many descriptions for different concerns.

    FPF separates the pieces:

    • the EntityOfConcern is the project entity under concern;
    • a description is a reviewable knowledge object, or episteme, that describes it;
    • a view is an identified episteme that conforms to the fixed rules of an identified viewpoint (E.17.0);
    • a viewpoint states the concerns and fixed rules used to judge that conformance;
    • a publication form makes a description, view, card, record, table, or dashboard available for use;
    • a carrier is the physical or digital rendering or storage that makes the publication form available;
    • a reliance boundary says what the publication may responsibly be used for.

    This is why a diagram is not the architecture, a dashboard is not evidence by itself, a model card is not model safety, and a generated explanation is not the system it explains. They can all be valuable, but each has a kind and a relation.

    Multi-view publication is therefore a strength, not a defect. A safety case, architecture description, dashboard, model card, evidence graph, and management summary may all concern the same project entity under different viewpoints. FPF's job is to keep them connected without letting one view silently replace another.

    This is also how FPF can work with distributed and AI-generated representations. For a vector representation, solver model, graph, natural-language summary, or human-readable pattern, identify the claim-bearing episteme and its relation to the project entity. That episteme may be a description under E.10.D2; it is a view only when it conforms to the fixed rules of an identified viewpoint under E.17.0. Recover the source and the relation involved only when the current use depends on a claim about source use, derivation, or construction. Keep its publication and reliance boundary separate from those recognition conditions. The question is what claim the publication can responsibly carry.

    A narrative or explanatory rendering is one such publication shape. Its source relation remains inspectable when it states what selected source structure it used, what it preserved, what it deliberately coarsened, abstracted, omitted, or lost, which viewpoint it uses, the source-return condition, and any unresolved neighboring assertion with its subject-pattern locator. If the rendering begins from an architecture description or view, that source basis may already be a coarsened account of actual, expected, or candidate structures; the rendering keeps that earlier loss visible. Narrative readability does not turn a rendering into evidence, assurance, permission, architecture, or the described object itself.

    Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)