FPF Reference

From Flat Documents to High-Dimensional Truth: The Multi-View Architecture

Preface node heading:from-flat-documents-to-high-dimensional-truth-the-multi-view-architecture:572

Content

Classical semiotics gave us the Semantic Triangle: Symbol, Concept, Object. It was a useful approximation for a paper-based world where a blueprint was physically distinct from the machine it described. For contemporary systems engineering, computational discovery, and AI-augmented management, that Triangle is a flatland map for a multidimensional territory. It collapses distinctions we now need to keep sharp: it confuses the view with the viewpoint, the carrier with the content, and the projection with the reality.

First Principles Framework (FPF) replaces this flat geometry with a topological architecture for knowledge. A complex U.System—whether a nuclear plant, a corporate strategy, or a causal model—cannot be captured by a single “truth document”. It is described by a family of connected epistemes (U.Episteme), each rigorous, each partial, and each obtained from the others by law-governed morphisms rather than copy-and-paste edits.

The Episteme as a Slot Graph, Not a Point In FPF, an episteme is not a static node. It is a structured Episteme Slot Graph (U.EpistemeSlotGraph, C.2.1). It has explicit slots for what it describes (DescribedEntity), where it is grounded (GroundingHolon), and through which lens it is seen (Viewpoint). This moves us beyond the naive “map vs territory” debate into a disciplined treatment of epistemic morphisms:

  • engineering views are not separate files to be synchronised manually; they are structure-preserving projections (U.EpistemicViewing, A.6.3) of a shared underlying DescribedEntity;
  • retargeting—moving from a physical description to a functional one, or from data to a model—is a formal, effect-free operation (U.EpistemicRetargeting, A.6.4) governed by bridges and invariants, not by “creative writing”.

Multi-View Describing vs Publication (MVPK) Engineers and managers often mistake the act of publishing (making a PDF, updating a dashboard) for the act of describing. FPF enforces Strict Distinction here (A.7, E.10.D2). U.MultiViewDescribing arranges families of descriptions and specifications under engineering viewpoints; the Multi-View Publication Kit (MVPK, E.17) sits on top and treats publication as a typed, functorial projection from those morphisms to human-facing surfaces.

A “Safety Case” and a “System Architecture” are not competing documents; they are two valid views of the same holon, rendered under different viewpoints and onto different surfaces. When a manager looks at a red/green dashboard, they are looking at a U.View (an U.EpistemeView), mathematically derived from underlying Work and EvidenceGraph lanes via a declared U.Viewpoint and PublicationScope. As long as that correspondence is maintained, the report cannot drift away from the reality it summarises without tearing the audit trail.

Supporting State-of-the-Art (SoTA) This multi-view architecture is designed for the age of the Bitter Lesson. Modern AI and solver-based workflows do not “think in documents”; they operate on latent representations, graph embeddings, and formal constraints. FPF’s multi-view kernel lets us treat a neuro-symbolic embedding, a solver model, and a human-readable specification as three views of the same episteme, linked by declared correspondences. It turns the “black box” of AI into a named component of a multi-view description, where we can rigorously ask: under which viewpoint(s) is this output admissible, and over which ClaimScope (G)?

By treating description as a graph of typed projections rather than a pile of files, FPF gives the Engineer tools to keep views coherent, the Researcher tools to trace provenance across viewpoints, and the Manager justified confidence that dashboards and reports are lawful views of the territory, not parallel worlds.