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

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 07:05:20 UTC

A.6:5 - Archetypal Grounding (Tell–Show–Show; System / Episteme)

Informative. Worked examples for learning the L/A/D/E claim-classification discipline; they do not add requirements beyond A.6:7.

Tell (universal rule)

To support boundary evolvability, separate claims across the signature stack and classify each statement as Law, Admissibility, Deontic duty/commitment/grant, or the boundary’s observable-effect/evidence family. An E claim names the exact actual occurrence under its subject predicate and retains the pattern only as a locator: dated Work only when the A.15.1 predicate is satisfied, or A.3/A.3.4 plus the exact interaction or causal predicate for non-Work change. EntityOfConcern, description, and publication carrier remain separate.

Show #1 (U.System): effectful API boundary (algebraic effects intuition)

System: A “Payment Authorize” service.

  • Signature layer (A.6.0).

    • Vocabulary: PaymentRequest, AuthDecision, MerchantId, Money, etc.
    • Laws: e.g., “If decision is APPROVED then reservedAmount = requestedAmount” (truth‑conditional).
    • Applicability: bounded context “Payments Authorization”.

  • Mechanism layer (A.6.1).

    • Admissibility gate: request is admissible iff tokenValid ∧ merchantActive ∧ amountWithinLimit.
    • Boundary transport details: HTTP headers and idempotency-key carriage. Declare canonical currency-conversion operations under A.6.1.
    • The local Audit and observability section specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their fields, correlation IDs and retention class. Retention duties remain D-claims.

  • Actual occurrence and work layer.

    • The payment-handling occurrence is U.Work only when its exact actual performer first has the A.13 core and A.15.1 independently admits the occurrence from its Method, time, containing System, and other required direct facts. If this payment account also asks under which assignment the performer acted, add F.6 through the same obtaining A.13 assignment; missing or failed attribution leaves the payment Work intact.
    • The ledger reservation change, event emission, timer transition, or retry effect is a separate actual-occurrence claim under A.3/A.3.4 or its exact interaction or causal-use pattern. Check each effect separately: knowing that the payment Work occurred does not show that the ledger changed, an event was emitted, or a retry happened.
    • Traces, logs, and metrics enter an A.10 evidence path for the exact effect being relied on; carrier presence creates neither Work nor change.

  • Publication faces (MVPK).

    • PlainView: narrative for stakeholders (what the service promise is, in plain terms).
    • TechCard: signature or mechanism details (types, error codes, version policy, admissibility predicate refs).
    • InteropCard: machine‑exchange oriented boundary details (canonical field names, schema refs, transport bindings).
    • AssuranceLane: evidence bindings (which carriers exist, how to adjudicate E-* claims, retention and access duties by reference).

Effects-and-handlers analogy. In this software example, the signature exposes the operation interface. A.6.1 governs declared operation semantics and the separate realization relation; the realizing entity supplies the concrete handler implementation. Implementations can change while preserving the declared operation meanings and applicable constraints.

Classification example:

  • “A request is admissible iff tokenValid ∧ merchantActive ∧ amountWithinLimit” belongs in Quadrant A (the declared admissibility gate).
  • “Clients MUST include Idempotency-Key” belongs in Quadrant D as a normative prescription and should reference the same gate semantics to avoid divergence. It becomes a claim about one obtaining individual U.Commitment only after A.2.8 identifies the actual bearer, constitutive rule, required instituting basis, and direct predicate.
  • “System emits AuthorizationRecord” belongs in Quadrant E (an actual event-emission claim).

Show #2 (U.Episteme): published evaluation protocol boundary (multi‑view + evidence)

Episteme: A published “Model Evaluation Protocol” for a safety‑critical classifier.

  • Signature layer: names operations such as Evaluate(model, dataset) → Report and states metric definitions (AUROC, calibration error) as Laws. A.6.1 governs the corresponding operation declaration and its argument/result meanings.

  • Mechanism layer: admissibility gate encodes when evaluation is permitted: dataset version must match declared license; measurement environment must meet constraints; seeds pinned.

  • Deontics and commitments: the protocol may prescribe that reviewers use dataset vX.Y and that authors publish MVPK faces and cite the measurement environment. If an organisation has an individual review-SLA duty, identify that actual admitted System or other A.2.8 party as bearer and establish the direct U.Commitment predicate. Any system-role classification or assignment remains a separate possible applicability ground.

  • Effects and evidence: the dated evaluation run is a Work occurrence only when A.15.1 grounds it; its result episteme, any model or dataset change, and the report publication remain separate. Report files, logs, hashes, and trace IDs support the selected claims through A.10 but create none of those occurrences or results.

Non-Work E contrast. A seedling’s spontaneous first-leaf unfolding can be an actual A.3.4 transformation with no performer, assignment, method, or Work occurrence. Measurements may support that exact change claim through A.10; neither the observation work nor its carrier becomes the change.

  • Multi‑view (MVPK face designators):

    • PlainView for decision makers: what this protocol means for assurance.
    • TechCard for engineers: metric definitions named by value, admissibility predicates, and a clearly marked Norms-and-commitments section (D‑claims) for governance.
    • InteropCard for exchange-oriented consumers: conceptual field names, anchors, and schema references.
    • AssuranceLane for auditors: evidence map (which carriers support which occurrence claims) and adjudication steps keyed by E-* IDs.

This episteme is a boundary because it mediates between theory (“metric definitions”) and work (“a run produced a report”). The signature stack provides the stable interface for that mediation.