EnosElinsa Write System Models and Problem Formulations
Purpose
Write the model in the order the system operates and formulate a problem that closes, rather than recreates, that model. Preserve an established architecture when supplied; introduce only the modules required by the new setting; and make every state, decision, equation, constraint, and objective traceable.
Required resources and routing
- Always read the core contract and quality gates in full.
- Read the MEC domain pack only for mobile edge computing, UAV-MEC, HAP-UAV, vehicular edge computing, dispersed edge computing, or directly adjacent MEC systems.
- If no domain pack matches, infer the operational workflow and physical checks from the target architecture and authoritative sources. Do not reuse MEC equations or module order by analogy alone.
Highest-priority rule: inherit before extending
When a reference architecture or existing model is supplied, first create:
| Model element | Inherited | Adapted | New | Removed | Reason and evidence |
|---|
Cover entities, topology, timing, workflow, physical or service relations, decisions, states, objectives, and constraints. Preserve valid notation and ordering unless a demonstrated dependency or correctness issue requires change. Never present inherited relations as new contributions.
Workflow
1. Recover the system contract
Identify:
- actors, sets, and controller or decision owner;
- physical or logical topology;
- static, mission, event, cycle, or slot timing;
- exogenous parameters and observations;
- state measured at a named instant;
- decisions and their selection instant;
- event order within one decision interval;
- derived performance measures;
- feasibility constraints;
- initial, boundary, terminal, success, and failure behavior.
Mark any missing item as an unresolved requirement.
2. Build the dependency graph
For every equation, record its inputs and output, then topologically order the modules. Prefer operational dependency over a topic taxonomy. A scenario-specific module belongs where its inputs have already been defined; an explicit forward reference is required when that order cannot be followed.
3. Write the overview as a model map
Open with a compact paragraph that defines the actors and control boundary, time convention, operational cycle, decision vector at a high level, objective family, and subsection map. Do not front-load all symbols.
4. Draft each module locally
Use:
operational transition -> assumptions and primitives -> derived relation -> physical interpretation -> local constraint
Define every symbol at first use, state domains and units, explain one paper-relevant coupling after each equation block, and place each constraint beside the relation it governs. Keep one dependency chain together.
For dynamic models, specify observation, action, realization, update, and terminal order. Simulate one interval by hand and ensure all branches are mutually exclusive, exhaustive, and feasible.
5. Close the formulation
The final problem display may collect previously introduced content, but it may not create new physics. It must state the decision variables, objective direction and aggregation, all active constraints, variable domains, uncertainty semantics, and horizon or policy semantics.
Create a decision traceability matrix:
| Decision | Relation affected | Constraint or domain | Objective path | Decision instant |
|---|
Fail the formulation if a claimed decision has no downstream effect, an objective relies on an uncontrolled quantity, or an online decision depends on unavailable future information.
6. Preserve the model-method boundary
The model defines physical state, observations, decisions, objectives, feasibility, and causal policy restrictions. Encoding, repair, action masking, network design, search operators, loss functions, training schedules, and algorithm-loop complexity belong in the method section.
7. Run the audit
Apply the core inheritance, symbol, causality, timing, dimensional, constraint, traceability, and formulation gates, followed by the selected domain gates. Check headings, first sentences, first symbol occurrences, dependency order, units, one complete interval, decision-to-objective paths, and exact closure between local constraints and the final display.
Output constraints
- Match the manuscript's notation, language, and section architecture.
- In an audit, distinguish architecture, causal or state, equation or notation, and formulation failures.
- Make the smallest change that resolves a demonstrated dependency or correctness problem.
- Do not redesign a valid model merely because another organization is possible.