FPF Reference

    From Flat Documents To Multi-View Truth

    Preface node heading:from-flat-documents-to-multi-view-truth:893

    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 thing under concern;
    • a description is a reviewable knowledge object, or episteme, that describes it;
    • a view is a selected presentation of description material for a concern;
    • a viewpoint states the concern and selection discipline behind a view;
    • 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 thing 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. A vector representation, solver model, graph, natural-language summary, and human-readable pattern can all be treated as descriptions or views when their relation to the project thing, source, viewpoint, and reliance boundary is declared. The question is not whether one carrier is more "real" than another. The question is what claim the publication can responsibly carry.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)