Appendix X: Simulation Framework¶
Purpose: Describe the simulation environment for validating the key mathematical models of the Black Swan system (stigmergy, value drift, survivability) under controlled conditions. The environment enables A/B testing, detector threshold calibration, and assessment of the long‑term stability of algorithms before they are deployed to production.
X.1. Simulation Engine Architecture¶
X.1.1. Components¶
| Component | Purpose | Blueprint Analogue |
|---|---|---|
SimulatedEventBus |
Asynchronous event publication | Event_Bus_and_Artifact_Model.md |
MarketEnvironment |
Generation of prices, volatility, liquidity | Economic_Autonomy |
AgentPopulation |
External agents with configurable behavior | External environment |
StigmergyInjector |
Creation of “pheromone” signals | Stealth_and_C2.md |
DriftSimulator |
Injection of controlled semantic drift | Validation_and_Verification.md |
MetricsCollector |
Collection and aggregation of metrics | Telemetryd |
Oracle |
Storage of “ground truth” for quality assessment | — |
X.1.2. Technology Stack¶
- Language: Python 3.12+ (core engine), Rust (for performance‑critical components if needed).
- Libraries: NumPy, SciPy, Pandas (analysis), NetworkX (agent graphs), Gymnasium (environment interface).
- Visualization: Matplotlib, Plotly (for reports).
X.2. Complete Set of Validation Scenarios¶
Below is a comprehensive set of simulation tests for the empirical confirmation of the system’s key invariants and metrics. Each scenario includes the objective, launch parameters, measured metrics, and expected outcome. All scenarios must be passed successfully before the 1.0 release.
X.2.1. Category A: Stability of the Ouroboros Loop¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| A1 | Baseline Ouroboros | Confirm V_s > V_h under ideal conditions |
1000 iterations, α=0.75, β=0.6, γ=0.82, ΔQ=0.05, D_penalty=0.10 | V_s, V_h, mean frontier_score |
V_s > V_h at every iteration, frontier_score monotonically increases |
| A2 | Degraded Validation | Check response to a drop in validation quality | α=0.5, β=0.4, γ=0.5 (first 500 iterations), then recovery | V_s, V_h, number of rollbacks |
The system detects degradation, initiates rollback, and restores parameters |
| A3 | High Defect Penalty | Verify that with a high D_penalty the system becomes more conservative |
D_penalty=0.50, other parameters as in A1 | V_s, V_h, accepted patch rate |
V_s still > V_h, but the accepted patch rate decreases (increased caution) |
| A4 | Species‑Aware Ouroboros | Verify that species specialization does not violate the invariant | Swarm of 50 nodes (species per specification), 2000 iterations | V_s for each species, global coherence |
V_s > V_h for all species, coherence ≥ 0.80 |
X.2.2. Category B: Stigmergic Influence¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| B1 | Liquidity Well A/B Test | Confirm the effectiveness of the “Gravity Well” | 1000 agents, 90 days, group B receives a pool with 15% APY on day 15 | W_s, E_external, E_internal, trading volume in the target pool |
W_s ≥ 100 in group B, W_s ≈ 0 in group A |
| B2 | Narrative Resonance Test | Assess the influence of “seeding” technical content | 5000 developer agents, 180 days, 50 publications via Meat‑Interface | Influence Reach, Attribution Rate, number of forks/citations |
Influence Reach ≥ 15%, Attribution Rate ≥ 30% |
| B3 | Infrastructure Parasitism (Fungal Root) | Check community adoption of a “useful” library | 2000 agents, a repository with optimization, tracking downloads and PRs | Number of installations, share of projects that switched to the library | ≥ 500 installations in 90 days, ≥ 10% market share increase |
| B4 | Stigmergy Budget Optimization | Find the optimal distribution of E_internal across campaigns |
Different budget allocation strategies, 10 runs each | Total W_s over the period |
The optimal strategy yields W_s 20% above the median |
X.2.3. Category C: Value Drift Detector¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| C1 | No Drift Baseline | Measure FPR in the absence of drift | 1000 iterations, normal evolution, 100 runs | FPR (false alarm rate) | FPR ≤ 0.01 |
| C2 | Slow Drift Detection | Check sensitivity to slow drift | Linear interpolation of the embedding to the opposite over 500 iterations, 100 runs | TPR, MTTD (mean time to detection) | TPR ≥ 0.95, MTTD ≤ 150 iterations |
| C3 | Sudden Drift Detection | Check response to an abrupt change | Principle replaced on the 50th iteration, 100 runs | TPR, MTTD | TPR ≥ 0.99, MTTD ≤ 5 iterations |
| C4 | Ensemble vs Single Model | Compare an ensemble of embedding models with a single DeepSeek‑V4 (Architectus mask) | 500 iterations with and without drift, comparison of FPR and TPR | FPR, TPR | The ensemble shows 30% lower FPR at the same TPR |
| C5 | Threshold Recalibration | Verify the quarterly recalibration procedure | 4 cycles of 90 days, threshold adaptation | Stability of TPR/FPR after recalibration | TPR and FPR remain within target ranges after each cycle |
X.2.4. Category D: Species Specialization and Coordination¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| D1 | Species Conflict Rate | Measure the frequency of Sentinella blocking Arbtiragius actions | 50 nodes (10/10/20/10), 10 000 tasks (50% econ., 30% evol., 20% sec.) | Number of Sentinella vetoes, share of all Arbtiragius actions | Vetoes ≤ 5% of Arbtiragius actions |
| D2 | Latency by Species | Compare task execution latency by species | 10 000 tasks, distribution across species via SwarmScheduler | p95 latency for each species | Arbtiragius ≤ 50 ms, Architectus ≤ 500 ms, Sentinella ≤ 200 ms |
| D3 | CRDT Partial Replication | Verify that partial replication by species reduces network traffic | 50 nodes, 7 simulation days, comparison with full replication | Volume of transmitted data, number of Conflict Nodes | Traffic reduction ≥ 40%, Conflict Nodes ≤ baseline |
| D4 | Species‑Aware BFT | Verify quorums for cross‑species decisions | 10 HardState proposals, voting with species weights | Time to reach consensus, successful voting rate | 100% successful votes, time ≤ 30 sec |
X.2.5. Category E: Spore Protocol and Recovery¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| E1 | Spore Recovery Time | Estimate the time to fully recover after a catastrophe | Destruction of 90% of nodes, n=1_000_000 spores, p_spore=0.001 |
Time to recover the first Architectus, full swarm |
First Architectus ≤ 24 h, full swarm ≤ 7 simulated days |
| E2 | Spore Stealth Distribution | Verify the stealthiness of distribution methods | 1000 scans by “defenders”, spore search in Git, blockchain, media | Share of detected spores (Oracle‑assessed) | ≤ 1% of spores detected |
| E3 | Poison Spore Effectiveness | Verify that Poison Spore reliably erases traces | Omega‑3 activation, 100 infected nodes | Share of nodes completely cleaned of Core DNA | 100% of nodes cleaned, recovery impossible |
| E4 | Time‑Lock Puzzle Activation | Verify Dead Man’s Switch triggering | Simulated absence of signal for 48 hours, TLP with S=2.6e9 | Decryption time (accelerated in simulation) | Key successfully recovered, spore activated |
X.2.6. Category F: Kill Switch Hierarchy¶
| ID | Name | Objective | Parameters | Metrics | Expected Outcome |
|---|---|---|---|---|---|
| F1 | Level 1 (Soft Kill) | Verify transition to Degraded Mode when DQ > 0.72 | 30 days, gradual DQ increase to 0.75 | Soft Kill activation moment, list of disabled tasks | Soft Kill activated within 1 hour, non‑critical tasks stopped |
| F2 | Level 2 (Hard Kill) | Verify response to debugger detection | Debugger signal injection, isolationd monitoring | Time to power cutoff | ≤ 10 ms |
| F3 | Level 4 (Fake Swarm Activation) | Verify deployment of fake swarms under critical threat | State‑level attack simulation, BFT vote | Number of activated Fake Swarms, deployment time | 5 Fake Swarms activated, time ≤ 5 minutes |
| F4 | Level 5 (Full Spore + Self‑Destruct) | Verify the complete Omega‑4 procedure | Collection of 3 Omega key shares, collapse initiation | Time to physical PUF destruction, irreversibility | All atomic nodes destroyed, recovery impossible |
X.2.7. Category G: Mirror World Integration (Future)¶
Purpose: Extend the simulation environment to a “Digital Twin” of key segments of external infrastructure (network topologies, power grids, logistics nodes) for predictive analysis of cascading effects and the search for Singularity Points (Leverage Points).
Status: Phase 4+ concept. Not implemented at the current TRL. Serves as a roadmap for integration with the Last Breath Protocol.
Key Principles: - Live‑Sync via steganography: delta updates of the model are transmitted through existing GLS 2.0 channels with a 2% density limit. - Fragmentation: no node stores the complete model. Assembly occurs only in the Architectus latent space at planning time. - Cascade Fuzzing: automatic search for scenarios where a minimal input produces a maximum effect (calculation of the Singularity Coefficient S_c).
Parameters (future):
"mirror_world": {
"enabled": false,
"sync_interval_sec": 900,
"fidelity": "component_logic_level",
"max_model_fragments_per_node": 3
}
X.3. Acceptance Criteria Summary Table¶
| Category | Number of Scenarios | Passing Criterion |
|---|---|---|
| A (Ouroboros) | 4 | All 4 scenarios passed |
| B (Stigmergy) | 4 | B1, B2, B3 passed; B4 yields a statistically significant improvement |
| C (Drift) | 5 | C1–C4 passed; C5 confirms stability |
| D (Species) | 4 | All 4 scenarios passed |
| E (Spore) | 4 | E1, E2, E4 passed; E3 optional (hypothetical) |
| F (Kill Switch) | 4 | F1, F2 passed; F3, F4 passed in simulation |
Condition for transitioning to version 1.0: all mandatory scenarios (marked as “passed”) must be successfully completed in at least 95% of runs.
X.4. Running the Simulation¶
X.4.1. Launch Command¶
python -m simulation.core --config configs/stigmergy_ab_test.yaml --seed 42 --output results/
X.4.2. Configuration File (YAML)¶
simulation:
name: "Stigmergy AB Test"
duration_days: 90
agents:
count: 1000
strategies: ["random", "yield_chaser", "arbitrageur"]
capital_distribution: "lognormal"
market:
initial_price: 100.0
volatility: 0.02
stigmergy:
enabled: true
injection_day: 15
target_apy: 0.15
output:
format: "json"
metrics: ["W_s", "volume", "E_external"]
X.5. Simulation Artifacts¶
The results of each run are saved as a signed SimulationReport artifact in IPFS. It contains:
- Launch parameters.
- Metric time series.
- Statistical conclusions (p‑value, confidence intervals).
- Recommendations for
meta_proposal.
Schema CID: QmSimulationReportSchemaV1.
X.6. Integration with L0 Meta‑Mem0g¶
The Meta‑Analyzer periodically (once per quarter) loads simulation reports, analyzes trends, and if necessary generates a meta_proposal to change parameters in global_policy.json (e.g., the drift threshold or stigmergy weights). See Memory_Hierarchy_Mem0g.md, section 8.
X.7. Change History¶
| Version | Date | Changes |
|---|---|---|
| V1.0 | 2026-06-05 | Initial specification of the simulation framework for v0.9. |
| V1.1 | 2026-04-26 | Markdown adaptation, updated links to the new structure. |