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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 13:50:10 UTC

A.15:4.1 - Core entities kept distinct

  • Exact local system-role kind. A value such as InspectorSystemRole : U.Kind is admitted under A.2 with C.3 through its U.System candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule. It is not a system, assignment, relation slot, capability, Method, Work, responsibility, or authority. A system classification judgment and an assignment occurrence are separate claims.
  • U.SystemRoleAssignment. This is the relation family consumed by A.15 and F.6. It has no permissive root RelationSignature. Each direct species declares HolderSystemSlot : U.System, a declaration-local AssignedSystemRoleKindSlot whose ValueKind is one exact local system-role-kind domain, its predicate and applicability, every real additional participant, and its occurrence-identity rule.
  • U.Method. The run-independent semantic way of doing. A Work occurrence can stand in enactsMethod(W, M); the Method does not act.
  • U.MethodDescription. An already identified U.Episteme whose exact EntityOfConcern is an admitted Method and whose substantive claims say how that Method is done, as judged by A.3.2. Wording, file form, or publication alone establishes no membership.
  • Holder capability (A.2.2). The holder’s ability to perform named work under stated conditions and bounds. Its assertion, evidence, currentness assessment and fit to a demand remain separate. Ability establishes neither assignment nor performed Work.
  • U.WorkPlan. A U.Episteme about possible future Work, including intended windows, dependencies, performers, and budgets. It does not bring a future Work occurrence into existence.
  • U.Work. The admitted kind for concrete dated Work occurrences. One Work individual has its own temporal extent, at least one obtaining A.15.1 enactsMethod relation, and at least one obtaining locally declared containing-system relation. It may stand in further enactment, affected-referent, binding, resource-use, production, and result relations when the receiving use needs those independently obtaining facts. Any log, ticket, assertion, description, or performed-work record is a separate episteme.

Work occurrence and record boundary. Do not add a universal primaryTarget field, a local kind field, or an Operational, Communicative, and Epistemic enumeration to Work identity. Recover the exact affected-referent, transformation, speech-act effect, commitment effect, production, delivery, acceptance, or other relation under its direct pattern. Those adjectives can remain recognition cues; they do not define Work subkinds by enumeration.

Didactic note for managers: the chef analogy. ChefSystemRole is one local system-role kind. A kitchen-assignment species defines the holder and assigned-kind positions and adds shift, station, or commission only when it changes the assignment. A particular assignment fills those positions with the chef System, the kind, and any additional value. A cookbook can be a MethodDescription; the chef’s skill can be a capability; a WorkPlan can schedule cooking; and making one souffle on Tuesday is dated Work. Its temporal and resource-use relations can state the 25-minute extent, eggs, butter, and consumed gas, while a kitchen log remains a separate episteme. A restaurant vocabulary or scheme can help interpret the claims without becoming a participant in every assignment. The cookbook, skill, plan, assignment, and log do not cook.