#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 blocker boundary and local-claim dispositions, 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 whose Solution answers that relation-specific question. 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. For each, state the exact current question and apply the pattern whose Solution answers it; carry only the returned result or honest stop. P2W introduces no relation kind or occurrence and is neither dated work nor a U.Transformation. Citing a PatternID, selecting a continuation, recommending an action, writing an imperative, or stating an 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, the accepted 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. Each cited PatternID locates the Solution passage needed for the question about its subject EntityOfConcern. A practitioner or another capable system applies that guidance to the project entity or relation—for example, a System, episteme, Method, Work occurrence, or direct relation. When source wording says role, apply E.10.ROLE before treating it as a local system-role kind, separate System-classification judgment, assignment occurrence, participation or functioning relation, ordinary non-use, or missing-governor case. The compact note, diagram, plan, trace, and publication are epistemes or publication-side values that describe, constrain, or make those 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 whose Solution answers that question. 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 pattern whose Solution answers the current question.

E.11.PUA covers a smaller use and may begin without ProblemCard@Context: use one selected pattern for one current practical question and reach the smallest useful result that truthfully answers it, or an honest stop. That ordinary use may stop there; name a receiving use only when the enclosing P2W continuation or another actual later use is current. 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 wording cue, 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; recover the relation and apply the pattern whose Solution answers that exact evidence, assurance, gate, decision, description, publication-use, or wording question.

#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, unresolved functional role cue, mechanism-position candidate, method candidate family, planning constraint, result cue, or changed measurement assumption. Route that cue through E.10.ROLE before it affects a continuation; the recovered local system-role kind, classification, assignment occurrence, direct participation or functioning relation, ordinary non-use, or exact missing governor remains with its own pattern. 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, applicable pattern contribution, 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 the pattern for that relation — 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, keep that C.29 question open and 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 current use action or continuation: stating a question, applying the pattern that answers it, keeping its returned result, stopping, splitting, or reopening. In another current case it may instead refer to an independently defined recommendation, PlanItem, enabled continuation of a qualified CGUS, 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, pattern contribution that answers it, 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 pattern that answers it, 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 defined and tested 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 identified 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 pattern whose Solution answers the question.

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 pattern contribution 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 cited 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, the particular cited pattern contribution used, 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, neighboring-pattern 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 whose Solution answers that question. 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, applicable pattern reference, particular contribution used, 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 subject-specific basis.

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 cited 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; use each relation's defining predicate and identity rule. If these conditions fail, correct the value-kind pair, apply the pattern that actually answers the question, 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 obtained by applying the patterns that answer its continuation questions. P2W preserves the carried claim and receiving use, states the concrete relation-specific question and its participants when relation-like, cites the applicable pattern, and keeps each result or honest stop on a separate continuation. It defines none of the selected relations or results; it cites rather than reproduces the neighbouring guidance.

The table below is the complete P2W-local decision aid. It asks only what result or blocker the applicable 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 returned 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 cited 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; a feedback relation may cycle only when its exact predicate and occurrence facts permit that 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. Use A.3.4 for each actual transformation and A.15.PROD only for 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
  applicablePatternRef: pattern whose Solution answers nextPracticalQuestion
  contributionUsed: particular definition, admission, selection, method, decision rule, publication rule, returned result, or other concrete contribution used in this case
  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 question or use, applicable pattern reference, and particular contribution used 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. Citing a PatternID does not thereby admit 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 cited 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; keep its obtaining or claim basis, occurrence-identity rule, and any receiver-conditioned reusable declaration or typed SlotSpecs with that returned object under the pattern content that defined or tested it. A predecessor pointer supports replay only and establishes neither episteme continuity nor another occurrence.

For first-minute use, state the question, apply the pattern that answers it, and continue with its result or stop without materializing this episteme. Materialize it only when replay is required. Each continuation names one applicable pattern reference 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 cited 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 cited 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 a second relation-selection map; 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, selected source U.Episteme, exact EpistemePublicationRelation occurrence reference when availability is material, source-pack cue or return, and provisional framework purpose.

If choosing a DPF, an access-only route, or stop must settle a downstream-used framework boundary, use E.4.PFAD to profile that framework-specific content in one E.9 DRR; a cheap seed or route that settles no such boundary stops without that DRR. State each material initial pattern relation with the predicate that defines it, and use E.4.PFR only when a named maintenance use needs relation records. Using the E.4.PFAD profile adds no second decision or decision record.

Use E.8 for authoring, E.21 for evaluation, E.23 for improvement, and G.11 for currentness or refresh. Keep the source result, selected answer and DRR, direct relation assertions or optional records, authored patterns, quality results, and currentness results separate. P2W preserves the carried claim only until the next concrete claim or relation-specific question is stated and its applicable pattern 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 defines the characteristic space and its comparability boundary; A.19.CPM comparison becomes current only when that characteristic space and comparator are current. The G.5 selected-set result declaration remains stopped until that comparison and front are current; actual audience availability is a separate later question that uses E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. 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. No U.WorkPlan has yet been produced under A.15.2, and no dated U.Work occurrence has yet been admitted under A.15.1. Thermal and serviceability measurements can feed but cannot create three separate results: applying A.15.5 may return WorkEntryReadiness@Context for one named intended-work concern; applying A.21 may return a GateDecision only for one current OperationalGate(profile) and its declared checks; applying 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 predicate definition or occurrence rule for that release relation 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. When descriptors, tests, competitor information, or cited publication editions change, reopen the currentness-dependent continuations under G.11.

The current next question in this example is: which retained layouts belong in the current C.18 front? The next applicable pattern is C.18, and its result is the current front record. Architecture comparison, selected-set result declaration, actual 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 defined 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 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 what the change affects: a changed practice or practitioner use reopens E.18.1; changed wording reopens F.18; changed public reader use reopens F.17; changed source basis reopens its exact source-use relation. For a changed publication, use E.17 for the source-backed face and return to source and E.24.PUB for the occurrence, form, carrier, audience, bounded use, and availability. 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 relation-selection 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 pattern that answers the question, and one visible stop. A case with several claims splits before any 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 question the reader asks:

• Lens or declaration? Ask whether the current use judges a mathematical representation or declares a 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 concerns a law-governed operation application or a reusable way of doing. A shared noun supplies neither; split the questions and use the Relations map once for each current claim.
• Change or timing? Ask whether the claim concerns an actual bounded change, a temporal aspect such as an interval or cadence, or the adequacy of a temporal claim for one use. A timestamp or a before-and-after picture supplies none of those answers.
• Work, change, or their connection? Identify the dated U.Work occurrence and actual U.Transformation separately, then ask whether a work-to-change claim is current. Apply the pattern that defines or tests that claim, or the applicable A.6.RCD route, and carry only its positive or negative result or exact blocker. Shared timing does not answer the question. The BuildOps and Pump 14 slices in 5.1 show a positive result; Pump 14 also preserves an earlier missing-governor stop without copying the result's proof.
• Approved, ready, released, or permitted? State which result is being sought: a gate decision, permission result, work-entry-readiness result, release U.Work occurrence, or subject-release relation. Apply the pattern that answers that question and carry its result or blocker; authorization is not a result type.
• Result or production? Let A.6.P.WMR separate the concrete result questions. Open A.15.PROD only for a production-work, entity-inception, or production-completion question; its returned claim or blocker stays 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 the pattern whose Solution answers that question, and continue only with its result or honest stop. Split several relation claims; if no relation can be stated, retain the cue and stop.

A neighboring pattern's 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 question-to-pattern 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 a practitioner or another capable system has obtained or amended the result by applying the cited guidance 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 use of neighboring pattern content 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 Relations 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 relied-on 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
  changedValuePatternRef: pattern containing the guidance applied in the earlier use of changedValueRef
  changedValueContributionUsed: exact Solution passage applied in that earlier use
  stillCarriedClaimSlice
  noLongerCarriedClaimSlice?
  smallestReopenedContinuation
  refreshCurrentnessLineRef?: exact current G.11 episteme or relation
  nextApplicablePatternRef: pattern whose Solution answers the reopened question

Reapply the exact guidance recorded for the earlier use before filling the replay episteme, then use the basis it supplied or located with current facts to reassess the earlier claim or result about the independently identified changed value. If the changed object is a relation, that reassessment first judges whether the relation obtains; apply [A.6.REL](/generated/patterns/A.6.REL) afterward only when relation-occurrence identity is current. The earlier 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. Citing a PatternID does not admit a MethodDescription.

P2W may cite a readable relation assertion, an explicitly individuated occurrence, or a typed assertion or description, but it cites the independently identified object that served as the earlier result together with its obtaining or claim basis. Citation does not make relation use signature-dependent; a receiving episteme carries a signature reference only when the defining content for that exact claim 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. If the reopened use depends on maintenance, responsibility, or authority, name the direct relation and its participants; an owner-shaped label is not enough. Reapply the guidance used for the earlier result. Add a [G.11](/generated/patterns/G.11) line only when one exists. The practitioner or another capable system applies the guidance to the reopened question and 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

Each slice shows only the P2W contribution: the carried distinction, current question, pattern that answers it, independently obtained result or blocker, and next continuation or stop.

1. Thin first-principles start. The accepted card says that a conserved structure, not one more tuning defect, matters to the next decision. The current question is a mathematical-lens question, so the practitioner applies C.29 and carries its lens-use result or stop. A separate declaration question goes to A.6.0; method selection waits for its own question and participants.

2. Planning from a selected-enough method. The carried distinction constrains planning and the current question asks for a plan. The practitioner applies A.15.2 and carries the plan result returned there. Any compact P2W note cites that result and the problem-side claim it preserves; the plan keeps its own content and authority.

3. Performed work and a positive store-change connection. The carried claim makes actual population of the artifact-store partition material to the next release question. The current question asks whether ReleaseBinary12_BuildWork_2026-07-21T0900_0912 is connected to ArtifactStorePopulationTransformation_12. A.15.1 and A.3.4 identify those two participants, and applying the BuildOps work-to-change predicate yields positive assertion BuildWorkPopulatedStore-12. P2W carries that assertion and continues to the separate release question; if the defining pattern instead yields a blocker, P2W stops there. It does not recreate the predicate test, performed-application proof, or negative-claim rule.

4. Result interpretation without a generic result. The sentence the work result proves the approach worked leaves the result question unresolved. Apply A.6.P.WMR; carry each concrete returned claim or blocker on its own continuation. No returned item becomes a generic result or production value merely because the source used the word result.

5. Functional explanatory order. A source diagram places formal declaration, principle framing, mechanism, normalization, method selection, planning, performed work, and measurement in one readable order. Treat each as a possible question, apply its defining pattern only when that question is current, and carry the separate returned values or stops. Display order supplies no project sequence or authority.

6. Interface split before P2W use. A source says a port-throughput limit makes a solution feasible after integration. Ask the module-interface question through A.6.M and the selected transformation-flow question through E.18. Planning, work, evidence, gate, function, and architecture cues remain stopped until their own questions are stated. P2W carries only the result or stop that matters to the current decision.

7. Measurement returns to planning. A source says one work occurrence produced telemetry and an artifact. A.6.P.WMR first returns the distinct artifact, telemetry, production, or unsupported results needed by the case; P2W keeps separate continuations. If a later C.16 result and G.11 currentness result change the reference plane used by planning, reopen only the planning, method-comparison, or problem-side continuation that relied on it. The earlier dated Work occurrence is not rewritten.

8. Pump 14 pressure adjustment; positive continuation after an earlier stop. The carried distinction makes the relation between W-P14-ADJUST-1010-1020 and T-P14-PRESSURE-RISE material. In the earlier case record, no current predicate could state that connection, so applying the defining work-to-change pattern yielded missing-governor and P2W stopped. In the current record, each precise performer has an independently established A.13 core and A.15.1 has independently admitted the Work. Because this record also carries exact assignment-bound attribution, F.6 afterward establishes that relation through the same obtaining assignment. That basis and the P14-REL-2026 application support the positive AdjustmentWorkCausesPressureRise result; P2W carries the result without reconstructing the agency, Work-admission, assignment-attribution, transformation, or causation proof. The separate claim that PC-P14-PRESSURE guided WP-P14-2026-07-15 still has its own missing-governor result and stays stopped. Later measurement and decision questions remain separate.

#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 defining predicates, signatures, participant order and endpoint bindings. Membership is acyclic; feedback relations may cycle when their own rules permit it. 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 identified viewpoint or model-use participant, applicable pattern contribution, 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 the particular pattern contribution used for the current question.
• 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 identified U.Viewpoint or BoundedModelUseStructure designated by that ClaimGraph, each cited 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, applicablePatternRef, 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 identified 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, applicable pattern contribution, 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, applicable pattern contribution, 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 in the patterns whose Solutions answer those exact questions.
• 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 pattern that answers the question 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 changedValuePatternRef; what still carries and what no longer carries; the smallest reopened continuation; any current G.11 currentness line; and nextApplicablePatternRef. If the changed object is relation-bearing, the cited 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, selected source U.Episteme reference, exact EpistemePublicationRelation occurrence reference when availability is material, source-pack cue, or source-pack return when that source use is current; the problem-side cue when that is current; the next concrete claim or relation-specific question, including its participants when a relation is asserted; the next applicable pattern selected from the canonical Relations map; 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 cites the exact positive or negative claim or blocker already returned by the named subject predicate's defining pattern or the applicable A.6.RCD route. It keeps the actual U.Work and U.Transformation references when they are part of that result, but does not reconstruct occurrence proof, predicate tests, failure classification, or negative-claim closure. The BuildOps and Pump 14 slices show positive carry-through; Pump 14 also preserves the earlier missing-governor stop. A production continuation likewise carries only the result or blocker returned by A.15.PROD.
• CC-E18.1-17 A PatternID reference, 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 independently identified values, has the filled cooling use, and stops at the applicable neighboring pattern. 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 the pattern whose Solution answers the next question. P2W preserves the carried claim; the practitioner or another capable system obtains or amends the downstream result by applying the neighbouring guidance.

Stable core and optional apparatus. Preserve the accepted claim for one receiving decision or use, ask a concrete relation question, apply the pattern that answers it, 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 the patterns whose Solutions answer each exact question. 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 pattern that answers the question. Outside that boundary, apply the pattern whose Solution answers the exact claim, split independent claims, or stop.

As of 2026-08-07, the Jiao article, QD survey, manufacturing digital-thread papers, historical Modelica 3.7 specification, and current Dyad 3.2 documentation are publication or practice anchors. Dyad remains the current relation-first multi-domain modeling comparator; Modelica remains historical lineage only. 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

• Apply A.22.CGUS when P2W identifies one A.22 structure whose local loci, selected relations, applied constraints, and at least two potential continuations are recoverable. Judge enabled, disabled, unknown, and error outcomes for the present case separately from structure identity and membership.

• 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 supplies SoTA harvesting, source selection, competing-tradition synthesis, and the refreshable synthesis pack before DPF hardening can rely on a source-derived seed. Add A.10 for claim-bound source or provenance, G.6 for addressable path citation or shared provenance representation, B.3 for assurance of a named reliance use, and G.11 for currentness and refresh only when that stronger use is current.

• E.4.DPF guides DPF authoring. When the framework-architecture question is live, E.9 records the selected answer and E.4.PFAD profiles its framework-specific content; E.4.PFR handles an optional framework-relation record only when a named maintenance use needs one.

• E.23 defines and tests 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 defines and tests 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 defines and tests selected TransformationFlowStructure, transfer annotations, flow valuation, ConstraintValidity, GateFit, gate profile, design tags, and run tags.

• C.22.2 defines and tests the accepted problem-side record and problem-side claims related to the carried distinction.

• A.6.P supplies recovery and readable statement of each direct relation. A.6.REL defines and tests 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. Use A.6.RCD, E.24, and E.24.UK for 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 question-to-pattern map. Read each row independently. The row order is not a declaration or work sequence, and each pattern keeps the definition, test, and basis of the result it returns.

#E.18.1:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)