#U.Dynamics: State-Space and Transition-Law Episteme

A.3.3 · Stable · Definitional pattern · Normative · 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

Use this pattern when a project needs one reusable claim about how the state of an exact EntityOfConcern can change: a state space, a transition law, an observation relation, and the conditions under which prediction, simulation, calibration, conformance, drift, or gating claims may be relied on.

#Aliases

• U.Dynamics

#Keywords

• dynamics
• state space
• transition law
• observation relation
• prediction
• simulation
• calibration.

#Relations

#Content

#Problem frame

Use this pattern when a project needs one reusable claim about how the state of an exact EntityOfConcern can change: a state space, a transition law, an observation relation, and the conditions under which prediction, simulation, calibration, conformance, drift, or gating claims may be relied on.

Use it when the working question is:

• which exact holon, episteme, system-in-role, claim, service, resource bundle, architecture, or other EntityOfConcern has changing state;
• which characteristics and local meanings define the state space;
• which transition law states how those coordinates evolve;
• which observations or work-derived traces can be compared with the law;
• over which operating region, claim scope, qualification window, parameter regime, or scale band the claim applies; and
• whether a prediction can be used for comparison, gating, assurance, planning, or control.

Primary governed object. A.3.3 examines one already identified claim-bearing U.Episteme candidate and judges whether that same individual belongs to the dependent kind U.Dynamics. Positive membership requires its exact C.2.1 EntityOfConcern to be the thing whose state is modelled and its ClaimGraph, interpreted under its effective U.ReferenceScheme, to declare both a state space and a state-transition law for that subject. C.2.1 keeps the episteme's identity; A.3.3 adds no second identity and no generic locality participant.

E.24.UK settlement. U.Dynamics remains a dependent durable U-kind under U.Episteme. It is the reusable state-space and transition-law episteme, not a root change kind, the changed EntityOfConcern, a selected U.Structure, a method or method description, a work occurrence, an actual transformation, or a flow structure. Components such as stateSpace, transitionLaw, observationRelation, and calibrationOrParameterSource remain ClaimGraph content or references inside the dynamics episteme unless another governing pattern independently identifies one of them.

First useful move. In one ordinary sentence, name the exact changing subject, the state coordinates and their meanings, the rule that relates earlier and later state, where that rule applies, and the nearest condition that stops its use. If that is enough for the current comparison, stop. Add observation, calibration, evidence, temporal, mathematical-lens, assurance, or gate machinery only when the proposed receiving use needs it. Before making a prediction, conformance, or gate-use claim, name the observation relation and exact applicability window; if either is unavailable, stop that stronger use.

What goes wrong if missed. Procedure text becomes "the dynamics", telemetry becomes a law, one observed run becomes a prediction, a dashboard becomes a state space, a description or selected graph is mistaken for the dynamics episteme, or a simulation becomes permission to act.

What this buys in practice. Practitioners can compare predictions with traces, decide whether stale predictions may still be used, separate Methods and MethodDescriptions from laws of change, and decide where characteristic, scope, temporal, mathematical-lens, evidence, assurance, or gate patterns must take over.

Not this pattern when. If the source only states a semantic way of doing, use A.3.1. If one episteme substantively describes that admitted Method, use A.3.2; A.3.2 neither identifies a dynamics episteme nor owns a selected organization among several Methods. If the question is an independently selected organization of exact constituents and obtaining relations, use A.22. If the source states one actual bounded change established by the exact changed referent, temporal or formal boundary, boundary conditions, actual subject facts, and continuity or reidentification, use A.3.4; a possible, predicted, simulated, or probable transition remains claim content and supplies no work, gate, release, or permission authority. If it states planned work or dated work, use A.15.2 or A.15.1. If it states a mechanism algebra, use A.6.1 and E.20. If it states only freshness, rhythm, inertia, delay, window, or currentness as a positive temporal aspect, use C.27.TA; if it states adequacy or supported use of an authored temporal claim, use C.27. If it states only evidence or assurance, use A.10 or B.3.

#Problem

Without a first-class U.Dynamics, state-change claims collapse into nearby but different claims:

1. Recipe becomes law. Teams put procedure text, a control diagram, a workflow diagram, or a method description where a state-transition law should be.
2. Trace becomes law. Dated work logs, telemetry, and incident sequences are treated as if past events defined what must happen.
3. Dashboard becomes state space. Metric lists appear without characteristics, units, scales, topology, geometry, invariants, or operating region.
4. Prediction becomes authority. A model output is used for a gate, release, safety, or work decision without freshness, non-expansiveness, commutation, observation, or assurance conditions.
5. Domain vocabulary blocks transfer. Physics, control, finance, reliability, operations, knowledge dynamics, and architecture all talk about change differently; FPF needs one kernel pattern that preserves their differences without inventing separate ontologies.

#Forces

#Solution

#Definition

U.Dynamics is a same-individual dependent kind of U.Episteme. Membership holds when one already identified episteme has the changing subject as its exact C.2.1 EntityOfConcern and its ClaimGraph, interpreted under the effective U.ReferenceScheme, substantively declares both a state space and a state-transition law for that subject. The law may include exogenous inputs, constraints, disturbances, and an observation relation.

The C.2.1 ClaimGraph, exact EntityOfConcern, and effective U.ReferenceScheme remain the episteme's identity discriminators. A.3.3 adds no context field or second dynamics identity. A U.ClaimScope, operating region, applicability window, qualification interval, parameter regime, or scale band enters only through the exact claim that uses it and its direct owner; changing one can change claim content without becoming an ambient container.

U.Dynamics can be deterministic or stochastic, continuous, discrete, or hybrid. It can make state-change claims about physical systems, software services, organizations, epistemes, claim portfolios, resource states, architecture characteristics, or another exact EntityOfConcern. If several subjects are jointly modelled, the exact C.2.1 EntityOfConcern must itself be an independently identified collection, system, or other admitted subject; list proximity does not create one.

It does not prescribe what an agent should do. A semantic way of doing belongs to U.Method; an episteme describing one admitted Method belongs to U.MethodDescription; a dated occurrence belongs to U.Work; a planned occurrence belongs to U.WorkPlan; an actual bounded change belongs to U.Transformation; a mechanism law belongs to U.Mechanism; a selected organization belongs to A.22 U.Structure; and evidence, publication, result, reliance, assurance, gate, and authorization claims remain with their direct owners. None of those objects establishes dynamics membership by being cited, adjacent, displayed, or used.

If empirical grounding is claimed, state the exact C.2.1 EpistemeEmpiricalGroundingRelation. A calibration source, observation record, dated calibration Work, evaluation result, A.10 evidence-provenance path, or B.3 assurance claim remains separately identified and does not become an intrinsic grounding field of U.Dynamics.

#Dynamics statement

Use this compact aid only when the ordinary sentence is insufficient for the current decision:

Dynamics statement:
  CandidateEpisteme:
  EntityOfConcern:
  EffectiveReferenceScheme:
  StateSpace:
  TransitionLaw:
  TimeReference:
  Stochasticity:
  InputsOrDisturbances:
  ObservationRelation:
  ConstraintsOrInvariants:
  ClaimScopeIfReliedOn:
  OperatingRegionAndApplicabilityWindow:
  CalibrationOrParameterSourceIfReliedOn:
  PredictionUse:
  EvidenceOrAssurancePathIfReliedOn:
  StopCondition:

This aid is not an instruction sequence, identity schema, record kind, method description, selected structure, or second carrier. C.2.1 identifies the candidate episteme. The rows expose the minimum claim content and separately governed references needed to keep a law of change distinct from Method, MethodDescription, Structure, Work, actual transformation, result, publication, evidence, reliance, assurance, and authority.

#Working distinction table

#State-space and transition-law fields

The following is a claim-content view of one C.2.1 episteme, not another object identity or mandatory serialization:

U.Dynamics membership view {
  candidateEpisteme: U.Episteme
  entityOfConcern: EntityOfConcern
  effectiveReferenceScheme: U.ReferenceScheme
  claimGraph: {
    stateSpace: state-space declaration over FPF characteristics
    transitionLaw: state-transition claim
    timeReference: continuous | discrete | hybrid
    stochasticity: deterministic | stochastic
    inputsOrDisturbances?: CharacteristicSet
    observationRelation?: claim or exact relation reference
    constraintsOrInvariants?: claim content
    claimScopeIfReliedOn?: U.ClaimScope
    operatingRegionAndApplicabilityWindow?: ConditionSet
    calibrationOrParameterSourceIfReliedOn?: exact source or calibration-episteme reference
  }
}

stateSpace is claim content of this U.Dynamics episteme. It uses characteristics with local meanings, units, scales, and comparability rules, and may cite [A.19](/generated/patterns/A.19) or [C.16](/generated/patterns/C.16) when characteristic or measurement construction is being claimed. It is not the same object as a receiving-evaluation CharacteristicSpace used to score an object for improvement. The dynamics state space may claim topology, geometry, aggregation policy, or coordinate transformations when trajectories or comparisons need them; an independently selected organization among exact constituents and obtaining relations remains A.22 U.Structure.

transitionLaw is paradigm-agnostic. It can be an equation, relation, kernel, finite-state transition, queueing model, Bayesian update, Petri-net firing relation, simulation rule, learned predictor, or hybrid model, provided the state space, semantic basis, and applicability boundary are declared.

transitionLaw, observationRelation, constraintsOrInvariants, and calibrationOrParameterSourceIfReliedOn are ClaimGraph content or exact references inside the U.Dynamics episteme unless another governing pattern independently identifies one as an episteme, source, relation, or structure. Naming or displaying one component does not split U.Dynamics, create a MethodDescription, or make a relation obtain.

observationRelation separates state from what can be measured, sampled, logged, estimated, or inferred. Identity observation is allowed only when the claim says the state coordinate is directly observed. Any exact measurement result, observation record, dated Work, provenance path, empirical-grounding relation, or assurance claim remains under its direct owner.

#Evidence, prediction, conformance, drift, and calibration

Let D be a U.Dynamics about exact EntityOfConcern E. Let W denote only exact dated U.Work occurrences when Work is current, and let O denote separately identified observation, telemetry, source, or measurement records. Neither a record nor a Work occurrence is part of D merely because a trace cites it.

These expressions name claim-side calculations or questions. A calculated value does not by itself establish an observation, conformance, drift, measurement, evaluation, gate, or assurance result. When such a result is claimed, its direct evaluation or measurement owner supplies the criterion, application and result semantics; C.2.1 identifies any persisted result episteme, and A.10 or B.3 governs only the separately claimed reliance or assurance use.

Calibration Work and its domain result may support a later dynamics episteme whose changed ClaimGraph receives its own C.2.1 identity; an EpistemeEditionRelation obtains only when C.2.1's exact continuation predicate is separately established. Calibration does not mutate the earlier episteme into Work, identify the result as dynamics, supply intrinsic grounding, or make the later law authoritative for a gate.

#Prediction use in comparison or gating

When predicted coordinates from U.Dynamics are used for comparison, release, gate, assurance, or work-preparation use, one of these conditions must hold:

1. a fresh observation is available for the gate or comparison window; or
2. the applied transition map Phi_dt is declared non-expansive under the declared distance structure, and the transition commutes with the invariantization or quotient step on the domain of use.

If neither condition is satisfied, prediction does not carry the gate or comparison claim. Use observation, state currentness through C.27.TA, use C.27 when authored temporal-claim adequacy is the concern, or move the gate claim to A.20, A.21, or the direct authority pattern.

Every use of Phi_dt states its applicability window: operating region, horizon, scale band, time step, parameter regime, and source-currentness condition.

#A.3.4, C.27.TA, C.27, and C.29 boundaries

A.3.4 governs one actual bounded change identified by the exact changed referent, maximal continuous temporal extent or exact formal ordering boundary, boundary conditions, actual characteristic-state and obtaining direct-relation facts, and continuity or reidentification. A dynamics episteme can model a possible change, predict a probable transition, simulate a trajectory, constrain a candidate, or assert that change is expected; none becomes an actual U.Transformation until that subject-side occurrence basis obtains. Prediction supplies no dated work, transformation participation, gate passage, release, permission, or other authority.

C.27.TA names positive temporal aspects: freshness, delay, rhythm, currentness, inertia, cadence, trajectory, recovery timing, stabilization timing, and validity window. C.27 judges adequacy or supported use of authored temporal claims that use those aspects. A Dyn2TemporalClaimAdequacyCard or temporal classification is not itself a law of change.

Stay in A.3.3 when transitionLaw or observationRelation uses accepted local dynamics, Markov kernels, ODEs, simulations, queueing theory, control theory, or domain theory under one explicit semantic basis and applicability boundary.

Use C.29 when the law depends on contested transfer, cross-domain analogy, learned or speculative mathematical lens, scale change, abstraction, quotienting, or reusable explanation across contexts. The C.29 output states preserved structure, lost structure, operating-region or scale window, rival lens when current, lens-use boundary value, and stop condition. A.3.3 remains the governing pattern for state space, transition law, observation, constraints, and calibration semantics.

#Method, mechanism, and governing-pattern constellation boundary

A source label such as process, algorithm, dynamics, workflow, model, controller, or simulator may point to linked slot positions under E.10.ARCH, not to one typed value. Recover the relevant slots first, then split the linked values:

• U.Method for the semantic way of doing;
• U.MethodDescription for the claim-bearing episteme that substantively describes one admitted Method, while C.29 and publication owners keep its representation, form, carrier, and availability separate;
• U.Dynamics for the state-space and transition-law episteme;
• U.Mechanism for an admissible operation or law-governed application over a subject kind;
• U.WorkPlan and U.Work for planned and dated occurrences;
• TransformationFlowStructure for selected flow structure when the source is describing a flow-shaped arrangement of transformations;
• evidence, gate, authority, and assurance values when those claims are current.

A transition graph, ordering, shared label, dynamics equation, MethodDescription node, selector row, or predicted trajectory also establishes no B.1.5 methodPartOf occurrence or composite Method. B.1.5 must independently recover exact part Methods, obtaining part relations, whole-forming claims and constraints, whole semantics, boundary and reidentification.

The linkage among relation positions does not become a process, method, mechanism, dynamics model, plan, work occurrence, or evidence object. Do not infer dual typing from a shared source or label. One episteme can meet A.3.2 only by describing one admitted Method, and one episteme can meet A.3.3 only by carrying the state-space and transition-law claims above; neither membership establishes the other, identifies the Method, selects an A.22 Structure, or supplies actual Work or transformation. No current FPF governor admits one individual as both the A.3.1 semantic way of doing and the A.3.3 state-change episteme; reopen that question only if a later direct admission rule states both memberships without letting either classification supply the other's facts.

#Archetypal Grounding

#Reactor control

A reactor team models temperature and concentration under a nonlinear ODE with disturbances. One claim-bearing reactor-model episteme is U.Dynamics. Its ClaimGraph declares the nonlinear ODE as transitionLaw, the exact temperature-and-concentration state space as stateSpace, the observation relation, disturbances, and the operating region and applicability window, or cites exact references that supply those declarations. The control policy is U.Method; a claim-bearing episteme represented by the controller code may be U.MethodDescription only when it passes A.3.2 for that Method, while the code representation, dated controller runs, and mechanism claims stay with their governing patterns. Thermocouple readings become evidence only through A.10 or the direct evidence pattern.

Side-by-side split:

#Reliability and operations

A service platform models backlog, arrival rate, and incident recovery with a queueing or birth-death model. The model can predict whether an SLO is feasible, but the service promise remains U.PromiseContent, and release or gate use needs the gate pattern.

#Evolutionary architecture

An architecture group tracks latency, coupling, operational cost, and change lead time across releases. A discrete-time transition map over those characteristics can be U.Dynamics. Architecture moves, selected structures, and views stay with architecture patterns; work occurrences and measurements stay with work and evidence patterns.

#Knowledge dynamics

A claim portfolio uses belief, evidence weight, source currentness, and contestability as state coordinates. A Bayesian or likelihood update is a dynamics episteme over claim state. The studies, reviews, and source records are evidence values; the dynamics model does not make a claim true by itself.

#Natural physical evolution

The Moon orbiting Earth can be modeled as U.Dynamics without pretending that the Moon enacts a method or performs governed work. A role assignment such as satellite classification may be well-formed, but it does not create method-work alignment.

#Bias-Annotation

Typical biases:

• recipe-as-law bias: procedure text or controller code is treated as the law of change;
• trace-as-law bias: logs or one observed run are treated as reusable dynamics;
• dashboard-as-state-space bias: visible metrics substitute for declared characteristics, units, scales, and comparability relations;
• prediction-as-authority bias: model output is treated as permission, gate passage, or safety proof;
• mathematical-prestige bias: equations, learned predictors, and simulations are accepted without applicability window, observation relation, and transfer boundary;
• semio-bias: the pattern drifts into arguments about descriptions of dynamics while losing the state-space and transition-law EntityOfConcern.

#Conformance Checklist

CC-A3.3-1 (Membership and identity). A.3.3 judges one already identified U.Episteme. That same individual is U.Dynamics only when its exact C.2.1 EntityOfConcern is the changing subject and its ClaimGraph, under its effective U.ReferenceScheme, declares both a state space and a transition law. A.3.3 adds no second identity. It is not thereby U.Method, U.MethodDescription, U.Structure, U.WorkPlan, U.Work, U.Transformation, U.Mechanism, result, publication, evidence, assurance, gate, or authority.

CC-A3.3-2 (Semantic locality without a container). Local meanings and characteristic names are interpreted under the effective U.ReferenceScheme; units, operating region, time base, approximation regime, claim scope when needed, qualification window and source-currentness condition remain explicit claim content or separately governed values. No U.BoundedContext, generic context field, selected structure, description, carrier, or intrinsic-grounding slot identifies or contains the dynamics episteme.

CC-A3.3-3 (EntityOfConcern). The changing EntityOfConcern is named. It may be a physical holon, service, organization, episteme, claim portfolio, architecture, resource bundle, or other holon with modeled state.

CC-A3.3-4 (State space). The state space enumerates characteristics with units, scales, comparability rules, and any needed topology, geometry, aggregation policy, or invariantization rule.

CC-A3.3-5 (Transition law). The transition law states a relation, map, kernel, equation, rule, learned predictor, or simulation rule suitable for the declared time base and stochasticity.

CC-A3.3-6 (Observation relation). Evidence use states how exact Work-side facts when present and separately identified work records, telemetry, measurements, observation records, or source records become observed coordinates. A record is not the Work it describes, and direct observation is declared rather than assumed.

CC-A3.3-7 (Constraints and applicability). Constraints, invariants, operating region, approximation regime, parameter range, horizon, and scale window are stated before prediction or gate use.

CC-A3.3-8 (No imperative overread). U.Dynamics does not prescribe agent steps, responsibilities, or ordered work occurrences. A reusable planning or control way that uses dynamics is U.Method; only a separately identified claim-bearing episteme that passes A.3.2 is its U.MethodDescription.

CC-A3.3-9 (No actuals on dynamics). Resource actuals, timestamps, Work occurrences, work logs, and telemetry attach to their exact Work, record, evidence, measurement, or source owners. Calibration Work and its domain result may support a later dynamics episteme with its own C.2.1 identity; a continuing edition relation obtains only when C.2.1's separate predicate does.

CC-A3.3-10 (Prediction use). Predicted coordinates used for comparison or gating require fresh observation or a declared non-expansive, invariant-commuting transition map over the domain of use.

CC-A3.3-11 (Temporal boundary). Positive temporal aspects stay with C.27.TA; temporal-claim adequacy, freshness-use, delay-use, rhythm-use, inertia-use, and currentness-use claims stay with C.27; reusable transition laws stay with A.3.3.

CC-A3.3-12 (C.29 boundary). Contested, cross-domain, learned, speculative, scale-changing, or transferable mathematical-lens use is assigned to C.29; A.3.3 keeps the dynamics semantics.

CC-A3.3-13 (Source-label repair). Process, workflow, algorithm, model, controller, simulator, and dynamics wording must not be repaired to U.Dynamics until the current slot is recovered: method, method description, work plan, dated work, selected transformation-flow structure, transition-law claim graph, evidence relation, or another governed value.

CC-A3.3-14 (Actual-transformation boundary). Possible, predicted, simulated, or probable change remains claim content. An actual U.Transformation requires the exact changed referent, temporal or formal boundary, boundary conditions, actual subject facts, and continuity or reidentification; dynamics and prediction supply no dated work, transformation participation, gate passage, release, permission, or other authority.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Quick use cards

• Dynamics predicts. It is a state-space and transition-law episteme.
• Work reveals. Measurements, logs, and actuals belong to work, evidence, or source values.
• Method guides. A method may use dynamics, but dynamics is not the method.
• State space first. No state-space characteristics, no reviewable dynamics claim.
• Observation matters. A law without observation relation cannot be compared with traces.
• Prediction is not authority. Gate and release claims need their governing patterns.

#Rationale

FPF needs U.Dynamics because many practical questions are not about what an agent should do, but about how a state changes when the world evolves, a model is simulated, evidence arrives, a resource pool fluctuates, or an architecture changes. Those questions need a law of change, not a procedure, not a work log, and not a promise.

The pattern is deliberately broad because state-change reasoning appears in physics, control, software operations, reliability, strategy, architecture, and knowledge work. The shared kernel is not a universal notation. It is the distinction between state-space, transition law, observation relation, applicability window, and related governed claim families such as method, work, evidence, assurance, and gate use. An actual transformation remains a different world-side occurrence: its exact changed referent, temporal or formal boundary, boundary conditions, actual subject facts, and continuity or reidentification are governed by A.3.4, not supplied by the dynamics episteme.

#SoTA-Echoing

Lower current use of this pattern when current work on process theory, predictive control, hybrid systems, stochastic dynamics, digital twins, causal dynamics, learned world models, graph representations, equivalence representations, or FPF's own characteristic-space, temporal, mathematical-lens, transformation, work, evidence, and gate patterns changes the governing distinction.

#Relations

• Builds on: C.2.1 for the same episteme's identity and any exact empirical-grounding or edition relation; A.19 and C.16 for characteristics, units and measurement meanings when current; A.2.6 for an exact U.ClaimScope; and direct source or publication machinery only when those claims are current.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; B.1.5 for composite Method construction; A.22 for an independently selected Structure; A.1.1 only when an independently selected bounded-model-use structure or obtaining model-use relation changes the receiving use; A.3.4 U.Transformation; A.15.2 U.WorkPlan; A.15.1 U.Work; A.6.1 U.Mechanism; E.20; C.27.TA; C.27; C.29; A.10; B.3; A.20; A.21; and architecture patterns when dynamics describes architecture-characteristic change.
• Separates from: services and promise content; PBS and SBS structural breakdowns; causal-use claims; gate authority; assurance arguments; publication-use claims.
• Uses for precision restoration: E.10, E.10.ARCH, F.18, and C.2.P.DR when source labels hide whether the claim is law, method, method description, mechanism, work, evidence, authority, or dynamics.

#A.3.3:End

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