#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 model of how state changes in a bounded context: a state space, a transition law, an observation relation, and the conditions under which prediction, simulation, calibration, conformance, drift, or gating claims are warranted.

#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 model of how state changes in a bounded context: a state space, a transition law, an observation relation, and the conditions under which prediction, simulation, calibration, conformance, drift, or gating claims are warranted.

Use it when the working question is:

• which holon, episteme, system-in-role, claim, service, resource bundle, architecture, or other EntityOfConcern has changing state;
• which characteristics define the state space;
• which transition law states how those coordinates evolve;
• which observations or work-derived traces can be compared with the law;
• whether a prediction can be used for comparison, gating, assurance, planning, or control.

Primary EntityOfConcern. The EntityOfConcern is U.Dynamics: an U.Episteme that specifies a state space and a state-transition law for one or more EntitiesOfConcern in a bounded context.

First useful move. Name the changing EntityOfConcern, the bounded context, the state-space characteristics, the transition law, the observation relation, and the applicability window. If these cannot be named, the current claim is not yet ready for prediction, conformance, or gate 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, 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 from laws of change, and decide where mathematical-lens, temporal, 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 it states an episteme describing that way, use A.3.2. If it states bounded transformation under conditions, use A.3.4. 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

Within a U.BoundedContext, U.Dynamics is an U.Episteme that specifies a state space and a state-transition law for one or more EntitiesOfConcern, possibly under exogenous inputs, constraints, and observation relations.

U.Dynamics can be deterministic or stochastic, continuous, discrete, or hybrid. It can describe physical systems, software services, organizations, episteme states, claim states, resource states, architecture characteristics, or other holons whose state change is being modeled.

It does not prescribe what an agent should do. A semantic way of doing belongs to U.Method; an episteme describing that way belongs to U.MethodDescription; a dated occurrence belongs to U.Work; a planned occurrence belongs to U.WorkPlan; a mechanism law belongs to U.Mechanism; evidence and assurance claims belong to their own governing patterns.

#Dynamics statement

Use this compact statement when applying the pattern:

Dynamics statement:
  EntityOfConcern:
  BoundedContext:
  StateSpace:
  TransitionLaw:
  TimeReference:
  Stochasticity:
  InputsOrDisturbances:
  ObservationRelation:
  ConstraintsOrInvariants:
  ApplicabilityWindow:
  CalibrationOrParameterSource:
  PredictionUse:
  EvidenceRelation:
  StopCondition:

This statement is not an instruction sequence. It is the smallest episteme-facing record needed to keep the law of change separate from methods, work, evidence, and authority.

#Working distinction table

#State-space and transition-law fields

U.Dynamics {
  context: U.BoundedContext
  entityOfConcern: EntityOfConcern
  stateSpace: state-space declaration over FPF characteristics
  transitionLaw: claim graph inside U.Dynamics
  timeReference: continuous | discrete | hybrid
  stochasticity: deterministic | stochastic
  inputsOrDisturbances?: CharacteristicSet
  observationRelation?: claim graph or relation reference inside U.Dynamics
  constraintsOrInvariants?: claim graph inside U.Dynamics
  applicabilityWindow?: ConditionSet
  calibrationOrParameterSource?: source or calibration episteme reference
}

stateSpace is the state-space declaration of this U.Dynamics episteme. It uses FPF characteristics with 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 made. It is not the same object as a receiving-evaluation CharacteristicSpace used to score an object for improvement. The dynamics state space may include topology, geometry, aggregation policy, or coordinate transformations when trajectories or comparisons need them.

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 and applicability window are declared.

transitionLaw, observationRelation, constraintsOrInvariants, and calibrationOrParameterSource are components or claim graphs inside the U.Dynamics episteme unless another governing pattern makes one of them a separately addressable episteme, source, or relation value. Naming one component does not split U.Dynamics into several unrelated epistemes.

observationRelation separates state from what can be measured, sampled, logged, estimated, or inferred. Identity observation is allowed only when the context says the state coordinate is directly observed.

#Evidence, prediction, conformance, drift, and calibration

Let D be a U.Dynamics in context C, and let W be dated U.Work records or observation records produced under C.

Calibration outcomes produce a new or updated dynamics episteme. They do not turn the old law into a dated work record and do not make the new law authoritative for gates without the gate pattern.

#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 bounded transformation under conditions. A dynamics episteme can model, predict, simulate, or constrain a transformation, but it is not the transformation itself.

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 inside one context.

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 representation describing that way;
• 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.

The linkage among relation positions does not become a process, method, mechanism, dynamics model, plan, work occurrence, or evidence object. Assign one typed value as both U.Method and U.Dynamics only when a governing pattern explicitly admits that dual typing for the current claim.

#Archetypal Grounding

#Reactor control

A reactor team models temperature and concentration under a nonlinear ODE with disturbances. The ODE, state space, observation relation, and operating region are U.Dynamics. The control policy is U.Method; the controller code is U.MethodDescription when it describes the method, and dated controller runs or 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 (Type). U.Dynamics is an U.Episteme for a state-space and transition-law claim. It is not U.Method, U.MethodDescription, U.WorkPlan, U.Work, U.Mechanism, evidence, assurance, or gate authority.

CC-A3.3-2 (Bounded context). Every U.Dynamics is declared inside a U.BoundedContext. Units, characteristic names, operating region, time base, approximation regime, and source-currentness condition are local to that context.

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 work records, telemetry, measurements, or source records become observed coordinates. 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. Planning or control methods that use dynamics belong to U.Method and U.MethodDescription.

CC-A3.3-9 (No actuals on dynamics). Resource actuals, timestamps, work logs, and telemetry attach to work, evidence, or source values. Calibration creates a new or revised dynamics episteme.

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.

#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, transformation, evidence, assurance, and gate use.

#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: A.1.1 U.BoundedContext; A.19 CharacteristicSpace; episteme machinery for description, source, and publication when those claims are current.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; 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; 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-06-11 — this section last modified in upstream FPF commit 20c8a0a5 (github.com/ailev/FPF)