FPF Reference

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

    Preface node heading:a-6-c-5-2-show-system-archetypes:9575

    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) 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.

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