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

Preface node heading:show-1-u-system-effectful-api-boundary-algebraic-effects-intuition:9151

#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

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.
  • Transport: HTTP headers, idempotency key transport, canonical currency conversions.
  • Audit and observability: specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their semantics (fields, correlation IDs, retention class).

• Actual occurrence and work layer.

  • The payment-handling occurrence is U.Work only when its admitted performer system, covering assignment, enacted method, time, and containing system are grounded through A.15.1.
  • 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/causal owner. 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).

SoTA tie‑in: This boundary is naturally understood using algebraic effects and handlers: the signature is the “operation interface” (effect signature), while the mechanism or realization provides handlers (semantics). The stack keeps the abstract operation signature stable while allowing multiple handlers and realizations to evolve.

Classification example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency‑Key” belongs in Quadrant D (role-assignment or acting-system obligation) but should reference the same gate semantics to avoid divergence.
• “System emits AuthorizationRecord” belongs in Quadrant E (evidence via carriers).

---

Last Updated: 2026-07-28 — upstream FPF commit 17edd955 (github.com/ailev/FPF)