fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 110127–110139

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 15:41:27 UTC · snapshot created 2026-10-03 15:43:46 UTC · last check 2026-10-03 16:00:20 UTC

F.14:10.1 - Requester and approver

Candidate family: RequesterSystemRole, ApproverSystemRole, RequestApproverSystemRole, SeniorApprover.

Premise: the local practice has already admitted RequesterSystemRole and ApproverSystemRole as exact local system-role kinds under A.2 with C.3. If that independent basis is absent, the case returns two candidates whose kind status is unresolved; the spellings do not admit them.

Result after that premise:

  • Reuse the two admitted kinds and keep separate SystemRoleKindDescription epistemes only when descriptions are needed.
  • RequestApproverSystemRole is blocked as a fused kind. Use an A.2.7 bundle relation when the two kinds travel together.
  • If the same holder must not carry both assignments in the same change window, use the A.2.7 incompatibility relation. Recover the two assignment occurrences through A.2.1 and any applicable A.2.5 currentness condition. Use F.6 only if a separate claim says that dated Work was performed under one of them.
  • SeniorApprover is not proof of independence or assurance. Recover the intended local system-role kind, exact assignment-state predicate or relation, capability, assurance, or policy claim before durable naming.