#P2W Problem-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: ProblemToWorkCarryThrough Plain-name: problem-to-work carry-through 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, A.3.1 U.Method, A.3.2 U.MethodDescription membership, A.3.4 actual bounded change, the A.15 work family, A.15.PROD local production-claim recovery, A.6.RCD exact missing-governor disposition, A.6.REL relation-occurrence and receiving-use discipline, A.6.P relational precision restoration, A.6.P.WMR wording-to-relation recovery, C.29, C.16, A.19.CPM, A.19.SelectorMechanism, C.18, C.19, F.8, F.18, F.17, F.9, G.5, G.9, G.11, A.20, and A.21. Purpose: preserve selected distinctions from an accepted problem-side record as method selection, planning, performed work, result interpretation, and return become current.

Use this pattern when an accepted ProblemCard@Context is ready enough to guide work, but the next FPF use is unsettled. Ask which accepted distinction should shape the next question, which relation and participants that question asserts, and what result or stop is needed before the next action.

#Relations

#Content

#Problem frame

Use this pattern when an accepted ProblemCard@Context is ready enough to guide work, but the next FPF use is unsettled. Ask which accepted distinction should shape the next question, which relation and participants that question asserts, and what result or stop is needed before the next action.

The accepted ProblemCard@Context is the primary EntityOfConcern of any materialized P2W note. Start from one accepted claim and one decision or use that needs it. Then state the relation being asserted, name its participants, and apply the pattern that governs that relation. A separately identified U.Viewpoint episteme or BoundedModelUseStructure participates only when the claim designates that object and its organization changes how the receiving claim is interpreted; neither becomes an identity field of the ProblemCard or note. Method selection, planning, dated work, actual change, result interpretation, and return remain separate continuations under their direct patterns. P2W introduces no relation kind or occurrence and is neither dated work nor a U.Transformation. A governing-pattern reference, selected continuation, recommendation, imperative sentence or intended realization does not admit any episteme as U.MethodDescription; A.3.2 requires one already identified C.2.1 episteme, one independently admitted U.Method as its exact EntityOfConcern, and at least one substantive way-of-doing claim.

Keep three objects separate. The accepted ProblemCard is the EntityOfConcern of a materialized P2W note. The note is identified under C.2.1 by its ClaimGraph, that exact card, and its effective U.ReferenceScheme; its ClaimGraph names the receiving use and designates a separately identified viewpoint or model-use structure only when the claim uses that object and its organization changes how the receiving claim is interpreted. The subject EntityOfConcern of each direct pattern is the system, episteme, method, role, work occurrence, relation, or other project entity addressed by that pattern. The compact note, diagram, plan, trace, and publication are epistemes or publication-side values that describe, constrain, or make those direct claims inspectable. Later method enactment or dated work can change or preserve a subject EntityOfConcern; improving a P2W note or completing its fields does not establish that subject change, work occurrence, evidence, acceptance, or result.

Primary reader and question. The reader already has an accepted ProblemCard@Context and must decide one next claim. Ask in ordinary words: what relation am I asserting, between which participants, and what result would change the next action? Then apply the pattern that governs that relation. Source wording or a supporting episteme may help formulate the question but does not supply the downstream result.

So-what adoption test. Use P2W only when keeping the accepted distinction changes which relation you assert, what result you write, or whether you continue, split, stop, or return. If the relation and result are already settled and P2W would add only another note, skip P2W and apply the direct pattern.

E.11.PUA governs a smaller use and may begin without ProblemCard@Context: apply one selected pattern to one current practical question, obtain the first directly typed result, and state its receiving use. E.18.1 begins only when the wider work-facing continuation depends on preserving accepted problem-side material. PUA may support one pattern inspection inside a P2W flow, but it does not replace the accepted-problem carry-through.

#Use this when

• an accepted ProblemCard@Context names a working problem and the team needs a disciplined next FPF use toward method, planning, performed work, or result interpretation;
• an invariant, 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 FPF use still lacks 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 FPF use.

#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 responsive to the accepted problem, 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 concrete next move: keep the accepted claim in view, state the question and participants, apply the pattern that answers it, and use the result it returns. Split several relation claims before applying their patterns. If the relation or needed facts are missing, keep the cue and stop. If a relied-on result changes, reopen only the continuation that used it. Add the compact note only when another person or later action must replay that path. The accepted problem-side distinction remains useful without becoming hidden permission to start work.

#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

An accepted problem-side distinction becomes useful when it is ready to guide downstream work or work-planning use. 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 distinction 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. First say which accepted claim must affect which decision or use. Then write one ordinary relation-specific question, name its participants, apply the pattern that answers it, and keep that pattern's result or stop. Add a compact note only when another person or later action must replay the path. P2W succeeds when the accepted claim, receiving use, concrete question, direct pattern, and result remain inspectable without turning their use-specific connection into a relation kind or treating a note, diagram, plan, trace, or publication as the subject entity or as proof that work occurred.

#Forces

#Solution

Local P2W mantra. Use this Plain recall formula for one working decision: which exact P2W continuation, if any, is justified now?

Carry the accepted distinction — ask one relation question — apply its direct owner — keep its result or stop — reopen only the dependent continuation.

Filled cooling use. ProblemCard@Context PC-FAB-042 says that method comparison must preserve the conserved heat-flow structure. The current decision is whether a mathematical-lens continuation is justified. Ask which structure the proposed lens preserves, which it loses, and where its use stops; apply C.29; keep the returned lens-use result. If the lens subject, declared use, preservation/loss account or stop is unresolved, stop this continuation and return to C.29. Do not advance by wording to method selection, planning or Work.

The formula is neither U.Method, U.MethodDescription, U.WorkPlan, dated U.Work, actual U.Transformation, CGUS nor a P2W relation. Imperative grammar and repetition establish none of those objects. The five rows below are a readable display of conditional continuations, not the mantra itself and not a project-work order.

If a selected CGUS already exists, an A.22 demonstrative slice may include this display in its ClaimContent for a declared use. The table itself admits no structure, continuation-row kind, relation occurrence, MethodDescription, plan or Work.

Here and elsewhere in this pattern, move is Plain wording for the exact current use action or continuation: stating a question, applying a direct pattern, keeping its returned result, stopping, splitting or reopening. In another current case it may instead refer to an independently governed recommendation, PlanItem, admitted CGUS continuation, dated Work or actual Transformation. No universal Move object or shared identity connects proposed, chosen and performed work, and wording performs nothing.

The decision aid below helps the practitioner choose the one relation question to answer now. Fill a compact carry-through or replay episteme only when another person or later action must recover the path. The aid shows the accepted claim, concrete question, relation and participants, direct pattern, returned result or stop, and the smallest continuation to reopen after a relied-on result changes.

Choose the first of these three levels that lets the current reader act and any later reader replay the path truthfully:

1. Ordinary conversational use. Repeat the local P2W mantra, state one concrete relation question and its participants, apply the direct pattern, use its result or stop, and finish. Write no P2W note when feedback is fast, the use is local, and nobody later needs to replay the path.
2. Reliance-bearing use. Add the compact episteme in 4.1 when transfer, audit, delayed feedback, expensive reversal, automation, or durable reuse depends on recovering the accepted claim and direct continuation.
3. Structure-bearing use. Add the exact selected structure governed by E.18.3, A.22.CGUS and, for independent members, E.18.NET in 4.0b only when branches, joins, guards, preserved structure, omitted-structure notes, path slices, or neighboring governed positions matter to the receiving use.

Choose a higher level only when its transfer, audit, delayed-feedback, costly-reversal, automation, durable-reuse or explicit-structure need is present. More fields do not improve the subject result and do not substitute for applying the direct pattern.

What is always needed, and what is optional. The stable P2W core is only: one accepted problem-side claim; one receiving decision or use; one concrete relation-specific question; one direct pattern per independent claim; the result or honest stop returned by that pattern; a split when several claims are current; and the smallest local return when a relied-on result changes.

No conditional extension may add a mandatory input to ordinary P2W use, change the kind or identity of a result returned by the direct pattern, or mutate the stable core. When an extension is not needed, omit it rather than filling its fields with generic placeholders.

Assurance scope by use. For a materialized positive episteme, check the accepted ProblemCard edition, carried ClaimGraph slice, decision or use that relies on the result, effective ReferenceScheme, returned result kind and ref, direct pattern, and carry-through rationale. Check a separately identified U.Viewpoint episteme or BoundedModelUseStructure only when the claim designates that object and its organization changes how the receiving claim is interpreted. For a stop use, check that no result was fabricated and that the cue and stop are stated. The episteme is about the accepted ProblemCard under C.2.1, not a P2W relation occurrence or RelationSignature. For practitioner guidance or conformance, verify that the mantra reaches one result or honest stop without making the episteme, structure, reader or checklist perform work. Pattern authoring or review additionally replays the cases, owner boundaries, checklist, and no-new-kind and non-procedural boundaries. None of these checks adds Work, transformation, evidence, gate, MethodDescription membership or downstream subject facts.

#P2W result without a new relation species

An ordinary P2W application is a practitioner move: preserve one accepted problem-side claim, name the receiving decision or use, ask one concrete question per independent relation, and keep only the result or stop returned by the pattern that governs that relation. This move introduces no ProblemToWorkCarryThroughRelation@Context, reusable predicate definition, RelationSignature, or P2W relation occurrence.

When transfer, audit, delayed feedback, costly reversal, automation, or durable reuse requires another person or later action to replay the claim, use the C.2.1 episteme in 4.1. Its identity is its ClaimGraph, the accepted ProblemCard@Context as EntityOfConcern, and the effective U.ReferenceScheme. The ClaimGraph records the accepted card edition and carried claim slice, decision or use relying on the result, concrete question, direct pattern, returned result kind and ref or exact stop, and why the carried content remains relevant. It designates a separately identified U.Viewpoint episteme or BoundedModelUseStructure only when the claim uses that object and its organization changes how the receiving claim is interpreted; neither becomes another identity discriminator. These are use-specific claim contents, not SlotSpecs of another relation species; the returned result retains its own kind, relation semantics when applicable, identity, and direct pattern.

The conversational, transfer, audit, delayed-feedback, automation, and durable-reuse cases in this pattern need a truthful, replayable claim; none asks whether repeated P2W relation occurrences are the same individual. The conversational move, optional positive note, and stop description therefore close those uses without a relation-kind candidate. A.6.RCD, E.24, E.24.UK, A.6.0, and relation-species naming do not open. If a later use asks whether a P2W relation occurrence persists, recurs, ceases, or participates in another relation, reopen A.6.RCD and obtain the direct subject settlement and admission before declaring or instantiating such a kind.

A positive use closes only when the accepted card and carried slice remain current for the receiving use, the direct pattern has returned its result for that use, and the rationale remains a truthful claim in the note or is directly recoverable in conversation. A preceding P2W note may be cited for replay, but it supplies neither occurrence continuity nor a supporting relation; any relation among returned values remains governed by its own direct pattern. If these conditions fail, correct the value-kind pair, apply the actual direct pattern, split the claims, or retain a reduced-use cue and stop.

#P2W Declarative Carry-Through Structure

Use P2W as a declarative interface from one accepted ProblemCard@Context claim to results or stops returned by direct patterns. P2W preserves the carried claim and receiving use, states the concrete question, cites the selected relation and direct pattern, and keeps each returned result or honest stop on a separate continuation. It owns none of the selected relations or results and does not reproduce how a neighbouring pattern identifies, derives, admits, or evaluates its subject.

The table below is the complete P2W-local decision aid. It asks only what result or blocker the direct pattern returned for this use; it does not copy that pattern's test, derivation, or admission method.

When the conditional structure extension opens, recover one admitted A.22-selected CGUS and, under E.18.3, the independently identified E.18 substrate positions, bindings, already-obtaining occurrences, and any relation-reference epistemes needed for replay. The exact condition basis—an applied claim with its test and current facts, an E.18 GuardFail event with its gate-assignment facts, or an independently defined obtaining guard-relation occurrence—supports an ordinary stop or reconsideration question; no return relation follows from the pattern reference. P2W keeps only its accepted claim, current use, one direct-pattern result or honest stop, split, and smallest affected continuation; it adds no structure field. Plain actions such as carry, recover, write, split, stop, and return guide this P2W use. They are not P2W relation kinds, commitments, permissions, gates, or substitutes for the direct pattern's rules.

#Conditional structure extension through E.18.3

Open this extension only when the reader must show explicit branches, joins, guards, paths, preserved structures, omitted-structure notes, or distinct stop and reconsideration questions. Identify one exact U.Structure under A.22.CGUS by its independently identified constituents, selected obtaining relation occurrences, applied constraints, and named selection-use frame. E.18.3 qualifies that selected CGUS only when it uses exact positions, bindings, and already-obtaining occurrences from one independently identified E.18 one-TFS, parent-relative internal-SubflowRef, or E.18.NET substrate. E.18.1 declares no P2W subset schema, wrapper relation, or hybrid record.

Before choosing the structure branch, distinguish three cases. Several FlowValuation values that resolve to one exact TransformationFlowStructure remain valuations of that one TFS. A detailed internal portion that resolves only through the same TFS positions and internal U.Transfer occurrences remains one parent-relative SubflowRef. Two or more independently identified TFS or nested-network values connected across their boundaries by exact already-obtaining relations require one E.18.NET TransformationFlowStructureNetwork; do not flatten them into one giant TFS. Every network member retains its own boundary, Work, actual transformations, valuations and leaf-local position binding or DesignRunTag. Each nested boundary reference resolves through one finite acyclic memberPath[] to an exact ExposedFlowPositionRef; each selected cross-boundary claim cites its exact obtaining occurrence and complete ordered endpoint bindings through one resolvable NetworkCrossFlowRelationRowRef. Membership is acyclic, while directly governed feedback relations may cycle.

If explicit structure is not required, use the stable conversational core. If replay but not structure is required, use 4.1. If the next question is work-facing, apply the A.15 family before claiming a plan, readiness, launch or dated U.Work. A.3.4 owns each actual transformation and A.15.PROD owns only the exact production-work, identity-inception or completion claim currently made. G.11 handles source currentness; E.18 handles one-TFS slice-local refresh; E.18.NET handles independent members and exact cross-member occurrences. P2W reopens only the smallest affected application.

#Compact carry-through episteme (conditional reliance extension)

Open this extension only when transfer, audit, delayed feedback, expensive reversal, automation, or durable reuse requires someone to replay the stable P2W core. Materialize one ordinary C.2.1 episteme whose exact EntityOfConcern is the accepted ProblemCard@Context, whose ClaimContent is the current positive or stopped carry-through account, and whose effective ReferenceScheme governs its designations. Carry-through note and stop description are Plain use labels for those two ClaimContent shapes, not local U-kinds or relation species.

carryThroughClaimContent:
  acceptedProblemCardEditionRef
  carriedProblemCardClaimSlice
  receivingDecisionOrUse
  nextPracticalQuestion
  directGoverningPatternRef: exact governing-pattern identifier or reference
  returnedResultKindRef?: exact kind returned by that pattern
  returnedResultRef?: exact positive result, relation occurrence, assertion or description
  honestStop?: exact blocker or reduced-use cue returned by that pattern
  carryThroughRationale
  localNonOverread?
  precedingCarryThroughEpistemeRef?: replay/source pointer only, with an exact relation when continuity or derivation is claimed
  continuationDescriptions[]: one direct pattern and one question or use per continuation
  returnCondition?

A positive use fills the exact returned result and leaves honestStop absent. A stopped use fills the returned blocker or reduced-use cue and fabricates no positive result. When the claim uses a separately identified U.Viewpoint episteme or BoundedModelUseStructure and that object's organization changes how the receiving claim is interpreted, the ClaimContent designates it; otherwise no surrogate field is filled. A governing-pattern ref is not thereby a U.MethodDescription. The episteme, its claim and its predecessor pointer are neither a reusable predicate definition nor a P2W relation kind or occurrence.

A positive use is well formed only when the named result kind is one that the direct pattern actually returns for the stated question, the carried ClaimGraph content remains relevant to the receiving use, and every independent continuation stays separate. When the result is a relation occurrence, assertion or description, cite that exact object; the direct pattern retains its obtaining or claim basis, occurrence-identity rule and any receiver-conditioned reusable declaration or typed SlotSpecs. A predecessor pointer supports replay only and establishes neither episteme continuity nor another occurrence.

For first-minute use, state the question, apply the direct pattern, and continue with its result or stop without materializing this episteme. Materialize it only when replay is required. Each continuation names one direct pattern and one question or use that its result answers. Do not combine value kind and relation signature, method and mechanism, evidence and assurance, plan and dated Work, actual Transformation and production, or refresh and residual triage in one field.

The use closes positively when the direct pattern has returned its positive result and the carried problem-card claim remains visible in that result or its stated basis. It closes by bounded stop when the direct pattern returns a blocker or reduced-use cue and no positive continuation can be stated.

#Conditional development-loop relation-selection extension

Open this didactic extension only when cheap generation, open-ended search, or evolutionary-engineering work has produced many variants before the project has a stable problem, comparison basis, selected set, work entry, or currentness relation. Apply the unchanged P2W core to the one question that changes the next action. The four rows below are discriminators, not an owner catalogue; use the single map in Relations only after the question is stated.

If the current question is still problem formulation or opportunity, return first to C.22.2 to accept or revise the ProblemCard@Context and its carried claim. That is an upstream return, not another downstream P2W result.

Cheap variant generation shifts effort toward problem production, characterization, archive stewardship, fair comparison, explicit choice, autonomy boundaries, evidence, assurance, performed work, effect measurement, currentness, and repair. P2W preserves the accepted problem-side claim while one of those relations becomes current; an archive, front, selected set, confidence phrase, or choice rule supplies neither an A.2.8.PER permission result nor performed work. Source wording such as trust budget, problem factory, solution factory, or factory of factories remains a project label until the evidence, assurance, autonomy, work-organization, or other direct relation is named.

#Conditional development-for-developed first-minute extension

Open this didactic extension only for a fast DPF seed, and keep the source-use and hardening continuations distinct. An accepted problem-side record may cite a G.2 source-use relation, source U.EpistemePublication, source-pack cue or return, and provisional framework purpose. E.4.PFAD, E.4.PFR, E.8, E.21, E.23, and G.11 govern their own proposal, review, authoring, evaluation, improvement, and currentness values. P2W preserves the carried claim only until one of those exact relations is selected.

Cooling-module example. ProblemCard@Context PC-DEV-041 states that cheap generation produces many cooling-module layouts while fair problem framing and comparison remain weak. The carried claim is that the current candidate set retains maintainable low-energy variants until energy use, service access, manufacturability, thermal margin, and test cost are represented in the current characteristic and comparison relations. A C.18 archive and front are current now. A.19 governs the characteristic space and its comparability boundary; A.19.CPM comparison becomes current only when that characteristic space and comparator are current. G.5 selected-set publication remains stopped until that comparison and front are current. An E.16 generator boundary may separately bound search and test spending. Prototype observations enter through A.10; assurance-sensitive confidence use enters through B.3. A C.30 architecture-candidate relation appears only for retained layouts that change selected structure. A.15.2 has not yet produced a U.WorkPlan, and A.15.1 has not yet admitted a dated U.Work occurrence. Thermal and serviceability measurements can feed but cannot create three separate results: A.15.5 may return WorkEntryReadiness@Context for one named intended-work concern; A.21 may publish GateDecision only for one current OperationalGate(profile) and its declared checks; A.2.8.PER may return one named non-prohibition, granted-permission, permission-exercise, non-violation, or permission-conflict result with its required participants and basis. An actual release action is an A.15.1 U.Work occurrence; a further claim that a subject was released needs its named subject predicate and participants. No such release predicate is current in this example, so an approved, authorized, or released cue stops as missing-governor for that attempted use rather than inheriting the measurement, readiness, or gate result. G.11 reopens currentness-dependent continuations when descriptors, tests, competitor information, or cited publication editions change.

The current next relation in this example is the C.18 front record. Architecture comparison, selected-set publication, planning, and work are possible later continuations, not alternative fillers of one field.

#Conditional naming and publication extension

Ordinary P2W use skips this extension. Open it only when a pattern author, publisher, trainer, or tool builder must cite the already governed practice outside its local use. The header's Tech/Plain pair identifies this pattern for readers: ProblemToWorkCarryThrough / problem-to-work carry-through. It does not classify a U.Method, U.MethodDescription, relation, Work or result. The selected name keeps the work-facing receiving use visible without implying a generic governed-value endpoint, a linear continuation or path, unchanged preservation, or a principle-only source; it is the widened successor to Principles-to-Work Carry-Through. If MethodDescription membership is actually needed, first identify one C.2.1 episteme, require one independently admitted U.Method as its exact EntityOfConcern, and apply the A.3.2 substantive way-of-doing claim threshold.

The compact positive, stop and replay shapes in 4.1 and 4.8 are local ClaimContent uses of ordinary C.2.1 epistemes. Their field labels are local phrases, not reusable U-kinds, NameCards or term rows. Before any external citation or tool-interface reuse, F.8 decides whether a name is needed; F.18 settles the name only for that exact governed value and use; F.17 publishes the exact scheme-local sense and source basis. F.9 opens only if two independently identified scheme-sense cells require an exact Bridge. No Bridge is current merely because two readers use similar P2W wording.

Keep the practice, pattern episteme, any admitted Method, any qualifying MethodDescription episteme, local carry-through episteme, publication occurrence, publication form and presentation carrier separate. Naming or publication admits none of them and adds no stable-core field. Reopen only the smallest direct owner: a changed practice or practitioner use reopens E.18.1; changed wording or public reader use reopens F.18/F.17; changed source basis reopens its exact source-use relation; changed publication occurrence, form or carrier stays with E.17/E.24.PUB. A source phrase or remembered title supplies no source-to-use relation, authority, evidence, result or performed Work.

#Positive carry-through: one executable first use

Use the first three rows for an ordinary case. Open the fourth only when the source sentence contains the additional claim. Other relation families use the same branch rule in 4.6; consult the single owner map in Relations only for the relation actually being asserted.

This example exercises the ordinary route: one carried distinction, one concrete question, one map lookup, one result from the direct pattern, and one visible stop. A case with several claims splits before any direct pattern is applied; a case with only a cue stops under 4.6.

#Direct-relation distinctions that change the branch

P2W carries a returned value or stop; it does not restate the neighboring pattern's internal test. Keep a local distinction here only when it changes which branch the reader takes:

• Lens or declaration? Ask whether the current use judges a mathematical representation or declares a governed signature. Split the claims when both are present; the first-use case in 4.2 shows the difference.
• Mechanism or method? Ask whether the claim states a law-governed operation application or a reusable way of doing. A shared noun supplies neither; split the questions and use the owner map once for each current claim.
• Change or timing? Ask whether the claim is one actual bounded change, one temporal aspect such as an interval or cadence, or a judgment that a temporal claim is adequate for use. A timestamp or before/after picture supplies none of those answers; split the questions before continuing.
• Work, change, or their connection? Identify the dated U.Work occurrence and actual U.Transformation separately. Continue with a work-to-change claim only when a named subject predicate with those participants obtains or an A.6.RCD disposition-2 local compound claim states the base facts; otherwise return missing-governor for the pair. The BuildOps and current Pump 14 slices in 5.1 show positive results; Pump 14 also shows the explicitly earlier stop in a case record that lacks its project declaration.
• Approved, ready, released, or permitted? State the intended result before looking it up: gate decision, permission result, work-entry readiness, release U.Work occurrence, or a subject release relation. Carry the one result that its pattern returns. If a stronger subject predicate cannot be named, preserve the cue and return missing-governor; authorization is not a result type.
• Result or production? Let A.6.P.WMR separate the concrete result claims. Open A.15.PROD only for a selected production-work, entity-inception, or production-completion question; its local claim remains separate from work, change, delivery, acceptance, and release.

For every other exceptional object, state the relation-specific question and consult the canonical map in Relations. A label, diagram, note, plan, trace, or familiar noun can trigger that question but cannot answer it.

#Boundary and relation discipline

P2W does not repeat the boundary rules of neighbouring patterns. Its local rule is simple: carry only the accepted problem-side distinction, state the next relation and participants, apply its direct pattern, and continue only with that pattern's result or honest stop. Split several relation claims; if no relation can be stated, retain the cue and stop.

An owner-specific detail appears outside Relations only when one local discriminator in 4.3 or one worked case needs it to choose, split, or stop. Section 4.6 is the plain branch rule; Relations is the only object-to-owner map. Neither place restates a neighbour's occurrence basis, recovery algorithm, production criterion, derivation method, or admission law.

A local P2W application closes positively when the direct pattern has produced or amended its result and the carried distinction remains visible in that result or its stated basis. It closes by bounded stop when no continuing relation can be recovered and the reduced-use cue plus stop condition are stated. A following method selection, planning act, work occurrence, evaluation, or other direct-pattern use is not unfinished P2W work.

A wider P2W carry-through slice remains current only while a named downstream receiving use relies on the accepted problem-side distinction. It closes when no remaining receiving use relies on that distinction and no return condition is current. A later changed assumption opens a new local return to the smallest affected application rather than retroactively keeping every earlier application open.

#Return and refresh rule

Reopen the relation that supplied the changed value, then only the continuation that relied on it. Do not replay the whole carry-through.

A dated occurrence already admitted as U.Work remains the same world-side occurrence. Return may change a later interpretation or plan; it does not rewrite that occurrence retrospectively.

#Plain relation-selection branch

First say the unsettled question as one ordinary sentence: "Did this work change that pressure here?", "Does this grant let this technician do this work now?", or the equally concrete sentence for the current case. Then name the participants and relation that sentence asserts and take one row. Do not scan every pattern first.

The ordinary case closes after the first row. The canonical owner map is for locating that one pattern or checking an exceptional branch; it is not a checklist to traverse.

#Lowering and reopen block

Lower only the claim that cannot be made. Keep any independently grounded value and preserve the practical question that would reopen the branch.

#Conditional reliance replay after a direct-pattern value changes

Open this extension only when transfer, audit, delayed feedback, costly reversal, automation, or durable reuse requires a durable account of what still follows after source-currentness repair, appearance-based reliance repair, changed measurement, changed problem-side record, FPF pattern change, or a use-found defect. An ordinary local return uses 4.5 and creates no replay episteme.

Materialize one ordinary C.2.1 episteme whose EntityOfConcern is the accepted ProblemCard carried by the original carry-through episteme, whose ClaimContent is the replay account below, and whose effective ReferenceScheme governs its designations. Replay note is Plain wording for this use, not a local U-kind, refresh process, change log or authority record.

replayClaimContent:
  originalCarryThroughEpistemeRef
  changedValueRef
  changedValueKindRef
  changedValueDirectGoverningPatternRef: exact pattern identifier or reference
  stillCarriedClaimSlice
  noLongerCarriedClaimSlice?
  smallestReopenedContinuation
  refreshCurrentnessLineRef?: exact current G.11 episteme or relation
  nextDirectGoverningPatternRef: exact pattern identifier or reference

Reapply the changed value's direct owner before filling the replay episteme. If the changed object is a relation, recheck it under that owner and [A.6.REL](/generated/patterns/A.6.REL). The direct result keeps its participants, obtaining or claim basis, occurrence-identity rule and any reusable RelationSignature or typed SlotSpecs. The replay account records only what still follows, what no longer follows and which P2W continuation reopens. A governing-pattern reference is not a MethodDescription.

P2W may cite a readable relation assertion, an explicitly individuated occurrence, or a typed assertion or description, but it cites the exact object returned by the direct pattern. Citation does not make relation use signature-dependent; a receiving episteme carries a signature reference only when its own direct pattern requires one.

The changed object may instead be a source edition, measurement, unit, reference plane, Method set, comparator, module-interface relation, publication-use relation, problem record or FPF pattern publication. Whatever changed keeps its own kind and owner. Add a [G.11](/generated/patterns/G.11) line only when one exists. The next direct pattern decides whether to continue, stop, split, retain a reduced-use cue or return upstream.

#Archetypal Grounding

#Seal-failure carry-through

A maintenance team has an accepted ProblemCard@Context for recurrent seal failure. It records the operating conditions, the distinction between thermal deformation and material degradation, and the observations that would challenge that distinction. The team uses E.18.1 because diagnostic-method selection, repair planning, dated repair work, interpretation of the post-repair measurements, and return after a changed diagnosis all depend on preserving these accepted problem-side distinctions.

E.11.PUA may help the team inspect and apply one diagnostic-pattern candidate inside this flow. Its result might be one fit finding or one diagnostic method-selection input. That smaller result does not replace the accepted problem material, the repair plan, the repair work, or the later interpretation and return relations.

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

#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. The practitioner preserves that claim, applies C.29 for the mathematical-lens question, and carries the returned lens-use value or stop. A separate formal-declaration question opens under A.6.0 and returns its own declaration result or stop; method selection waits for its own relation and participants.

2. Planning from selected enough method. A method family is selected enough for planning. The practitioner applies A.15.2; any compact P2W note cites the planning result returned there and the problem-side claim it preserves. The WorkPlan retains its own content and authority.

3. Performed work after planning; filled positive connection. Readable result: the named build U.Work occurrence populated the named artifact-store partition; that occurrence and the store change are connected by the declared BuildOps predicate, not by timing or the word build. A.15.1 grounds ReleaseBinary12_BuildWork_2026-07-21T0900_0912 : U.Work. A.3.4 separately grounds ArtifactStorePopulationTransformation_12 : U.Transformation as the 09:00-09:12 change of ArtifactStorePartition_12 from no stored ReleaseBinary_12 to stored ReleaseBinary_12 under BuildOpsStoreScheme-v12. Predicate-definition episteme BuildWorkPopulatedStore@BuildOps-v12(work, transformation) holds only when that U.Work occurrence performs the governed storeWrite application that changes the same partition. BuildApplication_12 supplies that performed application and its builtBinary -> ReleaseBinary_12 binding, so C.2.1 assertion BuildWorkPopulatedStore-12 carries the positive local work-to-change claim under A.6.RCD disposition 2. P2W keeps the work occurrence, transformation, and assertion separate. If the predicate or one required base fact is absent, this connection stops instead of becoming a universal work-to-change kind.

4. Result interpretation without generic result. The sentence the work result proves the approach worked does not yet name a result. Ask what can actually be asserted. A.6.P.WMR may return a direct subject claim, an A.6.1 application binding, a local A.15.PROD or A.6.RCD claim, or a bounded non-assertability result. P2W carries only the returned item. factually unsupported and missing-information stop an unsupported or underinformed claim; missing-governor identifies the absent predicate for the stated participants and use. None becomes a generic result or production value.

5. Functional explanatory order. A source diagram places formal declaration, principle framing, mechanism, normalization, method selection, planning, performed work, and result measurement in one readable order. The diagram helps recognize candidate continuations, but P2W carries only values returned by their direct patterns; the display order supplies no sequence or authority.

6. Interface split before P2W use. A source says a port-throughput limit makes a solution feasible after integration. The practitioner opens separate A.6.M module-interface and E.18 transformation-flow questions. Planning, work, evidence, gate, function, and architecture cues remain stopped until their relations are asserted. Conversational P2W use or the compact note carries only the direct-pattern result that changes the present decision.

7. Result measurement returns to planning. A source says one U.Work occurrence produced telemetry and an artifact. First use A.6.P.WMR to separate the artifact binding, telemetry claim, and any production or unsupported claim; P2W carries those results on separate continuations. If later C.16 measurement changes the reference plane used by planning, reapply C.16 and G.11, then reopen only the planning, method-comparison, or problem-side continuation that used that plane. The earlier dated U.Work occurrence is not rewritten.

8. Pump 14 pressure adjustment; governed continuation after an earlier stop. Readable result: the current case record supports W-P14-ADJUST-1010-1020 caused T-P14-PRESSURE-RISE under AdjustmentWorkCausesPressureRise; P2W carries that returned result rather than inferring it from timing. Exact basis: PumpTeam-14 : U.System performs W-P14-ADJUST-1010-1020 : U.Work under assignment RA-P14-ADJUST, enacts SetPointAdjustment@PlantOps-v3, and works in PumpStation-14 from 10:10 to 10:20 under A.15.1. Independently, A.3.4 returns T-P14-PRESSURE-RISE : U.Transformation as the bounded change of continuing HydraulicLoop_P14, whose discharge-pressure characteristic changes from belowBand to inBand over the same interval. Relation-declaration episteme P14-REL-2026, owned by Pump14OperationsRelations, declares AdjustmentWorkCausesPressureRise for those exact participants, and a separate case fact satisfies its actual-causation predicate. In the explicitly earlier case record, P14-REL-2026 is absent; at that epistemic stage, keep the Work and transformation separate, return missing-governor: work-to-change claim for <W-P14-ADJUST-1010-1020, T-P14-PRESSURE-RISE>, and route the missing declaration to Pump14OperationsRelations. The separate claim that PC-P14-PRESSURE guided WP-P14-2026-07-15 remains missing-governor under A.6.P.WMR; neither the problem claim nor shared timing causes the Work. Later measurement and decision uses remain separate; no production or transformation-composition question opens.

#Additional worked situations

#Pilot examples for transformation-flow structures and networks

These pilots are grounding checks, not source terminology to import. Before using one, decide which of three ontic cases is current: several valuations or path slices of one exact TFS; one parent-relative internal SubflowRef; or an E.18.NET network of independently identified TFS or nested-network members connected by exact already-obtaining cross-boundary relations. A diagram, common product, display order, shared Work or source wording decides none of them.

For one TFS, every valuation resolves to the same structure boundary and internal U.Transfer occurrences. For a network, every member retains its own boundary, Work, actual transformations, valuations and leaf-local position binding or DesignRunTag; exact cross-flow occurrences retain their direct governors, signatures, participant order and endpoint bindings. Membership is acyclic; directly governed feedback may cycle. Use a pilot to check the carried object's exact member-local position, the direct relation that crosses a boundary when one exists, and the smallest reopened member or continuation.

#Filled P2W carry-through notes

Use these as replayable filled examples, not as a second schema beside the compact note in 4.1.

Cooling-loop mathematical-lens continuation.

Port-throughput continuation split.

#Bias-Annotation

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

• Governance bias (Gov): permission, gate, release, assurance, and decision cues remain local cues until the relation and participants are stated: an A.2.8.PER permission result, A.21 GateDecision, A.15.1 release U.Work occurrence plus any required named subject release predicate, B.3 assurance result, or direct decision result. The word authorization supplies none of them.
• Architectural bias (Arch): diagrams, selected structures, and module-interface language help formulate the next relation question; they do not replace the accepted claim, receiving use, separately governed viewpoint or model-use participant, direct pattern, or returned result.
• Ontological and epistemic bias: a source publication, diagram, compact note, or formal declaration remains separate from the subject EntityOfConcern and from the relation or result claimed through its direct pattern.
• Pragmatic bias (Prag): the carry-through structure is useful for action without becoming a prescribed project procedure.
• Didactic bias (Did): the local P2W mantra and positive carry-through structure come before the heavier relation aids, so precision does not bury the working P2W application.

#Conformance Checklist

• CC-E18.1-1 The P2W use starts from an accepted ProblemCard@Context or stops before P2W begins.
• CC-E18.1-1a The accepted ProblemCard as the note's EntityOfConcern, the note's ClaimGraph and effective ReferenceScheme, any separately governed U.Viewpoint or BoundedModelUseStructure designated by that ClaimGraph, each direct pattern's subject EntityOfConcern, and every supporting compact note, diagram, plan, trace, or publication remain distinct. Note completeness does not prove a P2W relation occurrence, subject change, performed work, evidence, acceptance, or result.
• CC-E18.1-1b Every materialized carry-through episteme identifies one accepted ProblemCard as EntityOfConcern, carries one ClaimContent for the receiving use, names its effective ReferenceScheme, and designates a separately identified U.Viewpoint episteme or BoundedModelUseStructure only when the claim uses that object and its organization changes how the receiving claim is interpreted. It cites the carried ProblemCard slice, exact governing-pattern identifier or reference, returned value kind and ref or honest stop, and rationale. It introduces no reusable P2W predicate, RelationSignature, relation kind, local note kind or occurrence.
• CC-E18.1-1c When external naming or publication is current, F.8/F.18/F.17 apply only to the exact already governed value and receiving use. The pattern label and local positive/stop/replay phrases create no NameCard, U-kind, relation, Method or MethodDescription. Any MethodDescription claim separately passes the exact A.3.2 EntityOfConcern and substantive-claim threshold.
• CC-E18.1-2 A positive carry-through ClaimContent cites one exact returned result and one or more separate continuation descriptions. A stopped ClaimContent instead states the reduced-use cue or blocker and stop without fabricating a relation. Local non-overread and return conditions appear when relied on; absent fields are not filled by generic unions.
• CC-E18.1-3 The stable core works without an episteme or explicit structure: accepted claim, receiving use, concrete question, direct pattern, returned result or honest stop, split, and smallest local return. When explicit structure is needed, A.22.CGUS and E.18.3 select the exact structure; E.18 keeps several valuations or one internal SubflowRef on one TFS; E.18.NET keeps independently selected flows or nested networks and exact cross-member occurrences. E.18.1 adds no hybrid schema.
• CC-E18.1-4 One wording span from an admitted source 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 references keep postulates and CHR observability distinct from units, planes, comparators, thresholds, ontology editions, CHR editions, plans, work, evidence, and gates.
• CC-E18.1-7 Measurement, G.11 source-currentness relation, reference-plane, method-set, comparator, or problem-side changes return to the smallest affected application.
• CC-E18.1-8 The stable P2W core contains only accepted claim, receiving use and concrete question, direct pattern, returned result or honest stop, split, and local return. Reliance notes, explicit E.18.3 structure, development examples, and naming or publication are optional extensions. No extension may add a core input or change a returned result. Relation obtaining and identity, occurrence declarations, admission, production, evidence, gates, decisions, and other neighbouring algorithms remain with their direct patterns.
• CC-E18.1-9 Local boundary wording remains only where it names a near-miss that changes the next P2W application.
• CC-E18.1-10 The pattern leaves one usable next move: apply the direct pattern and use its result, write a compact note when another person or later action needs replay, split independent claims, keep a cue and stop, or reopen only the continuation affected by a changed relation.
• CC-E18.1-11 For a structure-bearing conformance or authoring use, replay at least one pilot from 5.3 and classify it as several valuations of one exact TFS, one parent-relative internal SubflowRef, or one E.18.NET network of independently selected members and exact cross-boundary occurrences. Keep every member boundary, Work, actual transformation, valuation, position binding and DesignRunTag local. The self-evolving-spec case keeps use-found evidence outside practitioner-facing prose. Ordinary P2W use does not open this extension.
• CC-E18.1-12 Every carried claim family can be lowered, stopped, split, or reopened through E.18.1:4.7; a cue from a wording span in an admitted source or from a source-pack cue that cannot name the recovered FPF kind or relation remains a reduced-use cue.
• CC-E18.1-13 Every materialized replay identifies the changed value, occurrence, assertion, or description; its kind and direct pattern; what still carries and what no longer carries; the smallest reopened continuation; any current G.11 currentness line; and the next direct pattern. If the changed object is relation-bearing, the cited direct result—not a P2W copy—retains its kind, participants, obtaining or claim basis, occurrence-identity rule, and any receiver-conditioned RelationSignature or typed SlotSpecs.
• CC-E18.1-14 When a generated DPF seed or cheap framework seed enters P2W, the record names the G.2 source-use record, source U.EpistemePublication reference, source-pack cue, or source-pack return when that source use is current, the problem-side cue when that is current, the next governing relation (G.2, E.4.PFAD, E.4.PFR, E.8, E.21, E.23, G.11, or another direct governing pattern), and the stop condition that prevents the seed from becoming public authority by generation alone.
• CC-E18.1-15 An actual-transformation continuation carries only an exact current value or blocker returned by A.3.4; E.18.1 does not reconstruct the occurrence basis or infer actuality or composition from a method, plan, model, description, flow position, adjacency, shared work, or common referent.
• CC-E18.1-16 A work-to-change continuation carries a named subject predicate with its actual U.Work and U.Transformation participants, a positive A.6.RCD disposition-2 local compound claim over governed base facts, or missing-governor for that pair. The BuildOps and current Pump 14 replays supply positive branches; Pump 14 also preserves the explicitly earlier missing-governor stage in a case record that lacks P14-REL-2026. A production continuation separately carries only the local result or blocker returned by A.15.PROD. E.18.1 reproduces none of those patterns' internal criteria.
• CC-E18.1-17 A governing-pattern ref, selected or recommended continuation, imperative wording, intended realization, plan seed, graph or filled table admits no U.MethodDescription. Membership exists only for an independently identified C.2.1 episteme whose exact EntityOfConcern is one admitted U.Method and whose ClaimContent contains at least one substantive way-of-doing claim.
• CC-E18.1-18 Move remains Plain wording for the exact current object or use action. Proposed or chosen work remains distinct from dated performed Work; no universal Move kind, record or relation is introduced, and wording performs nothing.
• CC-E18.1-19 The local mantra is the compact formula in 4, answers one stated decision, maps every term to governed values, has the filled cooling use, and stops at the exact neighboring owner. It is not the five-row display, a Method, MethodDescription, plan, Work, CGUS or structure identity.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

E.18.1 is a child of E.18 because a P2W use may need transformation-flow structure when the accepted claim spans several slices, typed positions, or returns. It does not define graph semantics or prescribe performed-work order. It helps a practitioner keep the accepted claim visible while selecting and applying the next direct pattern; that pattern, not P2W, produces or amends the result.

Stable core and optional apparatus. Preserve the accepted claim for one receiving decision or use, ask a concrete relation question, apply the direct pattern, keep its result or honest stop, split independent claims, and return only to the smallest affected continuation. Reliance notes, E.18.3 structure, development examples, and naming or publication open only for their stated uses and do not change that core. Relation occurrence, declaration, admission, production, evidence, gates, decisions, and other neighbouring rules remain in their direct patterns. This separation preserves the predecessor's problem, declaration, method, plan, work, result, evidence, currentness, and return functions without reviving its mega-record or putting apparatus before the first action.

#SoTA-Echoing

The sources below are current comparators for specific P2W moves, not authorities imported by reputation. Each row states what changed in the Solution and which overread remains blocked.

The synthesis that combines these moves into one P2W carry-through discipline is an FPF-scoped architectural hypothesis, not established SoTA. The sources support the problem-first, relation-separated, replayable moves named in their rows; they do not establish that P2W is a universal workflow or that one carry-through claim is sufficient for every downstream claim. The hypothesis is limited to one accepted problem-card claim, one stated decision or use that needs it, and one result or stop from the direct pattern. Outside that boundary, apply the direct pattern, split independent claims, or stop.

As of 2026-07-21, the Jiao article, QD survey, manufacturing digital-thread papers, Modelica 3.7, and Dyad 3.2 documentation are publication or practice anchors. Dyad 3.2 is a minor continuation of the 3.1 foundation with no source-level migration, so the selected component, relation, and analysis distinction remains current. The DGM paper is a recent system result; the 2026 EvoTrace and harness papers are current preprints and carry corresponding uncertainty. Reopen these adoptions when stronger studies change problem-first method selection, distinguish generated structural novelty differently, revise evaluator-hack controls, alter QD archive semantics, or show that digital-thread continuity warrants a stronger use than the exact direct relation currently supports.

#Relations

• Under A.22.CGUS, identify the one constraint-governed unfolding structure when P2W exposes typed structure positions, constraints, admissible next forms, and stop or reconsideration questions.

• E.18.3 qualifies that exact A.22-selected CGUS through positions, bindings, and already-obtaining occurrences from one independently identified E.18 substrate. E.18 defines the one-TFS and parent-relative internal-SubflowRef interfaces; E.18.NET defines independently identified network members and exact obtaining cross-member relations. P2W cites those exact values, adds no subset, reciprocal record, or hybrid structure schema, and neither reidentifies nor routes them.

• G.2 governs source-use records, source-pack return, evidence anchors for admitted source publications, and source-currentness payloads before DPF hardening can rely on a seed drawn from those admitted sources.

• E.4.DPF, E.4.PFAD, and E.4.PFR govern DPF authoring, framework architecture decisions, and framework relation records when a generated or cheap seed is carried toward hardening.

• E.23 governs repeated quality improvement only after the object version and evaluation are recoverable; P2W may carry a seed to that point but does not become the improvement method.

• G.11 governs currentness, admitted-source decay, source-use relation change, edition change, and refresh when a changed source publication, source-use relation, or telemetry reopens the smallest affected P2W application.

• 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.

• A.6.P governs recovery and readable statement of each direct relation. A.6.REL governs direct obtaining, occurrence individuation, and receiver-conditioned use of any reusable RelationSignature; P2W cites the occurrence, assertion or description returned there and copies none of that doctrine into ClaimContent. A.6.RCD, E.24, and E.24.UK govern any later P2W relation-kind candidate and admission, while A.6.0 declares a RelationSignature only after that settlement. F.8/F.18/F.17 open only when an external naming or publication use is current; the header's Tech/Plain pattern label and local note-field phrases create no NameCard, term row, U-kind, relation or MethodDescription. Canonical object-to-owner map. Read each arrow independently; the row order is not a declaration or work sequence.

#E.18.1:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)