FPF Reference

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

    Preface node heading:a-6-c-5-3-show-episteme-archetypes:12056

    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

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

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

    Unpack + classify:

    • Description/publication: 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: the protocol description carries generic prescriptions for covered implementers or operators: implement the protocol, do not send messages outside the state machine, and publish conformance records when required. It asserts no individual commitment occurrence.
    • E: admitted system ProtocolConformanceEvaluator-A performed ProtocolConformanceRun-T1 : U.Work over bounded interaction Trace-42. Exact A.6.1 application ProtocolConformanceApplication-T1 has result binding conformanceResult -> ProtocolConformanceResult-T1; that C.2.1 result episteme states conformanceVerdict=pass and observedTerminalState=completed under ProtocolConformanceCriterion-v5. For a disputed interaction, an A.10 path links this result to exact MessageTrace-42, ConformanceRunRecord-T1, and ProtocolAuditRecord-42 carriers.

    (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.
    • Description/publication: SLA publication (and its views for different audiences).
    • A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
    • D: the SLA clause is first a generic prescription for covered providers, clients, and auditors. Claim that actual provider ProviderSystem-A bears the four-hour duty only after the SLA's individualizing rule and required actual basis establish one exact A.2.8 commitment; otherwise keep the clause generic.
    • E: admitted system SLAEvaluator-A performed ResponseEvaluation-Ticket-17 : U.Work over Severity-1 ticket Ticket-17 under the declared clock and measurement method. Exact A.6.1 application ResponseMeasurementApplication-Ticket-17 has result binding responseIntervalResult -> ResponseIntervalResult-Ticket-17; that C.2.1 result episteme states observedResponseInterval=3h42m and withinFourHourTarget=true. When the SLA decision relies on this result, an A.10 path links it to exact ticket, response-timestamp, clock-source, and severity-classification carriers.

    Last Updated: 2026-09-04 — upstream FPF commit d7a71234 (github.com/ailev/FPF)