FPF Reference

    A.6.C:5 — Archetypal Grounding (Tell–Show–Show)

    Preface node heading:a-6-c-5-archetypal-grounding-tell-show-show:9563

    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

    A.6.C:5.1 — Tell

    If you use contract-language for a boundary, do not treat “the interface or specification” as an acting system. Instead:

    1. Identify the promise content (promise content) being promised,
    2. Identify the accountable Commitment holder(s) (accountable role assignments or admitted acting systems),
    3. Identify the Utterance surfaces that publish the boundary (signature or mechanism descriptions plus MVPK views),
    4. Identify the Performed work and evidence carriers that could adjudicate whether commitments were met,
    5. Classify each claim through L/A/D/E and reference across quadrants rather than paraphrasing.

    A.6.C:5.2 — Show (System archetypes)

    (A) Software API boundary

    Draft wording (contract soup): “The Payments API guarantees idempotency. Clients must provide Idempotency-Key. We log all requests. Availability is 99.9%.”

    Unpack + classify:

    • Utterance: signature or mechanism publication for PaymentsAPI (MVPK faces: TechCard, InteropCard).
    • L: define idempotency and the uniqueness semantics of Idempotency-Key. (“Idempotent” is a semantic property, not a duty.)
    • A: admissibility predicate: request is admissible iff Idempotency-Key is present and valid. (Gate belongs to mechanism.)
    • D: client implementers are obligated to satisfy the gate; provider implementers are accountable for the idempotency behavior as defined in L when the gate holds; provider commits to the availability target (scoped by window and exclusions). (Name the committing role; do not say “the API commits”.)
    • E: evidence expectations: audit and log carriers include request id, idempotency key, rejection reason; availability measurement uses defined window and signal definition.

    (B) Hardware interface boundary

    Draft wording: “The connector guarantees safe operation. Devices must not exceed 20V. Negotiation must succeed before power is applied.”

    Unpack + classify:

    • Utterance: published interface spec (pinout, electrical ranges, handshake procedure).
    • L: electrical invariants and allowable ranges are definitions and invariants (truth-conditional).
    • A: admissibility predicate: power delivery is admissible only after handshake state reaches an agreed mode.
    • D: manufacturer or integrator obligations: implement handshake; enforce voltage constraints.
    • E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

    A.6.C:5.3 — Show (Episteme archetypes)

    (C) Multiparty protocol boundary (behavioural and session-type motif)

    Draft wording: “The protocol guarantees progress. Participants must follow the sequence.”

    Unpack + classify:

    • Utterance: protocol description (could be a type spec or protocol spec plus explanatory views).
    • L: safety and progress properties as laws over the protocol model (truth-conditional, within the theory).
    • A: admissibility: when an interaction trace is considered valid or admissible (e.g., runtime checks; compilation checks; gating conditions for entering a session).
    • D: obligations on implementers or operators: implement the protocol; do not send messages outside the allowed state machine; publish conformance records if required.
    • E: evidence: message trace carriers, conformance test-run records, and audit trails for disputed interactions.

    (D) Socio-technical “SLA + audit trail” boundary

    Draft wording: “Provider shall respond within 4 hours for Severity‑1 incidents. Only Severity‑1 is covered. Evidence is provided by ticket logs.”

    Unpack + classify:

    • Promise content (service promise clause): responsiveness promise for a defined incident class and window.
    • Utterance: SLA publication (and its views for different audiences).
    • A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
    • D: provider commitment to meet the target; client duties (e.g., provide required info); auditor duties if applicable.
    • E: evidence: ticket carriers, timestamps, classification records, and the measurement procedure binding “4 hours” to a time window and clock source.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)