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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 16:02:47 UTC · snapshot created 2026-10-03 16:03:51 UTC · last check 2026-10-03 16:50:10 UTC

C.22.2:20.1b - Card/PFR Cardinality Replay

Every PFR reference below designates a world-side occurrence established under C.22.PFR; no card-side fact supplies its participants, adverse extent, or identity. PFR-InspectionAssignment-17 and later PFR-InspectionAssignment-18 are the two Robot-7 occurrences replayed in C.22.PFR:5.

For the unrelated branch, InspectionReleaseAssignment is a declared U.SystemRoleAssignment species. Occurrence InspectionAssignment-27 has admitted System Robot-8 as holder and local kind InspectorSystemRole as assigned-kind value. It obtains without interruption on [2026-07-13T10:00, 2026-07-13T10:30]; MaintenanceRoles-2026, Maintenance-Scheme-A, and the interval description interpret or describe the assertion but are not extra assignment participants.

Robot8ReleaseCriterionApplicability-4 uses predicate NoInspectorSystemRoleBeforeValidation-v2, maps the occurrence’s assigned-kind participant to the adverse nominal coordinate and its holder to Robot-8, and names Robot-8, its release ClaimScope, and [2026-07-13T09:30, 2026-07-13T12:00] as the other applicability participants. Those facts establish PFR-InspectionAssignment-27 on [2026-07-13T10:00, 2026-07-13T10:30] under C.22.PFR.

BranchExact card-side objectsMechanically recoverable result
One joint multi-PFR cardRobot7ReleaseEpisodesCard-E1 = <CG-Robot7-ReleaseEpisodes-E1, Robot-7, Maintenance-Scheme-A>. The exact ClaimGraph contains two affirmative assertion nodes designating PFR-InspectionAssignment-17 and PFR-InspectionAssignment-18. A.1 independently identifies Robot-7 : U.System, and both PFRs have that same System as their applicability-derived problem-for entity.One ClaimGraph has one direct, genuinely joint EntityOfConcern, so one card carries both PFR references. The card records two occurrences; it does not merge them.
Unrelated PFRs force splitProposed CG-Mixed-RobotReleaseProblems-E0 contains PFR-InspectionAssignment-17 about A.1-identified Robot-7 and PFR-InspectionAssignment-27 about separately A.1-identified Robot-8. No direct pattern in this replay identifies one joint EntityOfConcern for those claims; a list of the two Systems is not one.E0 cannot constitute one ProblemCard. Split it into CG-Robot7-ReleaseProblem-E1 in Robot7ReleaseProblemCard-E1 and CG-Robot8-ReleaseProblem-E1 in Robot8ReleaseProblemCard-E1, each with its own exact System EntityOfConcern and effective scheme.
Several cards retain one PFRRobot7SafetyCard-E1 = <CG-Robot7-Safety-E1, Robot-7, RobotSafety-Scheme-A> qualifies its designation by SafetyAssuranceViewpoint-E1 and receiving use AutonomousInspectionReleaseReview-E1. Robot7StaffingCard-E1 = <CG-Robot7-Staffing-E1, Robot-7, MaintenancePlanning-Scheme-B> qualifies its designation by MaintenancePlanningViewpoint-E1 and receiving use InspectionAssignmentRepairPlanning-E1. Both exact ClaimGraphs designate PFR-InspectionAssignment-17.The differing ClaimGraphs, schemes, viewpoints, and receiving uses identify or qualify two cards and their claims; the PFR reference remains exactly PFR-InspectionAssignment-17. Revising, merging, splitting, publishing, or replacing either card changes no PFR participant or adverse episode.