FPF Reference

    Principles-to-Work Carry-Through

    E.18.1 · Stable · Architectural pattern (E) · Normative unless explicitly marked informative · Part E - The FPF Constitution and Authoring Guides

    About this pattern

    This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

    How to use this pattern

    Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

    Tech-name: PrinciplesToWorkCarryThrough Plain-name: principles-to-work carry-through relation Type: Architectural pattern (E) Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part E -> E.18 child pattern Builds on: E.18 Transformation Flow Structure, C.22.2 ProblemCard@Context, A.6.0 U.Signature, A.6.1 U.Mechanism, the A.15 work family, C.29, C.16, F.9, A.20, A.21, and Part G comparison, selection, and refresh patterns. Purpose: relate accepted problem-side material to the next FPF kind named by value, relation, record, or pattern application while preserving the useful first-principles move.

    Use this pattern when an accepted ProblemCard@Context is ready enough to guide work, but the next FPF use is not yet settled. The practitioner has an unsettled carry-through question: which problem-side distinction can be carried into the next FPF relation or record named by value?

    Keywords

    • P2W
    • principles-to-work
    • carry-through record
    • accepted ProblemCard@Context
    • formal substrate
    • mechanism realization
    • method-family selection
    • work planning
    • evaluation refresh.

    Relations

    E.18.1builds onTransformation Flow Structure
    E.18.1builds onProblemCard@Context
    E.18.1builds onUnified Lexical Rules for FPF
    E.18.1builds onPattern Quality Gates: Review and Refresh Profiles
    E.18.1coordinates withMathematical Lens Use
    E.18.1coordinates withU.Signature — Universal, law‑governed declaration
    E.18.1coordinates withU.Mechanism - Law‑governed application to a SubjectKind over a BaseType
    E.18.1coordinates withRole-Method-Work Alignment (Contextual Enactment)
    E.18.1coordinates withU.Work: The Record of Occurrence
    E.18.1coordinates withU.WorkPlan: The Schedule of Intent
    E.18.1coordinates withSlotFillingsPlanItem — Planned Slot-Fillings Baseline (WorkPlanning PlanItem)
    E.18.1coordinates withWork-Relevant Source Restoration
    E.18.1coordinates withEvidence Graph Referring (C-4)
    E.18.1coordinates withTrust & Assurance Calculus (F–G–R with Congruence)
    E.18.1coordinates withU.Flow.ConstraintValidity — Eulerian
    E.18.1coordinates withGateProfilization: OperationalGate(profile) (GateFit core)
    E.18.1coordinates withMulti-View Publication Kit
    E.18.1outline parentTransformation Flow Structure
    E.18.1outline next siblingTransformation Flow Mathematical Description
    E.18.1explicit referenceTransformation Flow Structure
    E.18.1explicit referenceProblemCard@Context
    E.18.1explicit referenceU.Signature — Universal, law‑governed declaration
    E.18.1explicit referenceU.Mechanism - Law‑governed application to a SubjectKind over a BaseType
    E.18.1explicit referenceRole-Method-Work Alignment (Contextual Enactment)
    E.18.1explicit referenceMathematical Lens Use
    E.18.1explicit referenceMM-CHR — Measurement & Metrics Characterization
    E.18.1explicit referenceAlignment & Bridge across Contexts
    E.18.1explicit referenceU.Flow.ConstraintValidity — Eulerian
    E.18.1explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)
    E.18.1explicit referenceU.Transformation: Bounded Change Under Conditions
    E.18.1explicit referenceTemporal Aspect: Time Windows, Rhythm, Cadence, and Currentness
    E.18.1explicit referenceTemporal Claim Adequacy: State Readings, Temporal Trends, and Intervention-Sensitive Temporal Change
    E.18.1explicit referenceFunction and Functional Precision Restoration (RPR-FUNCTION)
    E.18.1explicit referenceModule Relation Repair
    E.18.1explicit referenceU.RelationSlotDiscipline - SlotKind / ValueKind / RefKind discipline for n‑ary relations (with slot‑operation lexicon)
    E.18.1explicit referenceModularity and Reusable Structure Characteristics
    E.18.1explicit referenceGrounded Architecture and Selected-Structure Adequacy
    E.18.1explicit referenceU.Dynamics: State-Space and Transition-Law Episteme
    E.18.1explicit referenceU.WorkPlan: The Schedule of Intent
    E.18.1explicit referenceU.Work: The Record of Occurrence
    E.18.1explicit referenceEvidence Graph Referring (C-4)
    E.18.1explicit referenceEvidence Graph & Provenance Ledger
    E.18.1explicit referenceHuman-Centric Working-Model
    E.18.1explicit referenceUnified Term Sheet (UTS)
    E.18.1explicit referenceUnified Normalization Mechanism (UNM)
    E.18.1explicit referenceMechanism Introduction Protocol (MIP)
    E.18.1explicit referenceMulti‑Method Dispatcher & MethodFamily Registry
    E.18.1explicit referenceParity / Benchmark Harness
    E.18.1explicit referenceUnified Selection Kernel (SelectorMechanism)
    E.18.1explicit referenceNQD‑CAL — Open‑Ended Search Calculus
    E.18.1explicit referenceExplore–Exploit Governor (E/E‑LOG)
    E.18.1explicit referenceSlotFillingsPlanItem — Planned Slot-Fillings Baseline (WorkPlanning PlanItem)
    E.18.1explicit referenceWork-Relevant Source Restoration
    E.18.1explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
    E.18.1explicit referencePattern Quality Gates: Review and Refresh Profiles
    E.18.1explicit referenceDecision Theory (Decsn-CAL)
    E.18.1explicit referenceArchitecture Description Adequacy
    E.18.1explicit referenceArchitecture Structural View Adequacy (ASV)
    E.18.1explicit referenceUnified Lexical Rules for FPF
    E.18.1explicit referenceMulti-View Publication Kit
    E.18.1explicit referenceExplanationFaithfulnessProfile — explanation-use discipline over existing MVPK faces

    Content

    Problem frame

    Use this pattern when an accepted ProblemCard@Context is ready enough to guide work, but the next FPF use is not yet settled. The practitioner has an unsettled carry-through question: which problem-side distinction can be carried into the next FPF relation or record named by value?

    The primary EntityOfConcern is the P2W carry-through relation: the relation between accepted problem-side material and the next FPF use whose governing relation can be named by value. P2W keeps first-principles material usable by turning it into one recoverable next move instead of letting an inspiring explanation become an all-purpose project claim.

    Use this when

    • an accepted ProblemCard@Context names a working problem and the team needs a disciplined next move toward method, planning, performed work, or result interpretation;
    • a first-principles, U.Signature(profile=FormalSubstrate), PrincipleFrame, mechanism-position, method-position, A.15.2 U.WorkPlan or plan-item, performed-work, result-record, or source-currentness cue is present, but the FPF kind or relation to use next is still unsettled;
    • a transformation-flow structure, mathematical path relation in a graph-shaped description, flow diagram, principle scheme, scenario, functional description, or source publication helps the team think, while the next move must still be recovered as an FPF kind or relation named by value;
    • a result artifact, telemetry line, acceptance record, quality-evaluation record, done-state update, feedback pin, or integration claim needs to be unpacked before it can guide the next move.

    What goes wrong if missed

    The team jumps from a convincing problem-side formulation into downstream language without naming the FPF relation being used. The work then looks connected to first principles, but the next record is unclear, the result phrase becomes too broad, and measurement or source-currentness changes have no honest return relation.

    What this buys

    The practitioner gets one next move whose governing relation is named: write a P2W carry-through record, recover the next FPF kind or relation, write or use the governed record, stop with a reduced-use cue, or return to the earlier application whose assumption changed. The payoff is practical: first-principles thinking remains action-guiding without becoming a hidden project authorization.

    Not this pattern when

    • there is no accepted problem-side record; use C.22.2 or the problem-side pattern named by value first;
    • the FPF kind under repair, relation, and record to write are already settled; use that pattern directly and do not add a P2W layer;
    • the requested output is a local project procedure, schedule, or work-management method; use the relevant work, planning, method, gate, or operational-management pattern;
    • the requested record or claim is an evidence case, assurance case, gate record, decision record, architecture description, publication-use claim, or wording-use repair; use the recovered relation and its governing pattern directly.

    Problem

    First-principles work often becomes useful exactly when a problem-side formulation is ready to move toward work. The accepted problem card may expose an invariant, mathematical lens, functional role, mechanism-position candidate, method candidate family, planning constraint, result cue, or changed measurement assumption. Without P2W, that useful material is either overcompressed into "we have a solution" or scattered across several related FPF patterns before the working distinction is preserved.

    P2W solves a carry-through problem. It takes accepted problem-side material, states the distinction it can carry, selects the next FPF application, typed value, relation, or record, and records what was written, stopped, split, or reopened. The pattern succeeds only when a practitioner can replay the move from source problem to next record without importing the law of another pattern into P2W.

    Forces

    ForceWhat P2W must preservePressure to manage
    First-principles usefulnessA strong problem-side insight may guide method, planning, work, or result interpretation.The insight is tempting to treat as a completed downstream claim.
    Governing-kind precisionThe next FPF kind or relation must be recoverable before a continuing carry-through relation is used.Diagrams, graph-shaped expressions, and source wording can look sufficient without a record to write.
    Practical readabilityFirst use needs a compact record and a quick next action.Too much boundary prose can hide the working P2W move.
    Non-linear useP2W may skip, branch, split, stop, or reopen loci in the carry-through structure.A readable diagram or graph-shaped expression can be mistaken for a required project sequence.
    Result usefulnessResult phrases often point to artifacts, telemetry, acceptance, measurement, refresh, or role enactability.One broad result word can hide several different records.
    Neighbor economyNeighboring patterns keep their own law.Repeating their non-use doctrine inside P2W creates content fanout.

    Solution

    The solution has two parts: use the declarative carry-through structure below to select one relation-governed P2W move, then fill the carry-through or replay record only for the relation being made. The locus and relation vocabulary names which distinction can be preserved, which FPF relation is recovered, which record is written, which cue is stopped, and which earlier application reopens after a problem-side result becomes useful for work.

    P2W Declarative Carry-Through Structure

    Use P2W as a declarative carry-through structure of relation-governed moves from an accepted ProblemCard@Context to accepted FPF applications. The structure is not a prescribed FPF-use procedure. It can be expressed as a graph-shaped description or joined with project workflow material only when the workflow or mathematical graph description is the current EntityOfConcern of a governed use: a U.MethodDescription, U.WorkPlan, TransformationFlowStructure, flow valuation, or E.18.2 mathematical description. P2W itself shows which distinction can be preserved, which FPF relation is recovered, which record is written, which cue is stopped, and which earlier application reopens after a problem-side result becomes useful for work.

    The carry-through structure has nine recurring loci. A concrete P2W application selects a carry-through slice: it may use one locus, branch into several applications, split one source phrase into several records, stop with a reduced-use cue, or reopen an earlier locus when measurement or source currentness changes.

    LocusQuestion answeredOutput of the P2W move
    AcceptedProblemSideOutputWhat accepted problem-side material is being preserved for the next use?Problem-card reference plus carried distinction.
    NextFPFUseQuestionWhat is the next unsettled FPF kind or relation?One question stated in FPF vocabulary.
    FirstPrinciplesLensWhat structure, invariant, loss, or payoff makes the next move worth formal treatment?Preserved structure, lost structure, payoff, and stop condition.
    DeclarationStackWhich U.Signature(profile=FormalSubstrate), PrincipleFrame, ontology, CHR, measurement, normalization, or bridge relation is needed?Declaration or reference to the declaration relation named by value.
    MechanismMethodCandidateIs the next work-facing issue mechanism-position meaning, method-position meaning, method comparison, or retained-set handling?Mechanism cue, method cue, comparison cue, selector cue, or retained-set cue.
    TransformationTemporalAspectIs the next issue a bounded transformation under conditions, a temporal aspect of a governed object or claim, or the adequacy of an authored temporal claim?A.3.4, C.27.TA, or C.27 application.
    WorkPreparationIs a planning record, slot-filling plan item, feasibility note, evidence-reference pin, or freshness request needed?U.WorkPlan, PlanItem, or SlotFillingsPlanItem application.
    PerformedWorkAndResultHas dated U.Work occurred, and what result-related records appeared?Work occurrence plus unpacked artifact, telemetry, acceptance, measurement, source, or role-enactability relation.
    ReturnAndRefreshDid measurement, source currentness, reference plane, or problem-side wording change an earlier assumption?Return to the affected application with the changed relation named.

    P2W relation labels are carry, recover, write, split, stop, and return. Carry preserves a distinction from the problem side. Recover names the FPF kind or relation. Write creates or amends the governed record. Split separates one source phrase into several applications. Stop preserves a reduced-use cue when no relation-governed continuation is available. Return reopens the smallest earlier application whose assumption changed. These are carry-through relation labels for P2W use, not a project-work procedure.

    Carry-through record

    For first-minute use, fill only ProblemCardRef, CarriedDistinction, NextFPFUseQuestion, and either RecoveredFPFKindOrRelation or StopCondition. Use the remaining fields only when the move continues, splits, writes a record, or returns after a changed assumption.

    Use one filled record when applying P2W. It is the local project-facing record of the pattern. Do not copy an empty form into project material; if a field cannot be filled with recovered claim content, state the stop condition or leave the field out.

    P2W carry-through record:
  ProblemCardRef: ProblemCard@Context PC-FAB-042, accepted for a cooling-fixture deformation problem.
  CarriedDistinction: the deformation is not one more tuning defect; the problem card identifies a conserved heat-flow structure that must survive method choice.
  NextFPFUseQuestion: does the team need mathematical-lens use or a `U.Signature(profile=FormalSubstrate)` declaration before method selection?
  P2WLocus: FirstPrinciplesLens -> DeclarationStack.
  RecoveredFPFKindOrRelation: mathematical-lens use plus `U.Signature(profile=FormalSubstrate)` and `PrincipleFrame` declaration relation.
  SelectedApplication: `C.29` for preserved and lost structure; `A.6.0` for `U.Signature(profile=FormalSubstrate)` and `PrincipleFrame` when the declaration is written.
  WrittenRecordOrApplication: a short `U.Signature(profile=FormalSubstrate)` declaration naming the heat-flow invariant, the boundary conditions being preserved, the deformation factors left outside the model, and the payoff for later method comparison.
  NotCarried: no method is selected by this record.
  StopCondition: stop before method selection until comparator, measurement, and selected-set relations are named.
  ReturnTrigger: later result measurement shows that the planned module-interface constraint used the wrong reference plane.
  SourceCurrentnessCheck: source restoration and refresh reopen the measurement, normalization, planning, and method-comparison applications; the earlier U.Work occurrence is cited but not rewritten by P2W.

    ProblemCardRef and CarriedDistinction locate the accepted problem-side material and the distinction being carried. NextFPFUseQuestion, P2WLocus, and RecoveredFPFKindOrRelation keep the next FPF kind or relation explicit before a continuing carry-through relation is used. SelectedApplication and WrittenRecordOrApplication name what is used or written.

    NotCarried is a compact field, not a place to repeat boundary doctrine from other governing patterns. It names only the local overread that would change this P2W move. StopCondition, ReturnTrigger, and SourceCurrentnessCheck keep stopping and reopening tied to a changed relation, measurement, source-currentness, or problem-side assumption.

    This record shows the complete P2W relation structure: problem-side distinction, first-principles value, selected FPF application, written record, stop condition, and return after measurement and source-currentness change.

    Positive move table

    Locus reachedP2W moveRecord or continuation
    Accepted problem-side outputState what is carried from the problem card and what question under repair remains.P2W carry-through record begins.
    First-principles or mathematical cueName preserved structure, lost structure, payoff, and stop condition.Mathematical-lens use or U.Signature(profile=FormalSubstrate) declaration.
    Ontology, UTS, CHR, or PrincipleFrame cueOrder ontology, UTS, characteristic, measurement, and principle-frame declarations before downstream use.Declaration-stack application.
    Mechanism-position or method-position cueSeparate mechanism-position meaning from method-position meaning, method comparison, and retained-set handling.Mechanism-position, method-position, method-comparison, selector, or retained-set application.
    Bounded transformation or temporal-aspect cueSeparate bounded transformation, temporal aspect, and temporal-claim adequacy.A.3.4 for bounded transformation, C.27.TA for temporal aspect, or C.27 when authored temporal-claim adequacy or currentness-use is being made.
    Planning cueWrite or amend a planning record, plan item, evidence-reference pin, freshness request, or planned constraint.A.15.2 U.WorkPlan or plan-item application.
    Dated performed U.WorkRecord the work occurrence and relation to plan, gate, launch values, provenance, and later result records.Performed-work application plus any separate entry or provenance relation.
    Result phraseSplit the phrase into artifact, resource, launch-value, telemetry, acceptance, measurement, source, quality, done-state, feedback, parity, refresh, or role-enactability relation.One or more result-related applications.
    Changed measurement or source currentnessReturn to the smallest earlier application whose assumption changed.Measurement, normalization, source-restoration, refresh, planning, method-comparison, or problem-side correction.

    Locus Use Details

    Problem-side input: P2W starts only from accepted problem-side material. The record carries the distinction that matters for the next move, not the whole problem-side pattern.

    First-principles and declarations: mathematical-lens use, U.Signature(profile=FormalSubstrate), ontology, UTS, CHR, measurement, normalization, bridge, and PrincipleFrame material are handled as declaration-stack applications. The P2W record names which declaration or neighboring relation is being written or cited, what structure is preserved, what is lost, and which downstream relation is still unsettled.

    When mathematical wording points both to a formal declaration and to a mathematical lens, P2W does not decide by vocabulary. Use the slot discipline in A.6.0:10a.1: A.6.0 owns U.Signature(profile=FormalSubstrate) declaration, C.29 owns mathematical-lens use, A.6.1 owns mechanism consumption or realization, and E.18.1 owns only the carry-through cue and next-relation selection.

    Mechanism and method: do not decide by noun. Recover the claim position. A mechanism-position claim names operation algebra, law set, applicability predicates, effect realization, or mechanism-description need. A method-position claim names a context-defined semantic way of doing work, candidate set, comparison, selector, retained set, or selected-record need. A shared source label, project-side name, or recognizable change concern may require linked method and mechanism typed values, but P2W records only which relation is being carried through and leaves the other typed value as a stopped cue unless its governing pattern is opened.

    Transformation and temporal aspects: a problem-side distinction may point to a bounded transformation, a temporal aspect, and a temporal-claim adequacy question at once. Do not fold these into method, mechanism, plan, or work. A.3.4 owns bounded transformation under conditions, including transformed object, pre-state, post-state, condition set, and admissible effect claim. C.27.TA owns temporal aspects such as interval, deadline, cadence, rhythm, synchronization, currentness window, recovery timing, or stabilization timing when the aspect itself is being named. C.27 owns adequacy, supported use, unsupported use, or source-currentness use of authored temporal claims.

    Planning and performed work: planning records are A.15.2 U.WorkPlan values or plan-item records, including evidence-reference pins, feasibility notes, freshness requests, and planned constraints. Performed work is a dated U.Work occurrence. P2W records which side of that boundary the carry-through record uses and which later result records have appeared.

    Result carry-through: a result phrase is treated as a bundle of possible records. The P2W move is to unpack it before it guides any next move.

    Structure, publication, function, module-interface, and integration cues: a transformation-flow structure, mathematical graph description, diagram, or publication can help classify the P2W move. Function wording continues only as an A.6.F function or functional-relation claim; interface, port, protocol, connection, resource limit, or integration wording continues only as a module-interface, signature-slot, reusable-structure, or architecture relation named by value through A.6.M, A.6.5, C.31, or the C.30 family. Otherwise the wording remains classification material for the P2W record.

    Boundary and relation discipline

    P2W is not a catalogue of boundary doctrines from other governing patterns. It has one local boundary rule: carry only the distinction accepted on the problem side, recover the next FPF kind or relation, and stop anything that would require a different governing relation until that relation is being made.

    Source pressureLocal P2W decisionContinuation
    Problem-side materialCarry only the accepted distinction and the next FPF-use question.Continue when the next FPF kind or relation is named; otherwise stop before P2W begins.
    First-principles or mathematical wordingState preserved structure, lost structure, payoff, and stop condition.Continue only as mathematical-lens use or as a U.Signature(profile=FormalSubstrate) declaration when that relation is being made.
    Declaration-stack wordingKeep the declaration being made separate from neighboring measurement, normalization, comparison, ontology, or bridge relations.Continue through the declaration relation that changes this P2W move.
    Work-facing, temporal, or result wordingRecover the concrete mechanism-position, method-position, bounded-transformation, temporal, planning, performed-work, or result-related relation.Continue through the matching application; split one source phrase only when several relations are being made.
    Another governed relation appears inside the source phrasePreserve the cue as source material, but do not import its governing law into P2W.Continue only through the relation that changes this P2W move; leave the other cue stopped until its governing relation is being made.

    Return and refresh rule

    P2W can reopen earlier applications without becoming a required work procedure. Reopen only the smallest application whose assumption changed:

    Changed assumptionSmallest reopened application
    measurement value, unit, scale, reference plane, or transport relationmeasurement, normalization, bridge, or comparison application
    source record, source edition, source reference, or publication-use relationwork-relevant source restoration, publication-use, or refresh application
    result artifact, telemetry, acceptance, done-state, or role-enactability recordresult-related split plus the evidence named by value, measurement, quality, role, or refresh relation
    method set, comparator, selector, retained set, or selected recordmethod-comparison, selector, retained-set, or selected-record application
    problem-side statement or accepted carried distinctionproblem-side correction in the problem-card application

    The earlier dated U.Work occurrence remains a dated occurrence. P2W may cite it during return, but the changed assumption determines which application is reopened.

    Relation selection aid

    Use this aid after the carry-through record when several cues compete for the continuing FPF application. It names the relation family P2W must recover before another pattern can govern the claim; pattern names for those families are listed once in E.18.1:12.

    What the source phrase makes currentRelation to recover before continuationLocal P2W move
    accepted problem-side distinctionaccepted ProblemCard@Context material plus one unsettled next relationState what is carried and what question remains.
    preserved or lost structure, invariant, near-sameness, formal payoff, or formal stop conditionmathematical-lens use or U.Signature(profile=FormalSubstrate) declarationName preserved structure, lost structure, payoff, and stop condition.
    postulate, observability, unit, plane, comparator, threshold, ontology edition, CHR edition, normalization, bridge, or measurementthe declaration or measurement-family relation being madeWrite or cite only that relation.
    mechanism position, method position, method candidate set, comparator, selector, retained set, or selected recordthe mechanism, method, comparison, selector, retained-set, or selected-record relation being madeKeep these relation positions distinct and continue only through the recovered one.
    bounded transformation, temporal aspect, dynamics episteme, or temporal supported-use claimA.3.4, C.27.TA, A.3.3, or C.27 relation according to the claim being madeSplit one phrase when it carries several of these relations.
    planning record, plan item, performed work, launch value, result artifact, telemetry, acceptance, measurement, refresh, or role enactabilityA.15.2 U.WorkPlan, plan-item, dated U.Work, or the result-related relation being madeWrite or cite the record being made; do not let generic result wording guide the next move.
    structure, transformation-flow cue, diagram, scenario, view, graph expression, publication, module-interface, function, evidence-looking, gate-looking, or decision-looking wordingthe relation named by value in the source phrase, or no continuation if none is recoverableUse the material only as classification until the relation is recovered.

    Lowering and reopen block

    Use this block when the carry-through record cannot preserve and continue the stronger-looking source cue. P2W succeeds when it leaves one relation-governed move. If the move is not recoverable by value, lower the cue, stop, or reopen the smallest affected application.

    Claim familyLowering or stop conditionReopened or continuing relation
    Problem-side materialNo accepted ProblemCard@Context, or the accepted problem-side statement changes the carried distinction.Stop before P2W begins, or return to the problem-side record named by value that changed.
    First-principles, mathematical, formal, or declaration-stack claimPreserved structure, lost structure, payoff, stop condition, declaration relation, measurement relation, normalization relation, bridge relation, or comparison relation cannot be named.Lower to a reduced-use source cue; continue only after the recovered declaration, mathematical-lens, measurement, normalization, bridge, or comparison relation is being made.
    Mechanism, method, selected-set, transformation, temporal, dynamics, planning, performed-work, or result claimThe source phrase blurs relation positions that change different P2W moves.Split to the recovered relation and continue only through that relation.
    Another governed relation is only signaled by a label, diagram, port, module-interface phrase, publication, view, approval word, readiness word, or wording phraseThe source material classifies a possible relation but does not name the relation being made.Preserve the cue and stop local continuation until the governed relation is recoverable by value.

    Replay and currentness record

    Use this compact record after source restoration, changed measurement, changed problem-side material, FPF pattern change, or a use-found defect. The record keeps replay local: it says what changed, what still carries, what no longer carries, and which application reopens.

    P2W replay and currentness check:
  OriginalRecordRef:
  ChangedInput:
  ChangedAssumptionKind:
  StillCarried:
  NoLongerCarried:
  SmallestReopenedApplication:
  GoverningRelationChecked:
  CurrentnessResult:
  NextMove:

    ChangedAssumptionKind names the assumption kind, such as measurement, unit, reference plane, source record, problem-side statement, method set, comparator, module-interface relation, publication-use relation, or FPF pattern change. StillCarried and NoLongerCarried prevent a source-currentness change from silently rewriting the whole carry-through slice. SmallestReopenedApplication keeps the repair local, and NextMove states whether to continue, stop, split, lower to a reduced-use cue, or return to the problem-side pattern.

    Archetypal Grounding

    E.18.1 is grounded in a simple System and Episteme contrast. In System-facing work, accepted problem-side material may lead toward method choice, planning, performed work, result records, and result measurement. In Episteme-facing work, the same material may lead toward a U.Signature(profile=FormalSubstrate) declaration, mathematical-lens use, description, publication, evidence, or gate-related claims. The P2W move asks one question in both cases: which FPF kind or relation can carry the next claim being made?

    ArchetypeSystem-side groundingEpisteme-side grounding
    TellA manufacturing team accepts a problem card showing that a fabrication issue is caused by a missing functional constraint.A research team accepts a problem card showing that two descriptions may be almost the same only under a declared U.Signature(profile=FormalSubstrate).
    Show without P2WThe team treats the principle scheme as method selection, work plan, performed work, and acceptance evidence at once.The team treats mathematical equivalence as real-world identity, measurement validation, evidence, and decision authority.
    Show with P2WThe team writes a carry-through record, separates method comparison from A.15.2 U.WorkPlan and plan-item records, records dated U.Work, and unpacks result records.The team writes a carry-through record, separates mathematical-lens use, U.Signature(profile=FormalSubstrate), bridge, measurement, evidence, and provenance relations, and keeps equivalence bounded by the declared formal relation.

    Worked slices

    1. Thin first-principles start. An accepted ProblemCard@Context says the problem is not one more local tuning task because a conserved structure is being ignored. P2W records the carried distinction, recovers mathematical-lens use and U.Signature(profile=FormalSubstrate) declaration only if needed, and stops before method selection until comparator, measurement, and selected-set relations are named.

    2. Planning from selected enough method. A method family is selected enough for planning. P2W carries the planning relation; the plan records planned constraints, planned fillers, evidence-reference pins, and freshness requests.

    3. Performed work after planning. A dated work occurrence has appeared. P2W carries the performed-work relation and records which gate, release, provenance, or launch-value relation is separate from the occurrence.

    4. Result interpretation without generic result. A source says the work result proves that the approach worked. P2W unpacks artifact, telemetry, measurement, evidence, acceptance, quality-evaluation, refresh, and role-enactability candidates before any one of them guides the next move.

    5. Functional explanatory order. A source diagram places U.Signature(profile=FormalSubstrate), principle frame, mechanism, normalization, method selection, planning, performed work, and result measurement in one readable order. P2W uses the diagram to classify applications while keeping material time and performed-work chronology with their own patterns.

    6. Interface split before P2W use. A source says a port-throughput limit makes a solution feasible after integration. P2W first splits the phrase: module-interface relation (A.6.M), E.18 transformation-flow relation or A.6.F function/throughput relation when function use is being claimed, WorkPlan constraint (A.15.2), dated U.Work occurrence (A.15.1), evidence or gate claim (A.10, G.6, A.20, or A.21), or architecture and structural-view claim (C.30 family). The carry-through record writes only the relation that changes the P2W move being made and leaves the other readings as stopped cues.

    7. Result measurement returns to planning. A performed U.Work occurrence produced telemetry and an artifact. Later measurement shows that the planned module-interface constraint was interpreted against the wrong reference plane. P2W splits measurement, reference-plane repair, source restoration, refresh, planning revision, and method-comparison claims. If the original ProblemCard@Context no longer states the right problem, the problem-side correction returns to the problem-side pattern.

    Additional worked situations

    SituationP2W moveWhat changes
    First-minute useA practitioner has only an accepted ProblemCard@Context and the sentence "the cooling fixture violates the heat-flow invariant." Fill ProblemCardRef, CarriedDistinction, NextFPFUseQuestion, and RecoveredFPFKindOrRelation or StopCondition.The next action becomes a C.29 and A.6.0 application, not method selection or evidence writing.
    Diagram and approval note in the same sourceThe same source contains a diagram, a test photo, and a manager note saying "approved." Keep P2W focused on the distinction carried from the problem-side result.Diagram, evidence-looking material, and gate-looking material are separated by relation recovery; the P2W record keeps only the carried distinction and next relation.
    Principle story without accepted problem-side materialA source has an inspiring principle story but no accepted ProblemCard@Context.P2W stops before it begins; the material remains a reduced-use cue until C.22.2 or the problem-side pattern named by value accepts problem-side material.
    Acceptance label hides wrong measurementA dashboard shows a green acceptance label, but the measurement used the wrong reference plane.Acceptance color does not guide the next move; P2W returns to measurement, normalization, source restoration, planning, and method comparison.
    Changed unit after source restorationLater source restoration changes only the unit and reference plane used by the planning constraint.P2W reopens the smallest affected applications; the earlier dated U.Work occurrence is cited, not rewritten.
    Near-sameness under a formal declarationA mathematical near-sameness claim preserves heat-flow structure but loses deformation factors outside the model.P2W uses C.29 for mathematical-lens use and A.6.0 for U.Signature(profile=FormalSubstrate), names preserved and lost structure, and prevents the lens from settling empirical truth or work authorization.
    FPF relation law changes after a P2W recordA governing FPF pattern changes the boundary for architecture-description, evidence, or source-restoration use. Fill the replay and currentness check: changed law, still-carried distinction, no-longer-carried cue, smallest reopened application, and next move.The earlier carry-through record is replayed rather than trusted by age; only the affected architecture-description, evidence, source-restoration, or P2W field changes.
    Relation selection would over-select from one phraseA source says "the new port contract proves integration readiness." P2W splits module-interface relation, E.18 transformation-flow relation, dated U.Work occurrence, evidence cue, gate cue, and architecture-description cue.Only the relation that changes the P2W move being made is written; the remaining readings stop as named cues until their governed relations are being made.
    Formal claim loses payoffA U.Signature(profile=FormalSubstrate) declaration preserves a neat invariant, but no practical payoff or downstream stop condition can be stated for the accepted problem-side material.The mathematical phrase lowers to a reduced-use cue; P2W does not open method selection, evidence, gate, or A.15.2 planning from mathematical prestige alone.
    Result source becomes staleA result-looking source is later replaced by a fresher source with a different artifact reference and measurement reference.P2W uses A.15.4-style source restoration before result carry-through; stale result wording cannot continue as evidence, acceptance, or quality evaluation.

    Pilot examples for coupled transformation-flow slices

    These pilots are grounding checks, not source terminology to import. They exercise the same common shape: one selected TransformationFlowStructure can relate several transformation-flow valuations or slices, one slice may develop or select a usable product, another slice may apply it, and an evaluation or refresh slice may return to the smallest affected development or application locus. The selected structure does not merge the slice-local objects, DesignRunTag boundaries, evidence, gates, work occurrences, or the relation position that the carried object fills inside each slice. Use each pilot to check whether the P2W use being made can name the joined transformation-flow slices, the carried object's slice-local relation position, the DesignRunTag boundary, and the smallest reopened slice.

    PilotP2W use being madeWhat it tests
    Coffee service STFAn accepted service-quality problem carries heat or mass-balance structure through U.Signature(profile=FormalSubstrate), declaration-stack, mechanism-position, normalization, method-selection, A.15.2 U.WorkPlan or plan-item records, dated U.Work, telemetry, measurement, and refresh relations.Positive whole-chain readability, freshness, set-return selection, launch values only in performed work, and relation-local refresh.
    Compiler design and runToolchain construction, compiler use, and product execution are separate applications; design and run changes pass through the gate and work relations being used.DesignRunTag, launch gate, reproducible build currentness and source currentness, and no collapse of build, run, and product work.
    TAMP and MPC roboticsMethod selection and A.15.2 planning records may be revised under a declared progress or budget condition before performed work.Branching and cycle use without imposing one mandatory work procedure, and no launch-value binding before performed work.
    AutoML and QDMethod selection returns a Pareto, QD, front, or archive set under comparator and descriptor editions, not a hidden scalar winner.Set-return discipline, comparator currentness, no hidden scalarization, and retained-set refresh.
    Freshness or material-transport caseWork planning and performed work depend on freshness windows, transport relations, units, reference planes, and source-currentness.No implicit latest, no unbridged unit or plane comparison, and smallest affected refresh.
    Integration under module-interface constraintsAfter assembly, a result phrase may mean role-enactability under module-interface constraints, evidence, gate, architecture, function, or work relation.Result carry-through is not artifact-only or telemetry-only; module-interface and integration wording must recover the relation being claimed.
    Tool-product-use chainA design-tagged transformation-flow slice makes a tool; a later run or use slice uses the tool to make a chair; another slice uses the chair as context for writing a text.One selected TransformationFlowStructure can relate all slices, but the same carried object may fill a run-result position in one slice and a design-side input, tool, context, or constraint position in another. The relation-position shift is explicit, tied to the E.18 transformation-flow relation and any DesignRunTag being used, and does not change the object's kind by wording.
    FPF pattern-development / self-evolving specificationA development transformation-flow slice creates or repairs a pattern, specification, or process description through drafting, quality evaluation, publication projection, and admitted publication; a later use slice applies that product to its own EntityOfConcern; a defect found in use returns to the smallest development slice for repair.Development, application, and evaluation slices are joined by transfer and return relations inside one selected TransformationFlowStructure while keeping objects and DesignRunTag boundaries separate; evaluation records or use-found evidence change the product through edits to the smallest development slice, not by entering the used publication's practitioner-facing prose.

    Filled P2W output records

    Use these as replayable outputs, not as new templates.

    P2W output record:
  ProblemCardRef: ProblemCard@Context PC-COOL-017, accepted for a cooling-loop stabilization problem.
  CarriedDistinction: the observed deformation is not one more tuning defect; a conserved heat-flow structure must survive method comparison.
  NextFPFUseQuestion: which formal or mathematical relation is needed before method selection?
  RecoveredFPFKindOrRelation: mathematical-lens use plus `U.Signature(profile=FormalSubstrate)` declaration.
  SelectedApplication: `C.29` for preserved and lost structure; `A.6.0` for the formal-substrate declaration.
  WrittenRecordOrApplication: declare the heat-flow invariant, boundary conditions, excluded deformation factors, and practical payoff for comparator selection.
  LocalStop: method selection waits until comparator, measurement, and selected-set relations are named.
    P2W output record:
  ProblemCardRef: ProblemCard@Context PC-PORT-008, accepted for an integration-throughput problem.
  CarriedDistinction: the port-throughput phrase may carry module-interface, `E.18` transformation-flow, work-plan, performed-work, evidence, gate, and architecture relations, but only one relation changes this P2W move.
  NextFPFUseQuestion: which relation is being written now?
  RecoveredFPFKindOrRelation: `A.6.M` module-interface relation plus `E.18` transformation-flow relation; `A.15.2` planning constraint is written only if the planning record is being made.
  SelectedApplication: `A.6.M` for the port contract; `E.18` for the selected transformation-flow relation; `A.15.2` only for the planned constraint.
  WrittenRecordOrApplication: write the module-interface constraint and `E.18` transformation-flow relation; stop evidence and gate cues until their governing relations are being made.
  LocalStop: no readiness proof or work authorization follows from the port phrase by itself.

    Bias-Annotation

    Lenses tested: Gov, Arch, Ontological and epistemic, Prag, Did. Scope: accepted problem-side output moving toward FPF applications.

    • Governance bias (Gov): permission, gate, release, assurance, and decision cues are preserved only as local cues until the relevant FPF relation is recovered.
    • Architectural bias (Arch): diagrams, selected structures, and module-interface language help classify the next move; they do not displace the P2W carry-through relation.
    • Ontological and epistemic bias: U.Signature(profile=FormalSubstrate), near-sameness, source publication, and evidence-looking language are turned into recovered FPF kinds and relations.
    • Pragmatic bias (Prag): the carry-through structure is useful for action without becoming a required project procedure.
    • Didactic bias (Did): the positive carry-through structure and filled record come before the boundary table, so precision does not bury the working move.

    Conformance Checklist

    • CC-E18.1-1 The P2W use starts from an accepted ProblemCard@Context or stops before P2W begins.
    • CC-E18.1-2 The carry-through record states ProblemCardRef, CarriedDistinction, NextFPFUseQuestion, RecoveredFPFKindOrRelation, SelectedApplication, WrittenRecordOrApplication, NotCarried, StopCondition, ReturnTrigger, and SourceCurrentnessCheck.
    • CC-E18.1-3 The positive carry-through structure is recoverable: accepted problem-side output, question under repair, first-principles lens, declaration stack, mechanism position, method position, planning, performed work, result records, and return or refresh.
    • CC-E18.1-4 One source phrase may split into several FPF applications; the record does not compress them into one generic token.
    • CC-E18.1-5 Result wording is unpacked into concrete result-related relations; a generic WorkResult kind is not admitted.
    • CC-E18.1-6 PrincipleFrame material keeps postulates and CHR observability distinct from units, planes, comparators, thresholds, ontology editions, CHR editions, plans, work, evidence, and gates.
    • CC-E18.1-7 Measurement, source currentness, reference-plane, method-set, comparator, or problem-side changes return to the smallest affected application.
    • CC-E18.1-8 Non-P2W governing law appears only as a recovered relation in E.18.1:4.6 and as a pattern list in Relations, not as repeated local doctrine.
    • CC-E18.1-9 Local boundary wording remains only where it names a near-miss that changes the next P2W action.
    • CC-E18.1-10 The pattern leaves one useful relation-governed action: write the carry-through record, write or use the governed record, split a source phrase, stop with a reduced-use cue, or return to a changed application.
    • CC-E18.1-11 Archetypal grounding can replay at least one coupled transformation-flow-slice pilot from E.18.1:5.3; the pilot joins development, application, evaluation, and repair slices in one selected TransformationFlowStructure while keeping their objects, slice-local relation positions, DesignRunTag boundaries, and evidence distinct. The self-evolving-spec pilot keeps development-slice evidence or use-found evidence outside the used pattern, specification, or process description.
    • CC-E18.1-12 Every carried claim family can be lowered, stopped, split, or reopened through E.18.1:4.7; a source cue that cannot name the recovered FPF kind or relation remains a reduced-use cue.
    • CC-E18.1-13 Every replay after changed source, measurement, problem-side material, or FPF relation law names the changed assumption kind, what is still carried, what is no longer carried, the smallest reopened application, the governing relation checked, and the next move.

    Common Anti-Patterns and How to Avoid Them

    Anti-patternRepair
    Boundary fanout. The pattern repeats long lists of what P2W is not.Keep relation discipline in E.18.1:4.4; make local sections state the next P2W action.
    Carry-through-as-procedure. A carry-through structure, diagram, or graph-shaped expression is read as a required project sequence.Treat it as relation-governed carry-through over FPF applications; use stop, split, and return relations.
    ProblemCard-as-solution. The accepted problem card is treated as method, plan, work, evidence, or result.Write the carried distinction and next FPF-use question before selecting an application.
    Math-as-authority. A U.Signature(profile=FormalSubstrate) declaration, mathematical lens, or near-sameness does all downstream work.Record preserved structure, lost structure, payoff, and stop condition; continue through the recovered relation.
    Generic result token. "Result" becomes one local kind.Split the phrase into artifact, telemetry, acceptance, quality, measurement, refresh, source, evidence, or role-enactability relation.
    Interface shortcut. Interface, port, protocol, connection, resource, or integration wording selects function, method, work, evidence, gate, or architecture by itself.Recover the module-interface, signature-slot, function, architecture, work, evidence, or gate relation before continuing.

    Consequences

    ConsequenceBenefitCost or mitigation
    The carry-through record becomes the local project record.A practitioner can replay the move from problem-side output to continuing FPF application.The record adds a small step before downstream work.
    Positive carry-through structure comes before boundary.First use is readable before the heavier relation aid.Boundary checks are still available in one canonical section.
    Result language becomes unpackable.Artifacts, telemetry, acceptance, measurement, refresh, and role enactability can be handled by their own records.More than one application may be needed for one source phrase.
    P2W stays non-procedural.The pattern can be used in many project situations without prescribing one local procedure.Teams that want a work procedure must add method material or A.15.2 planning material outside P2W.
    Related patterns keep their authority.P2W avoids duplicating evidence, gate, decision, architecture, publication, mechanism, and work-family doctrine.Users consult the pattern named by the recovered relation when that relation is being made.

    Rationale

    E.18.1 is a child of E.18 because P2W uses a selected transformation-flow structure as its setting when the carry-through relation spans several transformation-flow slices, loci, or returns. It does not define graph law or prescribe performed-work order. It defines a local carry-through pattern for turning accepted problem-side material into a next FPF use whose governing relation is named.

    The design puts the positive move table first because repeated negative distinction sets can make a pattern whose primary EntityOfConcern is P2W behave like reference policing. P2W needs precision, but precision is useful here only when it leaves a surviving action: write the carry-through record, recover the FPF kind or relation, use the governed record, stop, split, or return.

    SoTA-Echoing

    SoTA alignment rule. P2W borrows useful distinctions from practice traditions only after they can be stated as a P2W carry-through move: accepted problem-side material, carried distinction, recovered FPF relation, written record, stop condition, and local return. Currentness has two sources. A project source can become stale or be replaced. An FPF pattern can also change the relation law used by the carry-through record. In both cases P2W reopens only the smallest affected application.

    Practice traditionDistinction kept for P2WP2W invariantPractitioner implicationReopen if
    Model-based engineering and systems practice separates model, view, requirement, evidence, and performed-work records because each has different authority.A useful diagram or view can classify the next relation without changing the governed kind.P2W separates transformation-flow structure, mathematical graph description, view, publication, evidence, gate, and work applications before the next move.The practitioner can use a diagram as thinking material without letting the diagram authorize work, prove readiness, or settle evidence.The project source, architecture-description relation, evidence relation, gate relation, or release relation changes.
    Traceability and digital-thread practice values continuity from problem, rationale, method, plan, work, and result while keeping record kinds distinct.A trace is useful only when each record kind remains named.P2W carries problem-side material through a replayable carry-through record while keeping problem card, work plan, performed work, evidence, provenance, result, and refresh relations distinct.The team can replay a carry-through slice from problem to work without treating trace continuity as evidence, approval, or performed work.Source restoration, provenance, refresh, or work-family law changes the currentness relation.
    Formal-methods and mathematical-modeling practice uses U.Signature(profile=FormalSubstrate) declarations to preserve invariants, expose lost structure, and make equivalence conditions explicit.Mathematical value is recoverable only through preserved structure, lost structure, payoff, and stop condition.P2W separates mathematical-lens use from the U.Signature(profile=FormalSubstrate) declaration and from empirical, work, evidence, or authorization claims.A mathematical idea helps choose the next disciplined move without becoming proof of real-world identity or permission to act.Mathematical-lens, signature, bridge, measurement, normalization, comparison, or source-currentness assumptions change.
    Assurance, safety, evidence, gate, and decision practice treats confidence, acceptance, validation, approval, and release as distinct relations.Labels and readiness phrases are cues, not local authority.P2W preserves the cue, recovers the relation, and stops local authority until the governed relation is being made.A warning, green label, or approval note remains useful without becoming an evidence case, gate record, decision, or release.Evidence, assurance, gate, conformance, release, work-entry, or decision relation changes.

    Relations

    • E.18 governs selected TransformationFlowStructure, transfer annotations, flow valuation, ConstraintValidity, GateFit, gate profile, design tags, and run tags.
    • C.22.2 governs the accepted problem-side record and problem-side claims related to the carried distinction.
    • C.29, A.6.0, E.14, F.17, F.9, C.16, A.19.UNM, and Part G govern mathematical-lens use, U.Signature(profile=FormalSubstrate), principle-frame, ontology, UTS, bridge, measurement, normalization, and comparison relations.
    • A.6.1 and E.20 govern mechanism and mechanism-method stabilization relations. A.3.4, C.27.TA, C.27, and A.3.3 govern bounded transformation, temporal aspect, temporal-claim adequacy, and dynamics-episteme relations.
    • G.5, G.9, A.19.SelectorMechanism, C.18, and C.19 govern candidate-set, comparison, selector, retained-set, and selected-record relations.
    • A.15, A.15.1, A.15.2, A.15.3, and A.15.4 govern role-method-work alignment, performed work, planning, planned baselines, and work-relevant source restoration.
    • A.10, B.3, G.6, E.19, A.20, A.21, and C.11 govern evidence, assurance, provenance, conformance, gate, release, work-entry, and decision claims.
    • C.30, C.30.AD, C.30.ASV, C.31, A.6.M, A.6.F, E.10, E.17, and E.17.EFP govern architecture, architecture-description, structural-view, reusable-structure, module-interface, function, wording-use, publication, and publication-use claims.

    E.18.1:End

    Last Updated: 2026-06-13 — this section last modified in upstream FPF commit cb17c555 (github.com/ailev/FPF)