FPF Reference

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

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

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 + route:

  • Utterance: signature/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/exclusions). (Name the committing role; do not say “the API commits”.)
  • E: evidence expectations: audit/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 + route:

  • Utterance: published interface spec (pinout, electrical ranges, handshake procedure).
  • L: electrical invariants / 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/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.