Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

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 06:20:20 UTC

A.6:4.1 - Why “stack”: what is stacked, and what “higher and lower” means

This pattern uses stack in the same pragmatic sense as other FPF stacks (e.g., the holonic import stack and other layered disciplines): an ordered set of layers where higher layers are more stable commitments, and lower layers are more volatile realizations and evidence. “Higher” and “lower” provide engineering guidance for evolvability:

  • Higher in the stack = closer to public, reusable boundary intent.
  • Lower in the stack = closer to execution, implementation, and evidence (what is actually done and observed).

The Signature Stack (as used in this cluster) is the ordered family of canonical claim layers for a boundary package. Each of the four claim layers below is a stable canonical placement for one quadrant of statements (L/A/D/E), with a canonical boundary publication form or section that carries those statements:

  1. Signature layer (L: laws or definitions). U.Signature provides the stable declarative boundary: Vocabulary + Laws + Applicability, without runtime gate predicates.

  2. Mechanism layer (A: admissibility gates). U.Mechanism specializes U.Signature through the operation declarations, LawSet, AdmissibilityConditions and Applicability governed by A.6.1. Its admission predicates remain declaration content. Evidence-interface declarations and transport details keep their own claim classification; use A.10 for evidence sources and carriers, and name carrier-producing Work only when that occurrence is claimed.

    Audit vs AssuranceLane (avoid duplication): a boundary’s local Audit and observability section states its evidence-interface declarations: carrier classes and required fields, correlation keys, and exposure interface. Mechanism.AuditObservability below is a local publication-section locator, not an A.6.1 content component. Retention, access, and enforcement are D-claims. A general prescription remains a claim-bearing episteme; one obtaining individual duty cites the exact A.2.8 U.Commitment, its actual bearer, and its direct predicate. A system-role kind or assignment may be an applicability ground but is neither bearer nor commitment. An MVPK AssuranceLane is a publication face for auditors that explains how to adjudicate the evidence interface. Under CC-A.6.6, the AssuranceLane face references those evidence-interface declarations and relevant claim IDs or canonical locations; its explanation preserves their semantics.

  3. Deontic layer (D: duties, commitments, and grants). Put here a general prescription or a claim about an exact individual duty, recommendation-as-duty, prohibition, commitment, or A6-AW-NORM-GRANT. For an individual duty, cite the exact A.2.8 U.Commitment, actual bearer, constitutive rule, required instituting basis, and direct predicate. Test any responsibility claim separately through its domain predicate or return the exact missing governor. Other A6-AW-* claims keep their own placement. Reference related L-*, A-*, or E-* claims by ID or canonical location rather than duplicating their constraints.

  4. Observable-effects and evidence layer (E: Work-Effects & Evidence). E-* is the boundary’s observable-effect and evidence claim family. Each claim names the actual occurrence or evaluated finding under its subject pattern and, when reliance is current, the observation conditions and A.10 evidence path. Name U.Work only after A.13 recovers each exact actual performer and A.15.1 independently identifies the Work, Method, time, and containing System. Add F.6 only when the receiving boundary use expressly consumes precise assignment-bound attribution; its absence or failure leaves the Work intact. A natural, spontaneous, or formal transformation may instead use A.3 and A.3.4. Canonical placement is an Evidence-and-carriers section, typically rendered in AssuranceLane.

  5. Actual occurrences and realizations (outside the description stack). Substitutable realizations are exercised through dated Work only when each actual performer has its A.13 core and A.15.1 independently admits the occurrence. Add F.6 only when the receiving description also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. Work may participate in change, production, speech-act effect, evaluation, or evidence production, but each relation or claim must be established under the pattern that defines or constrains it. A.3 and A.3.4 also admit natural, spontaneous, and formal transformations without a performer, assignment, Method, or Work occurrence.

  6. Publication faces. MVPK selects exact epistemes and publication forms for audience-specific face uses. A selected episteme has U.View membership only when E.17.0 conformance to the exact viewpoint episteme obtains; any A.6.3 source-to-receiving construction remains separate. The face designator, publication occurrence, form, rendering, and carrier are not the U.View.

Observability compatibility note (informative): When specifying evidence carriers and correlation rules, it is often convenient to describe evidence-carrier classes using examples from observability practice: traces and spans, logs and log records, and metrics time-series, with explicit correlation identifiers. Treat these as example carrier schemas and join keys, not as mandatory technology choices.

A.6:4.1.1 - AssuranceLane skeleton (informative)

An MVPK AssuranceLane is a publication face that teaches a specific audience how to adjudicate E-* claims against the relevant evidence carriers, including those produced in Work. It cites the boundary’s evidence-interface declarations and explains them without changing their semantics.

Minimal content (suggested):

  • Scope: boundaryRef, version; viewRef and viewpointRef when view or viewpoint identity matters.
  • Carrier inventory: carrier-class and carrier-schema refs (A.7 Carrier) + where to obtain them.
  • E‑claim map: a table keyed by E-* ID with: measurement conditions, carrierRef(s), join and correlation keys, and a reference to the canonical E-* text that defines pass or fail criteria.
  • Operational policies: references to relevant D-* duties (retention, access control, exposure), without redefining them.
  • Limitations: sampling, redaction, missing signals, expected false negatives and false positives.

No new semantics reminder. An AssuranceLane may explain adjudication informatively, but any new boundary claim first enters its canonical source. A changed permission-looking claim cites its selected A6-AW-* row and subject pattern rather than being introduced inside the face.

Example (conceptual; uses view/viewpoint identity and the additional hypothetical header case in §4.2):

AssuranceLane:
  viewRef: <ViewId>
  viewpointRef: <ViewpointId>
  boundaryRef: <BoundaryId>
  version: <SemVer or revision>
  evidence:
    - E: E-OBS-1
      carrierRefs: [Carrier.AuthorizationRecord, Carrier.AuditLogEntry]
      measurement:
        conditions: "on every request lacking header X (A-AC-1)"
        vantage: "Operator and auditor pipeline"
        correlation: ["traceId", "requestId"]
      adjudication:
        check: "query audit stream for code=NotAdmissible and join to traceId"
        criteriaRef: "E-OBS-1 (pass or fail criteria live canonically in the E-claim)"
      references: [A-AC-1, D-RET-1, Mechanism.AuditObservability]

The absence condition also covers a request that was not rejected. A claim of complete coverage requires the relevant request population to be accounted for separately from individual query joins.

Default placements (quadrant → stack layer / section):

  • L → Signature.Laws (and, where appropriate, mechanism‑local semantic laws; never runtime gates)
  • A → Mechanism.AdmissibilityConditions
  • D → generic prescriptions, individual duties or commitments, recommendations-as-duty, prohibitions, and A6-AW-NORM-GRANT claims at their exact A.2.8 or A.2.8.PER subject pattern
  • E → actual occurrences, evaluated findings, and evidence claims, including A6-AW-EXERCISE, A6-AW-WEAK, A6-AW-CONFLICT, and A6-AW-SOURCE when those claims are current

Related subject rules (informative):

  • A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate and admissibility claims.
  • A.10 / B.3 ↔ E‑quadrant: for an E-* claim used for reliance, recover the A.10 evidence-provenance path and bounded use. A missing path narrows or blocks only the unsupported use. Open B.3 only for an actual named assurance claim about an exact target and assurance use.
  • A.2.3 and F.12 ↔ D/E separation: a U.PromiseContent promise is not evidence; promise acceptance is linked to Work evidence via F.12. A general duty remains normative content, while an obtaining individual duty is one A.2.8 U.Commitment borne by an actual System or other admitted party. Any system-role kind or assignment used to establish applicability stays separate. D-* claims reference A-* and E-* claims by ID or canonical location when needed.

A stack is useful because the intended direction of change is clear:

  • Lower layers (realizations, audit formats, transport mechanisms) are expected to change more frequently and can often evolve without forcing higher‑layer changes, provided higher‑layer commitments remain satisfied.
  • Changes to higher layers are boundary-claim evolution and typically require explicit compatibility reasoning (and therefore explicit versioning and communication).