[Call for Co-Steward] 3. Simulation & Sandbox Validation (SIMONE)

[kyberlex]

Mission: Building SIMONE in Julia & Auditing the Web Sandbox

In Open Networked Earth (O.N.E.), we have two computational tracks:

1. The Web Sandbox: An interactive browser demonstration running in Canvas 2D at 60 FPS (testing simplified resource balancing: solar kWh, water, calories, compute).
2. SIMONE (Scientific Co-Simulation Spec): A formal specification for a standalone discrete-event, multi-scale engine in Julia (Agents.jl + DifferentialEquations.jl) to model biophysical ODEs alongside human agent behavior under sortition.

The Open Questions & Doubts

We need simulation scientists to answer honestly:

1. Is SIMONE computationally feasible as specified, or would a simpler aggregate model produce more reliable results?
2. Are the physical conservation balances and unit conversions in the web Sandbox internally consistent and thermodynamically sound?
3. How do we properly validate the multi-agent decision loops against real-world human behavior without circular AI-generated assumptions?

The Role of the Simulation Co-Steward

We are looking for a computational modeler, complexity scientist, or scientific software engineer (Julia / Python):

• Domain Focus: Strong experience in agent-based modeling, ODE solvers, and numerical validation.
• Architectural Leadership: Build a minimal working prototype (starting with a single village model) and audit the Sandbox formulas.
• Engaging External Critics: Seek out and invite simulation researchers, JuliaDynamics contributors, and ABM validation experts to actively test and try to break the engine.
• The Loop: Critics test -> co-stewards analyze -> we patch and improve -> re-verify.

Everything is 100% free software (AGPL-3.0), non-commercial, zero crypto/tokens.

Relevant Specifications in Repo

• SIMONE Formal Specifications: simone/simone-specs.md
• Live Sandbox: https://one-oasis.surge.sh

How to Step Forward

If this domain speaks to you, reply below detailing your background, your thoughts on the SIMONE specification, or reach out privately at kyberlex@proton.me.

[rainerrodrigues]

@kyberlex Amazing project and I am blown away by the details!
First, Yes, but I wouldn't start with it. I'd build two models of the same single village:

(a) An aggregate stock and flow ODE model (energy, water, calories, compute as stocks).
(b) The Agents.jl + DifferentialEquations.jl version.

Then run "docking" (Axtell et al., 1996): if the ABM can't reproduce the aggregate model in the homogeneous agent limit, something is wrong. That gives you a built-in correctness test, and it tells you where agent heterogeneity actually changes the outcome. Only those parts justify the extra cost.

We need to consider risks of coupling, ensembles cost and stiffness and timescales.
We also need to consider frame-rate indepedence, real world behavioural data (like recent data) , ODD protocol and rival model benchmarking as well.

What I can offer is I can build the single village prototype in Julia (aggregate model + docking test first, then agents) and do the units/conservation audit of the Sandbox formulas, writing the invariants as tests.

What do you think?

[kyberlex]

@rainerrodrigues This makes complete sense to me, and the answer is an absolute yes.

To be completely honest, I’m a systems engineer/developer, not an academic mathematician or Julia veteran. My past experience with discrete-event simulations comes from semiconductor fab logistics (routing thousands of wafers across machines and transport systems). Those models were often far from reality because people cut corners or got lost in uncalibrated complexity.

That’s why I don’t want an AI-hallucinated monster model that looks impressive on paper but is broken underneath.
Your plan is by far the most sensible way forward:

1. Single village first: Keep the scope grounded and manageable.
2. The Docking test (Axtell): Building the aggregate stock-and-flow ODE first, and then proving that identical clone agents replicate those exact curves, is brilliant. It gives us a solid baseline before we let human behavioral chaos enter the room.

A quick note on scope:
Please completely ignore /sim. Don't spend a single minute looking at the JavaScript or auditing the web sandbox. That's just a browser-based visual toy for divulgation, and having you dig through frontend JS would be a complete waste of your skills. I want you 100% focused on Julia and simone/.

The simone/ directory is currently a blank canvas (it only holds simone-specs.md). Feel free to structure it as a proper Julia package (Project.toml, src/, test/).

I've just sent you a collaborator invite to the repository. Feel free to push directly to a dedicated branch (e.g. simone-init) or work via a fork and PR, whatever fits your workflow best.

Really glad to have you on board!

[kyberlex]

Hi Rainer! Just a quick heads-up: I dispatched the GitHub collaborator invite for the repository so you have full write access to simone/.
In case GitHub's notification email got buried in spam, you can accept it directly here whenever you have a moment:
👉 https://github.com/kyberlex/ONE/invitations
Zero rush at all, just making sure the link reached you. Looking forward to your single-village prototype!