Abstraction begins with an intended use
A mathematical model selects the aspects of a system needed to answer a particular question. It may describe a trajectory, an interaction between components, a constraint on a design or the distribution of an uncertain outcome. The useful level of detail depends on the intended use rather than on a general preference for more complexity.
System boundaries matter. A quantity treated as an external input in one model may be part of the state in another. A physical effect that is negligible at one timescale may dominate at another. Making those decisions explicit allows the model to be discussed before an implementation hides them behind interfaces.
The model should state its variables, assumptions, constraints and relevant domain. Those elements provide a basis for choosing a computational representation and for deciding what evidence would support its use. The Feedback Systems chapter on system modelling provides background on dynamic models and their representations.
State, dynamics and observations
The state x represents information used to describe the system’s evolution. Inputs u influence that evolution, parameters θ describe fixed or specified properties within the model, and t is time. The function f defines the dynamics. An observation function h maps the state to a quantity that can be examined or compared with measurements.
State and observation are different modelling choices. A measurement may reveal only part of the state, and several state configurations can sometimes produce similar observations. This distinction becomes important in parameter estimation, model comparison and the interpretation of uncertainty.
The equation alone is not a complete computational experiment. Initial conditions, input behaviour, parameter values and observation rules must also be specified. A numerical representation introduces further choices, including the method used to evaluate the dynamics and the conditions under which execution terminates.
dx/dt = f(x, u, θ, t) y = h(x, θ)
A general continuous-time state and observation model. The notation is illustrative, with no fitted parameters or project data.
Choosing a representation
Differential equations
Differential equations describe relationships involving rates of change. Ordinary differential equations are useful for many dynamic models with a finite-dimensional state. The structure of the equations, their timescales and constraints affect the numerical method required. An executable model must preserve the relationship between the mathematical variables and the quantities stored by the implementation.
Discrete states and transitions
Some systems are naturally described through time steps, events or modes. A discrete representation specifies how the state changes under defined conditions. When continuous and discrete behaviour coexist, the transition rules and the quantities exchanged between representations need to be made explicit. Otherwise, a change of mode can silently alter the meaning of the state.
Stochastic models
A stochastic model describes uncertain or random behaviour through a probability structure. Specifying a distribution is only one part of that structure: dependencies, temporal correlations and the way random influences enter the dynamics also matter. Repeated computational experiments need a sampling procedure consistent with the model’s assumptions.
Graphs and networks
A graph represents entities and their relationships through nodes and edges. State and dynamics can be associated with nodes, edges or the network as a whole. For an evolving system, connectivity may change with time or depend on the current state. The graph is therefore part of the model, and its abstractions should reflect the interactions relevant to the question.
Parameters, estimation and identifiability
Parameters can describe physical properties, interaction strengths or other quantities within a model. Some are known from an external specification; others may be estimated from observations. Estimation needs a stated observation model, an objective or likelihood, and an account of the uncertainty or noise affecting the data.
A good numerical fit does not by itself establish that the parameters have a unique interpretation. Different parameter combinations may produce similar observable behaviour. Identifiability asks whether the information available is sufficient to distinguish the quantities being estimated. The answer can depend on the model, the observations and the conditions under which those observations were collected.
This motivates careful separation between calibration and validation. Calibration adjusts a model against selected information. Validation examines its suitability for a stated use with appropriate evidence. The NASA modelling and simulation overview explains validation in terms of intended use.
Optimisation and constraints
Optimisation adds a decision problem to the model. It requires an objective, a set of decision variables and constraints that define admissible solutions. The objective must be connected to the system behaviour being examined, while the constraints represent conditions a candidate design is required to satisfy.
Decision variables and uncertain parameters should not be conflated. One may be chosen by an engineer while another represents an unknown property of the system. A model also needs to distinguish a feasible solution from one that only appears acceptable under a particular approximation or observation window.
Numerical optimisation therefore depends on the quality and meaning of the computation used to evaluate a candidate. Solver failures, discontinuities, stochastic variation and parameter uncertainty can all affect the comparison. An explicit model makes those dependencies easier to examine and document.
Model validation and uncertainty
Validation asks whether a model is suitable for its intended use. It requires a comparison appropriate to the question: observations, independently justified reference behaviour or other relevant evidence. An implementation can correctly execute a mathematical specification while that specification remains unsuitable for the physical or engineered system being studied.
Implementation verification addresses a different part of the chain. Tests may examine units, limiting cases, conservation relationships where applicable and consistency with reference solutions. Numerical convergence studies can help assess the influence of discretisation or solver settings. These checks support interpretation, but their scope should remain explicit.
Uncertainty can enter through parameters, initial conditions, model structure, observations and numerical approximation. Recording these sources separately helps identify which conclusions are robust and which depend on assumptions that need further examination.
Why modelling often comes before implementation
In a complex technical system, an implementation decision can encode a scientific assumption. A fixed time step, a scalar network weight or a particular variable ordering may be convenient for software design while changing what the model can represent. A prior mathematical description gives those decisions something explicit to be compared against.
This is the direction explored by Vazgra ModelForge: connect mathematical specification, computational representation, numerical execution, observation, comparison and refinement. The platform is experimental and under R&D; the workflow describes its intended role.
The connection also extends to complex systems, where coupling and scale affect the abstraction, and to scientific computing, where numerical choices affect execution. The Vazgra Solutions engineering philosophy treats these transitions as part of a traceable process from model to system.