Composable Model Schema (CMS) & ABM/SD Wiki
Executive Summary
The Composable Model Schema (CMS) v1.2.0 is a machine-readable specification framework for agent-based and system dynamics models. It enables automated discovery, code generation, model composition, and governance across heterogeneous modeling paradigms.
The ABM Wiki (446 entries) catalogs landmark agent-based models across finance, epidemiology, supply chain, and social systems. Each entry is structured as a CMS-compliant specification with causal mechanisms, empirical patterns, and parameter guidance.
The SD Wiki (252 entries) catalogs system dynamics models with stock-flow structures, feedback loops, and behavior modes. Both wikis serve as a knowledge base for NEXUS model discovery and as reference implementations for the CMS schema.
Part 1: Composable Model Schema (CMS)
1.1 Purpose & Design Philosophy
CMS enables models to be:
- Machine-readable: Parseable by agents for code generation, validation, and composition
- Framework-agnostic: Translatable between Simudyne Python SDK, NetLogo, Mesa, Modelica
- Discoverable: Searchable by domain, mechanism, pattern, and parameter constraints
- Governable: Assignable complexity tiers, approval workflows, and use-case restrictions
- Composable: Combinable via scenario-component mapping and ensemble specification
The schema is incrementally buildable: models start minimal and are enriched as understanding deepens.
1.2 Core Sections
Identity
- model_id: Unique identifier
- name, domain, subdomain: Categorical metadata
- source_type: "discovered" | "adapted" | "generated" | "internal"
- source_refs: Citations and lineage
Purpose
- problem_statement: Research question or decision problem
- intended_use: ["forecasting", "scenario_analysis", "stress_testing", ...]
- target_outputs: Observable metrics and reports
Scope
- modeling_paradigm: "abm" | "sd" | "hybrid"
- abm_family: "equation_driven" | "interaction_driven" | "hybrid"
- temporal_scope: Time horizon and real-world time unit
- system_boundary: Included/excluded entities
ABM Definition (Core)
Agent Classes:
name,representation_type(individual/representative/aggregated/clustered)multiplicity: Fixed or dynamic countinformation_set: Observables available to agentstate_variables: Named fields with typesbehavior_modules: Ordered action functions
Environment Entities:
- Shared state objects (grids, networks, globals)
- Mediator patterns for agent interactions
Topology:
type: "none" | "network" | "multi_layer_network" | "order_book" | "geography" | "mixed"nodes: Agent/entity typesedge_types: Named link types with propertieslayers: Multi-layer networks with inter-layer connections
Interactions:
interaction_id,name: Unique labeled communication channelproducer_entities,consumer_entities: Message sender/receiverpayload_or_flow: Message content specificationpreconditions,postconditions: Guard logic
Mechanisms (The core value of CMS)
mechanism_id: str # Unique identifier
name: str # E.g., "RiskShiftingGain"
category: Literal["structural", "behavioral", "environmental", "institutional"]
description: str # What the mechanism does
hypothesis: str # Causal hypothesis
agents: list[str] # Agent types involved
links: list[str] # Message channels touched
inputs: list[str] # State reads and incoming messages
outputs: list[str] # State writes and outgoing messages
noise_sources: list[str] # Aleatory uncertainty (agent.rng calls)
epistemic_params: list[str] # Config parameters that control it
output_metrics: list[str] # Which metrics does it affect
disable_config: dict # How to ablate it
predicted_effect: str # Expected direction and magnitude
optional: bool # Can it be disabled?
Stochasticity Spec (v1.2.0 feature)
noise_sources: Detailed noise model (type, distribution, accumulation, correlation)noise_budget: Per-observable CV (coefficient of variation) targetscorrelation_structure: Cross-noise dependenciesanti_pattern_checklist: Detector for common stochasticity bugs
Observables:
model_outputs: Time series and terminal valuesmetrics: Structured metrics with level (agent/group/environment) and aggregationempirical_targets: Stylized facts to match
Step Sequence & Initialization
step_sequence:
- order: 1
agent_type: "Buyer"
description: "Submit limit orders"
- order: 2
agent_type: "Seller"
description: "Submit ask orders"
- order: 3
agent_type: "OrderBook"
description: "Match and clear trades"
- order: 4
agent_type: "Environment"
description: "Record state snapshots"
Design Concepts (ODD-aligned)
emergence: How macroscopic patterns arise from microscopic interactionssensing: What information is available to each agent typestochasticity: Sources and statistical properties of randomnessadaptation: How agents learn and update behaviorprediction: Whether agents are forward-looking or myopicobjectives: Individual and collective goals
1.3 System Dynamics (SD) Extension
For models with continuous state evolution and feedback loops:
sd_definition:
stocks: # Levels/accumulators (differential variables)
flows: # Rates (d/dt expressions)
auxiliaries: # Converter variables
constants: # Fixed parameters
lookups: # Graphical functions (nonlinear relationships)
feedback_loops: # Named loops with polarity (R/B) and stocks involved
behavior_modes: # Expected dynamic patterns (exponential growth, oscillation, etc.)
boundary_adequacy: # Endogenous/exogenous/excluded variables
time_horizon: # Integration bounds and step size
solver: # "euler" | "rk4" | "rk45"
1.4 Execution & Governance
Execution Model:
abstraction_type: "message_passing_abm", "equation_driven_sd", "hybrid"time_model: Discrete steps or continuous timescheduling: Synchronous vs. asynchronous, ordered phasesparallelism: "cpu_single" | "cpu_multi" | "gpu" | "distributed"determinism_profile: "strict" (reproducible), "weak" (repeatable average), "stochastic"
Governance:
complexity_tier: 0–4 (from trivial to cutting-edge)approved_use_cases: Explicit whitelistprohibited_use_cases: Explicit blacklistrequired_specialist_agents: E.g., ["quant", "domain_expert"]signoff_requirements: Who must review before deployment
Lineage:
parent_models: Prior work this model extendsderived_from_wiki_entries: Which wiki entries inspired itmutation_history: Sequence of modificationsstatus: "draft" | "candidate" | "validated" | "deprecated"
1.5 Data & Evaluation Contracts
Data Contract:
initialization_data: Required inputs for model setupcalibration_data: Data needed to fit parametersruntime_data: Exogenous time series (e.g., market data, climate forcing)observable_mappings: How model outputs map to empirical data
Evaluation Contract:
calibration_targets: Which stylized facts / empirical moments to matchvalidation_targets: Out-of-sample teststests: Unit tests, integration tests, regression testssensitivity_analysis: Which parameters to perturbrobustness_checks: Edge cases and corner scenarios
1.6 Example: Double Auction Market
Identity:
{
"model_id": "cda_market_v2",
"name": "Continuous Double Auction with Heterogeneous Traders",
"domain": "finance",
"subdomain": "market_microstructure",
"source_type": "generated"
}
Agents (2 types):
Buyer:
- Multiplicity: 10–100
- State: budget, position (units held), reservation_price, active_orders
- Behavior: submit limit orders, cancel, execute market orders based on signal
Seller:
- Multiplicity: 10–100
- State: inventory, cost, reservation_price, active_orders
- Behavior: submit ask orders, cancel, execute based on opportunity
Environment:
OrderBook:
- State: bid_queue (sorted by price, FIFO), ask_queue, last_trade_price
- Role: match incoming orders against standing orders, execute transactions
Mechanism: PriceDiscovery
Hypothesis: Orders submitted at the highest buyers willingly pay and
lowest sellers willing to accept converge to a fair price.
Agents: [Buyer, Seller]
Links: [BidOrder, AskOrder]
Inputs: [OrderBook.bid_queue, OrderBook.ask_queue]
Outputs: [Transaction.price, Transaction.volume]
NoiseSource: ["Buyer.signal_noise", "Seller.cost_shock"]
EpistemicParams: ["order_imbalance_sensitivity", "tick_size"]
PredictedEffect: "Spread narrows monotonically with increasing liquidity"
Stochasticity:
NoiseSource S1: Buyer signal perturbation
Distribution: Normal(0, σ=0.05)
Purpose: path_divergence (different traders diverge in beliefs)
Accumulation: memoryless (each period independent)
NoiseSource S2: Seller cost shock
Distribution: Lognormal(0, σ=0.1)
Purpose: tail_generation (occasional large moves)
Accumulation: mean_reverting (shocks revert over 5–10 steps)
Correlation: S1 and S2 independent (orthogonal sources)
Budget: target_cv_baseline = 0.12 (12% spread volatility)
Part 2: ABM Wiki
2.1 Structure & Content
The ABM Wiki contains 446 markdown entries, each representing a landmark model or research direction in agent-based economics, epidemiology, ecology, and social systems.
Entry Format (ODD-aligned)
Header:
# CMS: [Model Name] ([Authors Year])
Domain: [Discipline]
Question: [Research question]
Source: [Citation]
Sections:
- Patterns — Emergent stylized facts the model must reproduce
- Scales — Temporal (step size, horizon), spatial, population
- Agents — Table: type, count, state variables, behavior
- Design Concepts — ODD sections: emergence, sensing, stochasticity, adaptation, prediction, objectives
- Mechanisms — Numbered causal processes with hypothesis and uncertainty map
- Mechanism Uncertainty Map — Links each mechanism to its noise sources, parameters, and propagation
- Interactions — Message flows between agents
- Step Sequence — Ordered ticks (who acts when)
- Boundary — Endogenous/exogenous/excluded variables
- Parameters — Table with defaults and ranges
- Behavioral Modes — Expected dynamic outcomes
- Reference Mode — Empirical calibration targets
2.2 Example: ABM Wiki Entry
Example: Abad et al. (2024) — Macroeconomic Model of Banks' Systemic Risk-Taking
Domain: Macroeconomics / Macroprudential Policy
Research Question:
How do heterogeneous banks' unobservable choices of systemic risk exposure, the risk-shifting vs. capital-preservation tradeoff, and macroprudential capital requirements interact to generate endogenous boom-bust cycles?
Key Patterns (Stylized Facts):
- CalmPeriodRiskBuildup: Systemic risk-taking peaks after long uninterrupted calm; crisis probability increases with calm duration ("crisis clock")
- CapitalRequirementCreditTradeoff: Stricter requirements reduce systemic risk but reduce credit supply
- CountercyclicalRegulatoryParadox: Countercyclical buffers can worsen risk-taking if banks anticipate future relaxation
- DepositInsuranceMoralHazard: Insurance removes market discipline; removing it re-activates depositor price sensitivity
- SystemicRiskConcentration: Unobservable and strategic — coordinated high exposure creates correlated failure
Agent Types:
Bank (N = 10–100, heterogeneous):
- capital_buffer k_i ≥ 0
- systemic_risk_exposure x_i ∈ [0,1] (UNOBSERVABLE)
- credit_volume L_i
- Decision: Choose x_i ∈ [0,1] each period balancing
* Risk-shifting gain (upside of boom, but downside uninsured)
* Capital preservation value (value of having capital for next period)
Regulator (1):
- capital_requirement r (static or countercyclical)
- Does NOT observe x_i
- Decision: Set r_t, optionally adjust countercyclically
Household (1 aggregate):
- deposit_volume D
- Provides deposits at rate r_D
- Under insurance: r_D fixed regardless of x_i
- Without insurance: r_D = r_free + risk_premium(x̄_perceived)
7 Mechanisms:
| # | Name | Hypothesis |
|---|---|---|
| 1 | RiskShiftingGain | Limited liability creates asymmetry: upside captured by bank, downside by insurers |
| 2 | CapitalPreservationValue | Capital is costly to raise; franchise value creates brake on risk-taking |
| 3 | CalmPeriodRatchet | Retained earnings → higher capital buffers → risk-shifting dominates after long calm |
| 4 | UnobservableExposure | Regulatory blind spot — x_i unobserved, capital reqs operate on L_i |
| 5 | CountercyclicalAnticipation | If requirements will be lowered in crisis, banks take more risk ex-ante |
| 6 | DepositInsuranceMoralHazard | Insurance removes price signal; market discipline requires x_i visibility |
| 7 | CreditOutputTradeoff | Higher capital requirements reduce equilibrium credit and steady-state output |
Mechanism Uncertainty Map:
RiskShiftingGain:
Epistemic: R_risky, crisis_loss_rate, r_base
Propagates: systemic_risk_exposure → optimal_welfare
CalmPeriodRatchet:
Aleatory: retained_earnings noise ~ N(0, σ)
Epistemic: p_slope, β (discount factor)
Propagates: systemic_risk_exposure → crisis_indicator
2.3 Wiki Taxonomy
The ABM Wiki is indexed by:
- Domain: Finance, Epidemiology, Supply Chain, Ecology, Social Systems, Governance, Energy, Demography
- Paradigm: Interaction-driven ABM, Equation-driven, Hybrid
- Agent Heterogeneity: 2-type, N-type heterogeneous, representative-agent
- Topology: None, Network (scale-free/small-world), Multi-layer, Spatial (grid/continuous), Order book
- Key Mechanisms: Risk-shifting, Information asymmetry, Feedback loops, Adaptation, Contagion, Institutional constraints
- Scale: 10–1M agents, 1–10K steps, local/global topology
Each entry links to:
- CMS JSON (machine-readable specification)
- Reference implementation (if available)
- Empirical calibration targets (stylized facts)
- Key parameters and ranges
Part 3: SD Wiki
3.1 Structure & Content
The SD Wiki contains 252 markdown entries, each specifying a system dynamics model with stocks, flows, feedback loops, and behavior modes.
Entry Format
Header:
# CMS-SD: [Model Name]
Domain: [Discipline]
Question: [Research question]
Framework: Generic SD
Sections:
- Stock-Flow Structure — Table: stocks (initial value, inflows, outflows) and flows (equations)
- Auxiliary Variables — Converters (nonlinear transformations, lookup functions)
- Feedback Loops — Named loops with polarity (R=reinforcing, B=balancing) and dominant stocks
- Causal Hypotheses — Text explanations of key mechanisms
- Time Constants — Characteristic timescales (residence times, delays, lags)
- Boundary Adequacy — Endogenous/exogenous/excluded variables
- Parameters — Default values and ranges
- Behavior Modes — Expected dynamic patterns (growth, oscillation, overshoot, collapse)
- Reference Mode — Historical empirical trajectory to match
3.2 Example: SD Wiki Entry
Example: Aging Population and Healthcare Demand (Ansah et al. 2014)
Domain: Healthcare / Demographics
Research Question:
How does demographic transition drive healthcare demand growth beyond what economic growth can sustain?
Stock-Flow Structure:
Stocks (Populations in ages):
Young_Population: 3M persons
Working_Age: 5M persons
Elderly_Independent: 1.2M persons
Elderly_Frail: 300K persons
Institutionalized: 80K persons
Flows (Annual rates):
births = Working_Age × fertility_rate
aging_to_working = Young_Population / youth_duration (20 years)
aging_to_elderly = Working_Age / working_duration (45 years)
frailty_onset = Elderly_Independent × frailty_rate (6% per year)
institutional_entry = min(Elderly_Frail × admission_rate, capacity_available)
deaths (age-specific mortality rates)
Auxiliary Variables:
dependency_ratio = (Young + Elderly_Ind + Elderly_Frail + Institutional) / Working_Age
healthcare_demand = Elderly_Ind × $3k + Elderly_Frail × $20k + Institutional × $60k
fiscal_gap = healthcare_demand - tax_base
care_waiting_list = max(0, Elderly_Frail × admission_rate - (capacity - Institutionalized))
Feedback Loops:
R1 Fertility Decline (reinforcing):
Higher dependency_ratio
→ economic pressure
→ lower fertility
→ smaller Working_Age cohort
→ higher dependency_ratio [closes loop]
B1 Mortality Regulation (balancing):
Larger elderly population
→ more deaths
→ limits growth of elderly stocks
B2 Fiscal Constraint (balancing):
Rising healthcare_demand
→ budget pressure
→ service rationing
→ slower frailty progression
R2 Medical Paradox (reinforcing):
Better medicine → lower elderly mortality
→ more elderly population
→ more frailty cases
→ more demand
→ more spending on medicine [closes loop]
Time Constants:
youth_duration: 20 years
working_duration: 45 years
independence_duration: 10–15 years
frailty_duration: 3–7 years
institutional_LOS: 2–4 years
Causal Hypotheses:
- Aging is primarily fertility-driven (structural shift), not longevity-driven
- Frailty transition creates nonlinear cost surge (5–10x from independent to institutional)
- Institutional capacity constraints shift care burden to unpaid family labor
- Dependency ratio >0.7 is structurally unsustainable for tax-funded systems
Behavior Modes:
Demographic dividend: Large working cohort, few elderly → fiscal surplus
Transition: Dependency ratio rises monotonically → growing pressure
Structural deficit: Ratio >0.7 → demand exceeds tax capacity
Crisis equilibrium: Unmet need normalized, informal care dominant
Empirical Calibration Targets:
Japan: dependency_ratio 0.43 (1990) → 0.69 (2020), health spend 5% → 11% of GDP
Germany: elderly (65+) 15% (1990) → 22% (2020)
UK: social care spending flat 2010–2020 while elderly +25%
3.3 SD Model Catalog
The SD Wiki indexes models by:
- Domain: Healthcare, Economics, Environment, Supply Chain, Population, Energy, Climate
- Behavior Mode: Growth, Decay, Oscillation, Overshoot-collapse, Goal-seeking, S-shaped growth
- Dominant Loop Polarity: Predominantly reinforcing, predominantly balancing, mixed
- Time Scale: Fast (weeks/months), medium (years), slow (decades)
- Key Stocks: Population, Capital, Resource, Inventory, Debt, Health
- Policy Levers: Tax rate, capacity, efficiency, elasticity, time delays
Each entry provides:
- Stock-flow diagram (ASCII + optional TikZ)
- Empirical reference mode (historical data + expected trajectory)
- Sensitivity to key parameters (which time constant changes output most?)
- Common pitfalls and validation checks
Part 4: CMS Format — Technical Specification
4.1 Schema Hierarchy
ComposableModelSchema (root)
├── cms_version: "1.2.0"
├── model_kind: "single_abm" | "abm_ensemble" | "single_sd" | "sd_ensemble" | "hybrid_abm_sd"
├── admission_status: "cms_native_abm" | "hybrid_abm" | "mechanism_reference_only" | "not_admitted"
│
├── Identity
│ ├── model_id, name, domain, subdomain, summary
│ ├── source_type: "discovered" | "adapted" | "generated" | "internal"
│ └── source_refs: [citations]
│
├── Purpose
│ ├── problem_statement
│ ├── intended_use: ["forecasting", "scenario_analysis", "stress_testing", ...]
│ ├── decision_context
│ └── target_outputs: [{metric, level, direction}]
│
├── Scope
│ ├── temporal_scope: {horizon, real_world_time_unit}
│ ├── system_boundary: {included, excluded}
│ ├── scenario_coverage: {base, stress, intervention}
│ ├── abm_family: "equation_driven" | "interaction_driven" | "hybrid"
│ └── modeling_paradigm: "abm" | "sd" | "hybrid"
│
├── ABMDefinition
│ ├── patterns: [Pattern {name, description, quantitative_threshold}]
│ ├── scales: {temporal, spatial, population}
│ ├── agent_classes: [AgentClass]
│ ├── design_concepts: {emergence, sensing, stochasticity, adaptation, prediction, objectives}
│ ├── environment_entities: [EnvironmentEntity]
│ ├── topology: {type, nodes, edge_types, layers}
│ ├── interactions: [Interaction]
│ ├── step_sequence: [StepSequenceItem {order, agent_type, description}]
│ ├── initialization: {agent_placement, initial_values, network_construction}
│ ├── mechanisms: [Mechanism]
│ ├── mechanism_contracts: [MechanismContract]
│ ├── stochasticity_spec: {noise_sources, noise_budget, correlation_structure, anti_pattern_checklist}
│ └── observables: {model_outputs, metrics, empirical_targets, latent_states}
│
├── SDDefinition (optional)
│ ├── stocks: [SDStockSpec]
│ ├── flows: [SDFlowSpec]
│ ├── auxiliaries: [SDAuxiliarySpec]
│ ├── constants: [SDConstantSpec]
│ ├── lookups: [SDLookupSpec]
│ ├── feedback_loops: [SDFeedbackLoop]
│ ├── behavior_modes: [SDBehaviorMode]
│ ├── boundary_adequacy: {endogenous, exogenous, excluded}
│ └── time_horizon: {initial_time, final_time, time_step, time_units}
│
├── Composition
│ ├── submodels: [submodel specs]
│ ├── interfaces: [connection specs]
│ ├── extension_points: [hotspot specs]
│ ├── scenario_to_component_map: [scenario → submodel selection]
│ └── ensemble: {enabled, voting, weighting}
│
├── ExecutionModel
│ ├── abstraction_type: "message_passing_abm" | "equation_driven_sd" | "hybrid"
│ ├── time_model: {type, step_size}
│ ├── scheduling: {type, phases}
│ ├── orchestration: {backend, parallelism, distributed}
│ ├── communication_pattern: "direct_messages" | "globals" | "middleware"
│ ├── state_layout: "object_oriented" | "columnar" | "distributed"
│ ├── parallelism: "cpu_single" | "cpu_multi" | "gpu" | "distributed"
│ ├── determinism_profile: "strict" | "weak" | "stochastic"
│ └── randomness_control: {seed_control: "strict" | "weak"}
│
├── DataContract
│ ├── initialization_data: [data sources]
│ ├── calibration_data: [empirical data]
│ ├── runtime_data: [exogenous time series]
│ ├── observable_mappings: [model_output → empirical_metric]
│ └── missing_data_policy: {imputation_allowed, synthetic_initialization_allowed}
│
├── EvaluationContract
│ ├── calibration_targets: [stylized facts, moments]
│ ├── validation_targets: [out-of-sample tests]
│ ├── tests: [unit, integration, regression]
│ ├── sensitivity_analysis: {required, key_parameters}
│ └── robustness_checks: {required, perturbations}
│
├── Governance
│ ├── complexity_tier: 0–4
│ ├── approved_use_cases: [whitelist]
│ ├── prohibited_use_cases: [blacklist]
│ ├── required_specialist_agents: ["quant", "domain_expert", ...]
│ └── signoff_requirements: ["technical_review", "ethics_review", ...]
│
├── Lineage
│ ├── parent_models: [model_ids]
│ ├── derived_from_wiki_entries: [wiki_ids]
│ ├── mutation_history: [edits]
│ ├── experiment_ids: [prior runs]
│ ├── version: "0.1.0"
│ └── status: "draft" | "candidate" | "validated" | "deprecated"
│
└── Artifacts
├── wiki_entry_id
├── model_py_ref, config_json_ref, settings_json_ref
├── results_json_ref, report_pdf_ref
└── output_dir_ref
4.2 Mechanism Specification (v1.2.0)
A mechanism is a named causal process that:
- Involves agents — which agent types implement it
- Touches links — which message channels it reads from or writes to
- Transforms inputs — state reads + incoming messages
- Produces outputs — state writes + outgoing messages
- Has a hypothesis — causal claim about system behavior
- Has predicted effect — quantifiable impact on observables
- Is ablatable — can be disabled via config override for testing
Topological Placement Rules:
- If agents=[A, B] and link A→B exists: mechanism sits ON the link (inline)
- If agents=[A] and link X→A exists: mechanism sits on incoming link to A
- If agents=[A] with no links: mechanism is internal to A (sidebar)
- If agents=[A, B, C]: mechanism spans multiple links (spanning box)
Uncertainty Propagation:
noise_sources: [agent.rng() calls feeding this mechanism]
Purpose: path_divergence | phase_transition_driver | heterogeneity_maintenance | tail_generation
Accumulation: random_walk | mean_reverting | memoryless | quenched | explosive
epistemic_params: [config parameters controlling this mechanism]
output_metrics: [which recorded metrics does it directly affect?]
4.3 Stochasticity Specification (v1.2.0)
Problem: Many ABM models have undefined or inconsistent stochasticity, leading to unreproducible "noise budgets" and cross-seed variability that is accident rather than design.
Solution: Explicit stochasticity specification that mandates:
- Source identification — every aleatory input named and described
- Accumulation mode — does noise accumulate (random walk), revert (mean-reverting), or stay local (memoryless)?
- Purpose classification — does this noise drive path divergence, phase transitions, or heterogeneity?
- Cross-noise correlation — are sources independent or co-driven?
- CV budget — what cross-seed coefficient of variation should each observable exhibit?
- Anti-pattern checklist — common stochasticity bugs (temporal accumulation without drift, no idiosyncratic component, etc.)
Example Noise Budget:
NoiseSource S1: "Trader signal jitter"
Agent: Buyer.compute_reservation_price()
Distribution: Normal(0, σ=0.05)
Purpose: heterogeneity_maintenance (each buyer has unique belief)
Accumulation: memoryless
Correlation: independent (uncorrelated with other traders' signals)
NoiseSource S2: "Market shock"
Agent: environment.fundamental_value
Distribution: StudentT(df=3, scale=0.1) [heavy-tailed]
Purpose: tail_generation (occasional large moves)
Accumulation: mean_reverting (half-life 5 steps)
Correlation: common_factor (affects all traders simultaneously)
Observable Target CV:
mid_price: target_cv = 0.12 [12% volatility]
Dominant sources: S1, S2
Distribution shape: lognormal [prices are ratio-scale]
CV lower kill: 0.005 [below 0.5% is unrealistic]
CV upper kill: 3.0 [above 300% is unrealistic]
Part 5: Connecting CMS, Wiki, & NEXUS
5.1 Wiki → CMS Pipeline
Each wiki entry is semi-automatically converted to a CMS JSON:
- Parse wiki markdown — extract patterns, agents, mechanisms, parameters
- Infer schema — map wiki sections to CMS fields
- Validate — check for consistency (mechanism inputs must be outputs of earlier mechanisms, parameters referenced must exist, etc.)
- Enrich — add uncertainty map, correlation structure, empirical targets
Example wiki entry (Abad banks) → CMS JSON (machine-readable spec) → NEXUS discovery (search by mechanism, domain, pattern)
5.2 NEXUS Model Discovery
When a user says /nexus "model financial systemic risk with bank heterogeneity":
- Search abm_wiki by keywords ("systemic risk", "heterogeneous banks", "capital requirements")
- Rank by relevance — which entries have the most similar mechanisms, agents, and empirical targets?
- Return top-N CMS specs — ordered by fit to user's problem statement
- User selects or adapts a wiki entry (mutation)
- NEXUS architect uses selected CMS as template, refines mechanisms, adds constraints
- NEXUS developer generates code from CMS, applying Simudyne SDK patterns
5.3 Composition & Ensemble
CMS enables model composition — assembling new models from existing mechanisms:
Base Model: Abad Banks Systemic Risk (wiki entry)
+ Mechanism: RiskShiftingGain
+ Mechanism: CountercyclicalRegulationAnticipation
+ Mechanism: DepositInsuranceMoralHazard
New Composition: "Banks + Supply Chain Contagion"
+ Submodel 1: Abad Banks (as above)
+ Submodel 2: Global Supply Chain (wiki entry)
+ Interface: Banks as demand nodes, supply chain disruptions shock bank inputs
+ Scenario mapping:
- scenario="calm": no supply disruptions, banks operate normally
- scenario="supply_shock": supply chain disrupted 50% → bank inputs collapse
Each scenario can be independently parameterized and run in parallel via NEXUS Monte Carlo.
Key Insights
Design Philosophy
-
Mechanism-first: CMS centers on causal processes, not agent counts or parameter values. Two models with different agents but identical mechanisms are structurally equivalent.
-
Uncertainty baked in: Stochasticity is not an afterthought but a first-class citizen in CMS v1.2.0. Every mechanism's noise sources are declared, traced, and CV-budgeted.
-
Reusability via composition: Models don't need to be rebuilt from scratch. Wiki entries are building blocks; CMS specs are composable.
-
Governance by tier: Complexity tiers (0–4) and use-case whitelists enable safe deployment — Tier 2 model can't be used for high-stakes policy without signoff.
-
Empirical grounding: Every pattern and mechanism is tied to empirical targets. Models are validated against stylized facts, not just parameter fitting.
ABM vs SD in CMS
| Aspect | ABM | SD |
|---|---|---|
| Unit of analysis | Individual agents, their decisions, their interactions | Stocks, flows, and rates of change |
| Time evolution | Discrete steps, synchronous or asynchronous | Continuous or small time steps (Euler/RK4) |
| Heterogeneity | Natural (each agent is an object) | Aggregated (stocks are populations) |
| Feedback | Implicit in agent behavior | Explicit feedback loops |
| Empirical grounding | Micro-data (agent-level behavior) | Macro-data (population flows) |
| Mechanism visibility | Individual rules and decision trees | Stock-flow structure |
| Composability | Via interaction contracts and message protocols | Via stock-flow boundaries and auxiliary variable reuse |
CMS treats both symmetrically: A hybrid ABM-SD model can have agents whose internal state is governed by SD logic (e.g., a bank with internal capital dynamics modeled as SD), or can have environment entities (like a global resource pool) governed by SD while agents remain discrete.
Conclusion
The Composable Model Schema provides a unifying language for agent-based and system dynamics models. By making mechanisms, parameters, and empirical targets explicit and machine-readable, CMS enables:
- Automated model discovery (ABM Wiki + SD Wiki)
- Intelligent code generation (NEXUS architect)
- Governance and validation (complexity tiers, signoff requirements, ablation tests)
- Model composition (snap together mechanisms and submodels)
- Cross-framework translation (Simudyne → NetLogo → Mesa → GAMA)
The ABM Wiki (446 entries) and SD Wiki (252 entries) serve as the reference implementation and knowledge base for NEXUS, enabling rapid discovery, adaptation, and synthesis of new models grounded in empirical literature.
Built on Simudyne Python SDK v0.7.0 — Agentic Simulation Lab