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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 13:05:11 UTC

E.17:5.2 - Declared publication-face kind values at Part E

Part E restricts exact publication-face kind values to the literals publication face/form and interop publication form. PlainView, TechCard, InteropCard, and AssuranceLane are face designators, not additional U-kinds or automatic U.View memberships.

USM linkage (normative when exact scope identity is current). An ordinary face first states its bounded use. When that bound must be cited, exchanged, compared, or relied on independently, identify U.PublicationScope under A.2.6. For a face selecting episteme E, PublicationScope(face_E) ⊆ ClaimScope(E). For a face selecting a capability-description episteme about C, PublicationScope(face_C) ⊆ WorkScope(C). Neither inclusion grants permission to perform work or proves that work occurred. A cross-context semantic claim separately retains its F.17 endpoint senses, F.9 Bridge, bounded-use claim, and any current A.10 or B.3 reliance result. An optional F.9 CL summarizes evidence strength; it is not a relation or use condition.

Publication-face naming discipline.

  • The exact publication-face kind values remain publication face/form and interop publication form.
  • Concrete face designators end in …View, …Card, or …Lane only within this family; the suffix does not establish kind membership.
  • PlainView is a historical face name, not a U.View claim. Use U.View only for an episteme that passes E.17.0 conformance.
  • AssuranceLane can expose evidence bindings or pins, but it is not an assurance claim, evidence-sufficiency result, confidence verdict, gate, or release permission.
  • carrier, bearer, and holder retain their exact carrier or relation meanings and do not name a view or publication entity.
  • Any legacy ViewFamilyId token is only the ordinary family designator used to retrieve one local E.17.1 declaration claim block inside an exact catalogue episteme edition; it is not a local id kind, U.View, U.Viewpoint, bundle-membership rule, or face kind.

Profiles select only needed faces.

  • MVPK-Min: one selected face, normally a PlainView or TechCard-Lite, for one current reader/use. No assurance or interoperability face is implied.
  • MVPK-Lite: the minimum two or more faces needed by current readers; add AssuranceLane-Lite only for a real evidence-facing use and InteropCard only for an exact external consumer.
  • MVPK-SetReady: add the faces and pins required for replayable or external interchange; concrete exchange formats remain outside Part E.
  • MVPK-Max: use all four designators only when all four reader/use obligations are current. It is not the default completeness target.
  • A -Lite face removes optional fields only, never claims. Enrichment adds fields or pins without retracting, widening, or strengthening the source claim.