FPF Reference

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

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

    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:

    • Description/publication: 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: the API policy generically requires covered clients to satisfy the gate and states the provider-side idempotency and availability prescriptions. No individual commitment follows from those clauses alone. If the case claims that ClientIntegrator-A or ProviderSystem-A bears one of those duties, cite that bearer's exact separately instituted A.2.8 commitment. (Do not say “the API commits”. Responsibility, if claimed, needs its own direct relation.)
    • 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:

    • Description/publication: 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: the interface specification's normative section contains generic prescriptions for covered manufacturers or integrators to implement the handshake and enforce voltage limits; it asserts no individual commitment occurrence.
    • E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

    (B-PER) Compact permission replay (only when the permission branch is live)

    Situation: “ReleaseAuthoritySystem, acting as release grantor under assignment ReleaseGrantor-A, approved DeploymentAgent-A, acting under assignment Operator-A, to deploy Release-4711 after preflight.”

    Unpack + classify:

    • Promise content (optional): SVC-RELEASE-4711 states which release artifact eligible consumers are promised; that content establishes no speech act, commitment, grant, deployment Work, result, or delivery.
    • Speech-act Work: ReleaseGrantorAssignment is a declared U.SystemRoleAssignment species. Occurrence ReleaseGrantor-A has admitted System ReleaseAuthoritySystem as holder and the local release-grantor kind as assigned-kind value. That System performs dated Approve occurrence SA-4711 under the assignment. The assignment supplies only the holder and assigned-kind facts used by the policy; it neither performs the act nor supplies authority. Any authority required by ReleaseGrantPolicy must obtain independently. Under the applicable policy, SA-4711 institutes—not merely publishes—grant occurrence PER-4711 only if the A.2.8.PER obtaining conditions hold. Approval text and a register row that names PER-4711 do not establish that fact.
    • D — current grant (A6-AW-NORM-GRANT): ReleaseOperatorAssignment is another declared species. Occurrence Operator-A has admitted System DeploymentAgent-A as holder and covers this window. The grant's beneficiary participant cites that occurrence, and its permitted-action participant is U.EpistemeRef(Deploy-Release-4711). This Claim Register row uses U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context, as its directObjectDesignation. SA-4711, the two assignments, policy, context, scope, and window remain grounds or qualifiers. The model may use this D claim only while the A.2.8.PER conditions make PER-4711 obtain and the row cites the named occurrence, act, and policy; the row itself does not make the grant current.
    • E — weak evaluation alternative (A6-AW-WEAK): if the basis establishes only current absence of prohibition in a sufficiently complete frame, record NonProhibitionFinding@Context; do not promote it to a strong grant or place it in D.
    • A — independent entry predicate (A6-AW-GATE): “deployment is admissible iff PER-4711 currently obtains and preflight is green” is an A-* predicate. It may consume the grant as one condition but is neither the grant nor proof of gate passage.
    • E — actual Work and exercise (A6-AW-EXERCISE): A.13 first recovers admitted System DeploymentAgent-A as the exact actual performer through obtaining assignment occurrence Operator-A of declared species ReleaseOperatorAssignment; A.15.1 independently admits dated U.Work occurrence DeployRun-4711. Because this permission-exercise branch expressly consumes precise assignment-bound attribution, F.6 then relates that already admitted Work through the same assignment and checks holder equality and coverage. The Work must instantiate the action specification inside the grant's scope and window. Only then may PermissionExerciseRelation@Context bind WorkRef(DeployRun-4711) to U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context. The assignment contributes the beneficiary and attribution facts consumed here; it neither classifies the performer, grounds or creates performance, nor performs the Work. Failed F.6 leaves the Work intact but blocks this attribution-dependent exercise branch. Planned work, the approval wording, and preflight alone are not exercise.
    • E — optional result or delivery: if DeployRun-4711 returns ReleaseArtifact-4711, cite the exact A.6.1 result binding or an already governed subject-specific WorkResultRelation; if that artifact is transferred, cite the independently obtaining delivery/transfer relation defined by its subject pattern. Work, result, and delivery do not imply one another.
    • E — evidence (optional): an A.10 path may link the exact grant, Work, exercise, result, or delivery claim to its current carriers for one bounded reliance use. The carriers create none of those objects.

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