Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 06:00:20 UTC

A.15.5:5 - Archetypal Grounding - Worked Slices

A.15.5:5.1 - Fixture deformation test

Situation. An accepted cooling-fixture ProblemCard has been carried through E.18.1 into WorkPlan-LAB-043 : U.WorkPlan; that P2W carry-through creates neither readiness nor target Work. Its PlanItem-TEST-043 designates possible future performance planned-fixture-deformation-test-043, classifies the intended work as fixture-deformation testing under the plan’s current scheme, selects FixtureDeformationTestMethod-E2 : U.Method, and relies on FixtureDeformationTestProcedure-E5 : U.MethodDescription only for the setup limits stated in that edition. The plan also carries declaration-local planned-filling rows SFI-043 for specimen and instrument choices, planned resource reservation FixtureBayReservation-043, and intended performer-system and FixtureTestTechnicianSystemRole conditions. The rows have no identity outside this WorkPlan. None is target test Work.

FixtureTestEntryCriterion-E2 requires, for the proposed start window, a resolved specimen identity, heat-flow invariant claim, boundary-condition plan, sensor-calibration result, selected fixture-drawing edition, resource-availability claim, and fixture-test-technician assignment, all current for this use. The assignment basis is explicit once: FixtureTestTechnicianAssignment is a directly declared U.SystemRoleAssignment species. It defines the holder and assigned-kind positions, uses FixtureTestSystemRoleKindDomain, requires FixtureTestTechnicianSystemRole, and applies to this laboratory test. Its obtaining occurrence FixtureTestTechnicianAssignment-043 has FixtureTechnicianSystem-043 as holder and covers the proposed start window. The A.15.3 rows preserve only the planned specimen and instrument choices. The calibration result, its A.10 evidence path and currentness result, and the E.17 drawing-edition publication use remain separate inputs. The criterion returns notReady when a required input is known to be expired or unresolved; unavailable facts return unknown. Any input revision, assignment gap, resource loss, or start-window change ends reliance and requires recheck.

CalibrationCurrentnessCheck-043 : U.Work was performed by LabMetrologySystem-2 : U.System under obtaining RA-LabMetrology-2-E7, enacted CalibrationCurrentnessCheckMethod-E1, and determined that the cited sensor-calibration result expired before the proposed start. Separately, FixtureEntryReadinessCheck-043 : U.Work was performed by LabOperationsCoordinatorSystem-1 : U.System under obtaining RA-LabOperationsCoordinator-1-E4, enacted FixtureEntryReadinessEvaluationMethod-E2, and applied the criterion to the exact plan inputs.

The C.2.1 episteme FixtureTestEntryReadinessResult-E1, whose exact EntityOfConcern is WorkPlan-LAB-043, states notReady for PlanItem-TEST-043: the calibration result is expired and the fixture-drawing edition remains unresolved. Its stop is do not start planned-fixture-deformation-test-043; its return condition is obtain a current calibration result, select the drawing edition, and rerun the readiness check. The preparation and checking Work occurred; the target test did not. No A.21 gate decision or A.2.8.PER permission result follows from this readiness result.

What changes in practice. The team stops the target test, assigns the two named preparation moves, and reruns the exact criterion after their inputs are current; it neither turns the existing plan into performed Work nor asks a gate or permission label to stand in for the missing facts.

A.15.5:5.2 - Documentation Repair Probe

Situation: an assisting agent can run a reversible documentation probe to find source-currentness gaps.

For the probe itself, apply one exact readiness criterion to its WorkPlan, using the designated declaration-local PlanItem content that the criterion needs, and return the local readiness value with its relied-on inputs, window, and recheck condition. If the probe is actually run, first recover the precise performer System’s A.13 core for that action and independently admit the dated occurrence as U.Work under A.15.1 from its performance history, enacted Method, extent, and containing-System relation. Add F.6 afterward only when the target repair-readiness account also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; otherwise leave F.6 unopened. Then run a separate readiness check for the target repair. The claims about the probe plan, probe readiness result, performed probe, and target-repair readiness result are four distinct claims.

A.15.5:5.3 - Release screen with separate readiness, gate, and permission windows

At 10:00, ReleaseReadinessCheck-12 : U.Work evaluates ReleasePlan-E7, PlanItem-Deploy-12, and ReleaseEntryCriterion-E3. The persisted result says ready for reliance only in [10:00, 10:30) and requires recheck after any source, resource, assignment, permission, or gate-input change.

At 10:05, the current A.21 application of profile Release-Core-E4 consumes that readiness result through one identified GateCheckApplicationResult, cited by its GateCheckRef, among the complete effective check set. The gate returns a GateDecisionResult with decisionValue=pass for [10:05, 10:20); DecisionLogRef=ReleaseGateLog-12 cites the separate log recording that result. That gate result is not the readiness result and does not institute permission.

Separately, exact A.2.8.PER GrantedPermissionRelation@Context occurrence DeployGrant-12 covers the named beneficiary and deployment action for [09:00, 11:00). DeployNonProhibitionFinding-E2 reports nonProhibited from its named current frame, explicitly complete for this use, in evaluation window [10:00, 10:15); it is not the grant. A PermissionNormConflictFinding@Context, if an incompatible current norm is established over the same content and window, would be a third permission-side input and an unresolved disposition would stop the use. A policy that requires readiness, gate passage, a current grant, and the frame-relative non-prohibition result may rely on those distinct inputs at 10:10; it must re-evaluate the relevant branch when any window ends or a conflict appears. None of them proves that deployment Work occurred. A.15.1 identifies that Work only after its dated occurrence basis obtains.

If a dashboard shows green but the exact readiness result or its reliance window, the current A.21 profile application and DecisionLogRef, or the required permission value and qualification window cannot be recovered, the display remains a cue, an appearance-based reliance question, or a prompt to open the exact A.10 evidence-provenance and applicable currentness question for the claim being relied on. It is not readiness, evidence sufficiency, gate passage, authorization, or performed work by appearance.