#U.Transformation: Bounded Change Under Conditions

A.3.4 · Stable · Definitional pattern · Normative except where a section is explicitly informative · Part A - Kernel Architecture Cluster

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

Type: Definitional pattern Status: Stable Normativity: Normative except where a section is explicitly informative

Use this pattern when a project needs to identify a bounded transformation itself: what governed object changes, from what condition to what condition or delta, under which boundary conditions, and which typed values must be considered around that transformation before a stronger claim is made.

#Aliases

• U.Transformation

#Keywords

• transformation
• bounded change
• transformed entity
• transformer
• input/output conditions
• functioning
• transformation-flow structure.

#Relations

#Content

#Use This When

Use this pattern when a project needs to identify a bounded transformation itself: what governed object changes, from what condition to what condition or delta, under which boundary conditions, and which typed values must be considered around that transformation before a stronger claim is made.

Use it when the working question is:

• what is transformed;
• what relation, task, transition, operation family, or predicate states the change;
• what conditions make the transformation possible, admissible, planned, enacted, observed, modeled, claimed, or published;
• which temporal aspect matters: time window, duration, cadence, rhythm, synchronization, currentness, or ordering relation;
• which transformation-ontic slots are claim-relevant in this use: acting system and TransformerRole relation when actual work is claimed, method, method description, mechanism, work plan, work occurrence, transformation-flow structure, transformation-flow mathematical description or lens, dynamics episteme, temporal aspect, temporal-claim adequacy, evidence relation, result record, source relation, publication, gate, decision, assurance, or refresh or reopen claim.

Primary EntityOfConcern. The EntityOfConcern is U.Transformation: the durable ontic for bounded change under declared conditions over an entity, structure, state, characteristic, episteme, work product, architecture, formal object, or other governed object. Its type-level typed n-ary SlotRelation with SlotSpec signature states both the identity slots by which one transformation is recovered and the participation and check slots by which claims about acting side, method, work, mechanism, transformation-flow structure, mathematical description, evidence, publication, and other transformation-relevant values stay attached to the same ontic. The transformationRelation is one slot inside that typed relation, not the whole U.Transformation.

First useful move. Identify the U.Transformation value first by filling the identity slots: transformed object, bounded context, initial condition, post-state condition or delta, transformation relation, admissibility or boundary condition, and temporal or ordering reference when relevant. Then run the participation and check slot relation in A.3.4:4.4: for each slot, record a filled value, unknown or not recovered, not asserted, not current for this claim, or claim lowering or blocking when a stronger claim depends on the missing value. If a claim-bearing record is also needed, treat it as a C.2.1 episteme whose claim graph may make claims about the transformation, one of its slots, a slot filler, or relations among those values. Do not treat the episteme as the transformation itself.

Open-world guard. An unfilled method, work, description, evidence, result, gate, or publication slot does not mean that no such value exists in the world. It means only that this use has not recovered or asserted that value, or that the value is not current for the claim being made. Do not infer a methodless transformation merely because no U.Method has been described yet.

What goes wrong if missed. Method names become change proof, work traces become laws, process diagrams become execution, dynamics models become permission, temporal trends become intervention claims, mathematical constructions become project-world work, and publications about a change are treated as the change itself.

What this buys. A practitioner can keep the transformation under concern distinct from, but slot-connected to, the system bearing TransformerRole and dated work when actual project-world change is claimed, the method that can specify it, the mechanism that can law-govern it, the transformation-flow structure that can compose or locate it, the mathematical description or lens that can express selected structure, the dynamics episteme that can model it, the temporal aspect that can time it, the temporal-claim adequacy pattern that can judge a temporal claim, and the evidence or result relation that can justify a use.

Not this pattern when.

• If the issue is only a semantic way of doing, use A.3.1.
• If the issue is a description of that way, use A.3.2.
• If the issue is a state-space and transition-law episteme, use A.3.3.
• If the issue is a law-governed operation algebra with admissibility predicates, use A.6.1 and E.20.
• If the issue is planned or dated work, use A.15.2 or A.15.1.
• If the issue is the selected compound transformation-flow structure, its locus, path, path slice, crossing, or flow valuation, use E.18.
• If the issue is a graph, algebra, category, tuple, morphism, quotient, fold, refinement, factorization, or wiring expression used to describe that structure mathematically, use E.18.2 and C.29.
• If the issue is a positive temporal aspect of an object or claim, use C.27.TA.
• If the issue is adequacy or supported use of a temporal claim, use C.27.

#Problem Frame

FPF often needs to talk about change in physical systems, engineered artifacts, organizations, epistemes, documents, architectures, programs, regulatory situations, and research objects. The same source phrase may say "algorithm", "process", "workflow", "procedure", "mechanism", "run", "trajectory", "transition", "stabilization", "editing", "migration", "optimization", "morphism", "construction", or another field-specific name for a change, transformer, or change structure.

Those phrases are not enough to recover the object under concern. A CRISPR editing protocol, a nuclear-plant operating change, a platform refactoring, a model update, a document repair, an architecture move, a proof construction, and a method-result carry-through can all involve transformation, but the FPF values under use differ.

FPF already has strong neighboring patterns:

• A.3 for transformer constitution: acting system bearing TransformerRole, method description, method, and actual work;

• A.3.1 for U.Method;

• A.3.2 for U.MethodDescription;

• A.3.3 for U.Dynamics;

• A.6.0 and A.6.5 for signatures and slot discipline;

• A.6.1 and E.20 for mechanisms;

• A.15.2 and A.15.1 for work plans and dated work;

• E.18 for transformation-flow structures;

• E.18.2 for mathematical descriptions of transformation-flow structures;

• E.18.1 for problem-to-principle-to-work carry-through;

• C.27.TA for positive temporal aspects;

• C.27 for temporal-claim adequacy;

• C.29 for mathematical-lens use;

• evidence, gate, assurance, source, result, decision, and publication patterns for their own claims.

What is missing is the compact ontic that says how these values fit around one bounded transformation without turning any one of them into the whole change.

#Problem

Without U.Transformation, projects repeatedly make category errors:

1. Method as transformation. A way of doing is treated as if the change already happened or must happen.
2. Mechanism as transformation. A law-governed operation algebra is treated as the actual or intended change, rather than as one governing value for a transformation.
3. Work as transformation law. A dated work occurrence or trace is treated as if it defined the reusable transformation.
4. Dynamics as permission. A state-space or transition-law episteme is used as if it authorized action, gate passage, or result acceptance.
5. Temporal claim as transformation. A claim about rate, rhythm, recovery, delay, effort, inertia, freshness, or validity window is used as if it specified the whole change and its conditions.
6. Formal construction as project-world work. A morphism, proof construction, or formal transformation inside a mathematical substrate is treated as a physical or organizational change without a realization or work relation.
7. Publication as transformation. A report, dashboard, diagram, source span, or published specification is treated as if it were the changed object or the change event.

These errors are expensive because the wrong neighboring pattern then receives the claim. The project may seek evidence for a method when it needs a work trace, compare dynamics models when it needs a transformation boundary, or invoke temporal-claim adequacy when the real problem is the missing transformation relation.

#Forces

#Solution

#Definition

U.Transformation is a durable FPF ontic for bounded change under conditions.

A U.Transformation is identified by:

• the transformed entity, structure, state, characteristic, episteme, work product, architecture, formal object, or other governed object;
• the bounded context;
• an initial condition and post-state condition, final condition, or delta predicate;
• a transformation relation, task, transition, operation family, morphism, construction, or declared transformation predicate;
• admissibility or boundary conditions;
• a temporal or ordering reference when timing or ordering matters for the claim.

The transformation may be possible, planned, enacted, observed, modeled, described, evidenced, or published. Those are linked-use relations around the transformation. They do not change the basic kind.

#Transformation Core

Use this compact filled core before examples or neighboring-pattern references. It identifies one U.Transformation value under concern by filling the core slots from the type-level schema in A.3.4:4.4. It is not a second ontology, not an episteme slot relation, not a record kind, and not a substitute for neighboring patterns.

TransformationCore:
  transformedEntityOrStructure: governed object or structure whose change is under concern; type it through A.3.4:4.3.
  boundedContext: bounded context-of-meaning where the transformation has meaning; type it as `U.BoundedContext` or through the direct context-governing pattern when current.
  initialCondition: starting state, structure, characteristic value, formal object, or condition set.
  postStateConditionOrDelta: intended, observed, possible, modeled, or claimed post-state, result condition, or delta predicate.
  transformationRelation: the relation, task, transition, operation family, morphism, construction, or predicate that makes the change one transformation rather than an unrelated before-and-after pair.
  admissibilityOrBoundaryCondition: condition that makes the transformation possible, admissible, meaningful, blocked, or lowered.
  temporalOrOrderingReference?: time window, duration, cadence, ordering relation, or C.27.TA temporal aspect when timing or order changes the transformation claim.

Filled first-use slice:

TransformationCore:
  transformedEntityOrStructure: reactor cooling loop operating state, governed as a plant subsystem state.
  boundedContext: emergency-load-change operating review.
  initialCondition: temperature profile oscillates after a load step.
  postStateConditionOrDelta: oscillation is damped within the declared safety window.
  transformationRelation: operating-state stabilization relation under the revised control setting.
  admissibilityOrBoundaryCondition: safety-case review and measurement evidence must hold before the setting is used.
  temporalOrOrderingReference: settling-time window and observation cadence governed through C.27.TA.

Immediate linked values:
  MethodRef?: revised operating method, governed by A.3.1.
  DynamicsEpistemeRef?: state-space and transition-law model, governed by A.3.3.
  WorkOccurrenceRef?: not asserted until dated plant work is recorded through A.15.1.
  EvidenceOrSourceRef?: temperature measurement evidence, not permission by itself.

TransformationCore is the ordinary filled-core instruction for one concrete use. It does not add U.TransformationKind, U.TransformationTuple, or U.TransformationCard. Use those names only after a separate E.24 decision shows that dependent patterns need those levels.

After the core is identified, run the participation and check slot signature in A.3.4:4.4. Method, method description, mechanism, work plan, work occurrence, acting system and TransformerRole chain when actual work is claimed, transformation-flow structure, transformation-flow mathematical description, dynamics episteme, temporal aspect, temporal-claim adequacy, mathematical lens, evidence, source, gate, decision, assurance, result, publication, and refresh or reopen slots are not all identity slots, but they are not arbitrary neighbors either. They belong to the U.Transformation ontic because claims about a transformation change admissible use, support, responsibility, repeatability, enactment, observation, modeling, permission, or refresh when those slot fillers change.

The modularity rule is: the slot belongs to the transformation ontic, while the filler keeps its governing kind and pattern. A MethodRef? slot may be filled by U.Method under [A.3.1](/generated/patterns/A.3.1); a WorkOccurrenceRef? slot may be filled by U.Work under [A.15.1](/generated/patterns/A.15.1); a MechanismRef? slot may be filled by U.Mechanism under [A.6.1](/generated/patterns/A.6.1) and [E.20](/generated/patterns/E.20). This prevents two bad moves at once: it does not collapse method, mechanism, and work into transformation identity, and it also does not pretend that a transformation claim can ignore the way, enactment, evidence, or description that the claim relies on.

When an authored text, dashboard, proof, publication, model, or project record makes claims about the transformation, model that claim-bearing value through [C.2.1](/generated/patterns/C.2.1) rather than duplicating the episteme ontic here:

TransformationDescriptionEpisteme (C.2.1 shorthand, only when a claim-bearing value is current):
  EntityOfConcernSlot: the U.Transformation, one transformation slot, one slot filler, or a relation among those values, as selected by the current claim.
  ClaimGraphSlot: claims about possibility, planning, enactment, observation, modeling, evidence, publication, acceptance, or supported use.
  ReferenceSchemeSlot: how the claim graph is read or tested as claims about the selected transformation value or slot relation while preserving the enclosing U.Transformation context.

This shorthand is only a C.2.1 application. It does not add a second slot relation to [A.3.4](/generated/patterns/A.3.4), and it must not make the description, publication, proof, dashboard, source span, or record into the transformation itself.

#Transformed Object Discipline

Do not identify transformations over untyped "things". The transformed-object slot is one slot inside the U.Transformation ontic. Its filler is an EntityOfConcern value under its governing pattern, not a string, record, dashboard, workflow label, or publication title.

Minimum transformed-object record:

transformedEntityOrStructure:
  value: the named object, structure, state, characteristic, episteme, work product, formal object, or architecture-selected structure under concern.
  governingPattern: the FPF pattern that governs that object kind or relation.
  objectKind: Entity | Holon | System | Episteme | ArchitectureSelectedStructure | WorkProduct | FormalOrIdealObject | OtherGovernedObject
  boundaryOrReferenceScheme: boundary, reference scheme, identity condition, or formal substrate that keeps this object recoverable.
  levelOrScopeWhenRelevant: holon level, system scope, architecture level, formal level, publication scope, or local context when it changes the claim.
  descriptionOrPublicationWhenRelevant: description, diagram, report, dashboard, source span, or publication only when it is being used as a description or publication of the transformed object.
  notSelfEvidencingSource: source, publication, dashboard, or card that must not be treated as evidence merely because it names the object.

Use current [A.1](/generated/patterns/A.1) for the holon, entity, or system source line and the governing subject pattern for the filled object. A U.System, U.Episteme, architecture-selected structure, work product, organization, physical object, document or specification episteme, formal object, or project-world object can fill the slot. The slot does not make the filler a new kind, and the filler does not become U.Transformation merely by occupying the slot.

#Ontic Slot Relation, Identity Slots, and Participation Checklist

U.Transformation uses A.6.0 and A.6.5 slot discipline. This section is the type-level onticSlotRelation schema expressed through SlotSpec rows for U.Transformation. It has two slot statuses:

• identity slots that make one bounded transformation recoverable;
• participation and check slots that must be considered when claims about the transformation use method, mechanism, work, dynamics, temporal, graph, formal, evidence, result, source, publication, gate, decision, assurance, or refresh material.

This is not an editor's distinction between "important" and "optional" prose. It is the ontological modularity decision for U.Transformation. A participation and check slot is included in this ontic when all five conditions hold:

1. Claims about the transformation regularly change their admissible use, support, repeatability, responsibility, enactment, observation, modeling, permission, acceptance, or refresh when this slot's filler changes.
2. The filler has a stable relation to the transformation: it specifies, constrains, enables, enacts, observes, models, times, evidences, publishes, authorizes, accepts, refreshes, or otherwise participates in the ontic through a stable relation.
3. Omitting the slot would force dependent patterns to copy local negative catalogues or grow a shadow ontology around "process", "algorithm", "workflow", "mechanism", "evidence", "record", or similar source labels.
4. Including the slot does not fuse kinds: the slot belongs to U.Transformation, while the filler remains governed by its own pattern.
5. The first-use burden stays bounded: a user records a disposition for the slot, not a full neighboring pattern unless the current claim depends on that value.

The ? marker on a slot means optional in a filled use, not optional in the type-level checklist. Each use considers the slot and records one disposition: filled, unknown or not recovered, not asserted, not current for this claim, or claim lowering or blocking when a stronger claim depends on the missing value. Under open-world discipline, an unfilled slot does not assert that the value does not exist.

Claims may be made about any part of this ontic: the whole transformation, an identity slot, a participation and check slot, a slot filler, or a relation among fillers. A C.2.1 episteme carries those claims; A.3.4 supplies the transformation ontology that keeps the claims from drifting into separate ontologies.

The broad recognition area is change under concern. FPF does not add a separate U.Change head here. U.Transformation is the durable ontic for an atomic bounded change under conditions; change remains the plain recognition gloss. E.18 supplies TransformationFlowStructure: selected compound structure over transformations and adjacent governed loci. Source phrases do not create a second ontology competing with U.Transformation: recover bounded transformation, selected transformation-flow structure, or mathematical-description slot by the current EntityOfConcern and claim. When a transformation-flow locus, path, path slice, substructure, crossing, or flow valuation composes, decomposes, constrains, or locates the bounded change, it fills the structural slot. When a graph, algebra, category, tuple, morphism, quotient, fold, refinement, factorization, or wiring expression is used to express that selected structure, it fills the mathematical-description slot instead.

The A.3 transformer line is the actual-work docking for this ontic. A.3 already governs the acting side: a U.System bearing TransformerRole, a U.MethodDescription, a U.Method, and a dated U.Work occurrence. A.3.4 supplies the missing filled change-under-concern core and surrounding participation slots that those values can participate in. When a transformation is claimed as actual project-world change, recover the A.3 and A.15 chain through WorkOccurrenceRef?: performedBy -> U.RoleAssignment(holder: U.System, role: TransformerRole, context, window) and enactsMethod -> U.Method, with the method-description source when current. Do not introduce a separate transformer and transformation ontology for the acting side, and do not treat actual work as the whole transformation when the changed object, delta, boundary condition, or graph expression is also claim-relevant.

A.3.4 therefore needs two different linked slots, not one vague graph reference. TransformationFlowStructureRef? is current when an E.18 selected compound structure, transformation locus, selected path, path slice, substructure, crossing, or flow valuation composes, decomposes, constrains, or locates the atomic bounded change. TransformationFlowMathematicalDescriptionRef? is current when a graph, algebra, category, tuple, morphism, quotient, fold, refinement, factorization, or wiring expression is used as a mathematical description or lens for that selected structure. The first keeps the transformation in-life or in-subject structure under concern; the second keeps the mathematical description from becoming the transformation, method, mechanism, work occurrence, publication, or evidence relation.

TransformationCore in A.3.4:4.2 is one filled use of the identity slots, not a second ontology. The participation and check slots are fixed typed positions around the transformation, not extra identity conditions and not fused neighboring kinds.

Identity slots:

Participation and check slots:

The functional-transformation slots form one reciprocal group, not five loose fields. TransformerRef?, InputConditionOrPortRefs?, OutputConditionOrPortRefs?, FunctioningRef?, and TransformationFlowStructureRef? are active when the transformation is a functional behavior, is located in a flow, crosses a port or boundary, or depends on a bearer/capability/allocation claim. They are not identity slots by default; they become identity-making only when the current transformation claim explicitly distinguishes this transformation by the bearer, input/output boundary, functioning relation, or flow position.

A.3.4 does not duplicate A.15 role slots and does not add RoleAssignmentRef? as an identity slot. If a transformation claim depends on planned or performed work, recover the role-method-work chain through A.15, A.15.1, and A.15.2. If the required U.RoleAssignment, holder, role, context, method, work plan, or work occurrence cannot be recovered, lower or block the work-dependent transformation claim.

E.18 locus labels do not automatically fill A.3.4 slots. A transformation-flow locus labelled as mechanism points to mechanism-governing content under A.6.1 and E.20; it fills MechanismRef? only when that mechanism value is recovered. A locus labelled as work or work enactment fills WorkOccurrenceRef? only when a dated performed-work occurrence is current under A.15.1. A signature locus points to A.6.0; a check locus points to gate or constraint-validity claims under A.20 or A.21. Method and method-description slots still use A.3.1 and A.3.2; a readable structure order does not create a method.

This is a weak dependency on E.18, not an identity dependency. Every U.Transformation may later receive a one-locus, path-slice, substructure, or containing-flow-structure expression, but A.3.4 does not require such a structure to identify the transformation. When the structure is current, it helps recover method, work, mechanism, publication, evidence, gate, result, or refresh slots by pointing to structure-local loci; the filled values still remain governed by their own patterns.

Kinds do not collapse when associated with a transformation. U.Method, U.Mechanism, U.WorkPlan, and U.Work are not descriptions merely because they are named here. U.MethodDescription, U.Dynamics, and a transformation-description value are epistemes under their own governing patterns. Evidence, source, gate, decision, assurance, result, and publication values may support or govern claims about the transformation; they do not become identity slots unless a governing pattern explicitly makes them identity conditions.

When the current object is a claim-bearing description of the transformation, use C.2.1 explicitly:

TransformationDescriptionEpisteme:
  EntityOfConcernSlot: the U.Transformation, one transformation slot, one slot filler, or a relation among those values
  ClaimGraphSlot: claims about possibility, planning, enactment, observation, modeling, evidence, publication, acceptance, or supported use
  ReferenceSchemeSlot: how those claims are read or tested as claims about the selected value or slot relation while preserving the enclosing U.Transformation context

A dependent pattern may cite U.Transformation, a filled TransformationCore, or a specific participation and check slot without copying this slot relation.

#Neighboring Distinction Table

#Description And Publication Boundary

A method description, dynamics model, transformation diagram, transformation-flow structure description, dashboard, result record, source span, publication, or proof may describe a transformation or provide evidence for a use. It is not the transformation.

If the description itself is under concern, use C.2.1, A.3.2, A.3.3, E.17, E.18, or the direct publication or source pattern. If the transformation is under concern, keep the description as a neighboring episteme or publication value.

#Formal Transformation And Project-World Realization

A morphism, constructive proof, formal construction, task, or state transition can be a transformation inside a formal or mathematical object of concern. That does not make it project-world work.

Use this distinction:

• If the object under concern is formal or ideal, the transformation relation may be a morphism, construction, task, or transition inside the formal substrate.
• If the object under concern is physical, organizational, architectural, documentary, or epistemic, the formal relation may specify, model, constrain, or compare the transformation, while work, realization, evidence, and result relations stay with their governing patterns.
• If a project wants to move from formal construction to project-world change, name the realization relation, work plan, work occurrence, evidence relation, and result relation separately.

#Typed Bundle Recovery Slice

Use this slice when one source phrase appears to name method, mechanism, formal construction, work, evidence, and transformation at once.

Source phrase:

"The workflow algorithm transforms the emergency-stop specification, and the proof shows the new plant boundary is safe."

Recover the project concern first: the project is asking whether a specification episteme and an architecture-selected boundary have been changed so that an emergency-stop claim can be used safely. Then recover typed values:

TransformationCore:
  transformedEntityOrStructure:
    value: emergency-stop specification episteme section
    governingPattern: C.2.1 plus the specification or publication pattern that governs the section
    objectKind: Episteme
    boundaryOrReferenceScheme: named section and declared emergency-stop boundary
    descriptionOrPublicationWhenRelevant: published specification revision
    notSelfEvidencingSource: the proof and publication do not prove their own project-world use
  boundedContext: plant-control safety specification review
  initialCondition: ambiguous stop boundary admits two incompatible readings
  postStateConditionOrDelta: revised boundary admits one declared interpretation under named conditions
  transformationRelation: specification-repair relation over the episteme section
  admissibilityOrBoundaryCondition: review condition and safety-case relation required before use
  temporalOrOrderingReference: C.27.TA validity window for the revision and review cycle

TransformationDescriptionEpisteme (C.2.1 shorthand):
  EntityOfConcernSlot: the U.Transformation identified above
  ClaimGraphSlot: claims that the specification section changed, that the proof relation supports one formal boundary reading, and that safety use still needs assurance or gate admission
  ReferenceSchemeSlot: specification section reference plus formal-substrate interpretation and safety-case review scheme

Current neighboring relation references: method description for the repair procedure; formal substrate or mathematical lens for the proof; evidence or assurance relation for safety use. These references stay outside TransformationCore.

This slice shows the slot-bundle rule without making the claim-bearing episteme the object. The workflow label may point to a method description, a work plan, or an E.18 transformation-flow structure. The algorithm or proof may point to a formal substrate or mathematical lens. The published revised specification is an episteme or publication value. The project-world plant change, if any, needs separate work, evidence, gate, and result relations. Do not assign one typed value as method, mechanism, transformation, work, and evidence merely because the source phrase uses one convenient label.

#Archetypal Grounding

#Physical System Change

A nuclear-plant team claims a revised operating method stabilizes a temperature profile after a load change.

U.Transformation names the bounded change: reactor subsystem under context, initial operating condition, post-change stability condition, transformation relation, admissibility and safety boundary, and time window. The operating method is U.Method; the operation algebra or control law may be U.Mechanism; the state-space model is U.Dynamics; the work trace is U.Work; the safety evidence and gate use remain with evidence and gate patterns.

#Biological Editing

A CRISPR project claims an editing protocol changes a DNA target while keeping off-target risk under a bound.

U.Transformation names the changed biological target, initial condition, post-state or delta, editing transformation relation, admissibility or boundary condition, and any temporal or ordering reference that changes the claim. The editing protocol fills MethodDescriptionRef or MethodRef when it is a selected way of doing; the biochemical mechanism fills MechanismRef; off-target measurements fill EvidenceOrSourceRef; the observed edited sequence or accepted lab output fills ResultRef. The protocol description is not the transformation; the biochemical mechanism is not the dated lab work; the off-target evidence is not permission to use the result.

#Specification Repair

A safety specification is revised so that an emergency-stop boundary no longer permits two incompatible readings.

U.Transformation can name the bounded change to the specification episteme: the affected episteme or section, the initial ambiguous condition, the clarified post-state condition, the transformation relation, and the review or acceptance condition. The edit work is U.Work; the repair method is U.Method; the revised specification remains an episteme or publication under its own governing pattern.

#Formal Construction

A mathematical proof constructs an object and shows that a morphism preserves a chosen invariant.

U.Transformation may govern the formal transformation when the formal object is the EntityOfConcern: initial formal object, constructed object or delta, morphism or construction relation, and admissibility or invariant condition. Formal substrate or mathematical lens fills FormalOrMathLensRef unless it is already the context-of-meaning for the formal object; the proof relation fills evidence or source support or a C.2.1 claim-bearing episteme, not core transformation identity. It does not describe project-world work until a separate realization, method, work, or evidence relation is named.

#Architecture Move

An architecture team changes a selected structure so that an interlevel conflict is reduced while a key architecture characteristic stays within bounds.

U.Transformation names the structure change and delta condition. The architecture pattern governs the selected structure and characteristic; C.29 may supply a mathematical lens for preserved and lost structure; C.27.TA may govern trajectory, cadence, recovery, inertia, or validity window; work planning and dated work stay with A.15.2 and A.15.1.

#Functional Transformer In A Flow

Use this slice when the same sentence says that a system "performs a function", "transforms input to output", or "implements an algorithm". The first question is not whether a function word is present. The first question is which transformation, bearer, input/output boundary, method or algorithm, and flow position are current.

Functional transformation slice:
  TransformationCore:
    transformedEntityOrStructure:
    boundedContext:
    initialCondition:
    postStateConditionOrDelta:
    transformationRelation:
    admissibilityOrBoundaryCondition:
  TransformerRef?: U.System bearing TransformerRole@Context, candidate system, or not recovered
  InputConditionOrPortRefs?: accepted input state, flow, material, energy, signal, information, work product, formal object, condition, or functional port signature
  OutputConditionOrPortRefs?: produced state, flow, material, energy, signal, information, work product, formal object, condition, or functional port signature
  FunctioningRef?: FunctionalElement@Context relation when this transformation is used as the element's functioning
  MethodRef? or MethodDescriptionRef?: algorithm, protocol, recipe, controller, or generalized method only when that claim is current
  MechanismRef?: law-governed realization or operation structure when current
  TransformationFlowStructureRef?: containing flow, path, path slice, composition, coupling, or constraint when current

Examples:

• A pump in a hydraulic network is a U.System filling TransformerRef? when it raises pressure or moves fluid under the current claim. Its required behavior grounds a U.Transformation; inlet/outlet hydraulic conditions or port signatures fill input/output slots; the pump curve may fill mechanism or dynamics slots; the network path fills TransformationFlowStructureRef?.
• A resistor in an electrical circuit is a system or component locus bearing transformer role when the claim is voltage-current relation, heat dissipation, or signal conditioning. Its terminals are not module interfaces by default; they are input/output or port-signature slots for the electrical transformation unless a module-interface claim is current.
• A warehouse in a logistics network performs receiving, storing, picking, or dispatch transformations. The warehouse or candidate subsystem fills TransformerRef?; pallets, orders, inventory states, or documents fill input/output slots; a routing algorithm may be U.Method or U.MethodDescription; dated picking work remains U.Work.
• A refrigerator thermal cycle has compressor, condenser, expansion, and evaporator transformations inside one TransformationFlowStructure. The refrigerator or subsystem can fill TransformerRef?; heat-flow and refrigerant-state boundaries fill input/output slots; the thermodynamic mechanism and control method stay with their governing slots.
• A neural-network block transforms activations inside an architecture flow. The block can be a candidate system or module locus depending on the claim; tensor shape signatures may fill input/output slots; an attention algorithm may be method or method description; benchmarks, ablations, or pruning masks are evidence/result or architecture claims only when their governing patterns are current.

These cases permit the sentence "the system performs a functional transformation at this point in the flow" when the system/candidate system, TransformerRole@Context, bounded transformation, input/output boundary, and flow location are named or explicitly marked unknown/not-current. They also prevent the overread that a named algorithm, module, port, or evidence record by itself proves the transformation, functioning, compatibility, or result.

#Bias-Annotation

Lenses tested: Onto, Arch, Prag, Epist, Gov.

This pattern intentionally biases toward object separation: transformation, method, mechanism, work, dynamics episteme, temporal aspect, temporal-claim adequacy, evidence, result, and publication are kept as linked values, not synonyms.

Resisted distortions:

• software narrowing: algorithm or process wording is treated as code-only when the project concern is a physical, formal, architectural, or project-world transformation;
• method-as-effect: a way of doing is treated as if it had already produced the change;
• model-as-authority: a dynamics episteme is treated as permission, evidence, or gate passage;
• trace-as-law: one work occurrence becomes a reusable law;
• formal-as-work: a proof construction, morphism, or formal transition is treated as project-world work;
• temporal-overread: rate or rhythm wording is treated as a transformation without transformation relation and boundary conditions.

#Conformance Checklist

#Common Anti-Patterns

#SoTA-Echoing

#Consequences

• FPF gains one place to identify bounded transformations without turning method, mechanism, work, dynamics, temporal aspect, temporal-claim adequacy, evidence, or publication into each other.
• C.27.TA can carry positive temporal aspects while C.27 stays focused on temporal-claim adequacy and supported use.
• A.3.3 can stay an episteme pattern for state-space and transition-law claims.
• Users pay the cost of identifying a small TransformationCore when transformation is material to the project concern.
• Neighboring patterns need thin relation updates so they can cite U.Transformation without copying its slot relation.

#Relations

• Builds on: E.24, A.1, A.6.0, A.6.5, C.2.1, A.3, A.7.
• Coordinates with: A.3.1, A.3.2, A.3.3, A.6.1, E.20, A.15.1, A.15.2, E.18, E.18.1, C.27.TA, C.27, C.29, evidence, gate, decision, source, result, assurance, and publication patterns.
• Specializes: the A.3 transformer-constitution family for bounded transformations under declared conditions.

#A.3.4:End

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