Economy organ spec review: data flow corrections, toolchain decisions, typo fix

- M3 hub: predictions publish continuously to Marketplace via M2 (not trader-queried)
- M3 BoundedPrediction: three quality metrics (confidence, correctness, certainty)
- M5 traders: read predictions from Marketplace, mixed roster (LLM + bots)
- M7 SAE: monitors at Marketplace level (the only trader interface)
- M6 Conductor: clarified as LLM, not rule-based
- M4 wallets: one multi-chain wallet per trader, strictly 1:1
- M1 Marketplace: added query_predictions interface for traders
- M3d/M3e: Fortran 2018, gfortran, fpm, OpenBLAS, hand-rolled numerics
- M3b typo: "literao" -> "literal"
- SessionStart hook: added gfortran, fpm, Tcl, ECLiPSe Prolog, Zig, Foundry
- Stub fpm.toml for M3d (mev sims)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

core/docs/plans/M3-sims-hub.md

@@ -3,9 +3,10 @@
 ## 1. Component
 The economy organ's prediction engine: **always-running simulations** ("Sims") populated by
 autonomous simulation agents ("Pops") that model market dynamics across multiple mathematical
-domains and time scales. Sims are **queryable at any time** by Traders (M5) — they produce
-**predictions with explicit upper and lower bounds** on every output value. This is the hub spec;
-individual sim types have dedicated sub-specs (M3a–M3g).
+domains and time scales. Sims produce raw simulation data; the hub transforms it into
+**predictions with explicit upper and lower bounds** and publishes them continuously to the
+Marketplace via M2 Data Feeds. Traders query predictions from the Marketplace (M1), not from the
+hub directly. This is the hub spec; individual sim types have dedicated sub-specs (M3a–M3g).
 
 The academic foundations span AMM mechanism design [1,2], MEV game theory [3,4,5], macro
 tokenomics via SDEs [6,7], and evolutionary consensus games [8–11].
@@ -22,12 +23,13 @@ stdin/stdout JSON — **Fortran** (M3d, M3e), **Prolog** (M3b, M3f), **R** (M3a)
 sub-processes it orchestrates.
 
 ## 4. Does / does-not
-- **Does:** tick-advance continuously at **90:1** (1 wall-second = 90 simulated seconds)
+- **Does:** tick-advance continuously at **90:1** (90 simulated seconds = 1 wall-second)
   across **six concurrent time horizons** — tick/hourly, daily, weekly, monthly, annual, and
   5-year forecast windows; every tick advances every sim; maintain populations of Pops whose
   behaviors emerge from the sim's mathematical model; ingest live data from Data Feeds (M2)
-  for calibration; respond to Trader queries with bounded predictions; produce outputs with
-  **explicit upper/lower bounds** on every prediction value.
+  for calibration; transform raw sim data into bounded predictions and publish them continuously
+  to the Marketplace via M2; produce outputs with **explicit upper/lower bounds** on every
+  prediction value.
   | Horizon | Window | Tick step | Effective ratio | Wall time for window |
   |---------|--------|-----------|-----------------|---------------------|
   | Tick–hourly | Next 1–60 min | 1s | 90:1 | ~40s |
@@ -37,27 +39,35 @@ sub-processes it orchestrates.
   | Annual | Next 365d | ~2.5 hr | ~788,000:1 | ~40s |
   | 5-year | Next 1825d | 12 hr | ~3,942,000:1 | ~40s |
 - **Does-not:** trade (Traders/Marketplace do); make decisions for traders (it informs, they
-  decide); enforce laws (Marketplace does); supervise behavior (Conductor/SAE do); skip ticks;
-  run slower than 90:1.
+  decide); enforce laws (Marketplace does); supervise behavior (Conductor/SAE do); receive
+  trader queries (traders query the Marketplace); skip ticks; run slower than 90:1.
 
 ## 5. Interface contract
-- `query(sim_type: SimType, query: PredictionQuery) -> BoundedPrediction`.
+- `publish(sim_type: SimType, prediction: BoundedPrediction)` — the hub continuously transforms
+  raw sim data into predictions and publishes them to the Marketplace via M2 Data Feeds. This is
+  a constant stream, not on-demand. Traders query predictions from the Marketplace (M1), not from
+  the sim hub.
   `SimType` ∈ { `statistical`, `sociological`, `amm_liquidity`, `mev_adversarial`,
   `tokenomics_macro`, `consensus_staking`, `market_microstructure` } (M3a–M3g).
-- `BoundedPrediction { value, lower_bound, upper_bound, confidence, time_horizon, sim_type, timestamp }`.
+- `BoundedPrediction { value, lower_bound, upper_bound, confidence, correctness, certainty,
+  time_horizon, sim_type, timestamp }`.
   Every output is bounded — no point estimates without uncertainty ranges.
-  `confidence` ∈ [0.00, 10.00] — printed as `7.62/10.00`. Gain rates print as
-  `lower - value - upper / 10.00` (e.g. `2.31 - 4.44 - 7.11 / 10.00 gain over next 30 days`);
+  Three quality metrics, each ∈ [0.00, 10.00]:
+  **confidence** — how sure the model is of this prediction;
+  **correctness** — how accurate the model has been historically;
+  **certainty** — how stable the estimate is across perturbations.
+  Gain rates print as `lower - value - upper / 10.00`
+  (e.g. `2.31 - 4.44 - 7.11 / 10.00 gain over next 30 days`);
   the denominator aids legibility — gain is not capped at 10.00.
   Example: `{ value: 7.2, lower_bound: 5.8, upper_bound: 8.9, confidence: 7.30,
-  time_horizon: "4h", sim_type: "amm_liquidity" }`.
+  correctness: 8.10, certainty: 6.50, time_horizon: "4h", sim_type: "amm_liquidity" }`.
 - `status(sim_type?) -> { running, pop_count, last_calibration, data_freshness }` — health check.
 - `calibrate(sim_type, feed_data: [NormalizedDatum])` — Data Feeds (M2) pushes live data for
   model recalibration.
 
 ## 6. Dependencies & stubs
 - M2 Data Feeds — calibration data source; *stub:* canned market data.
-- M5 Traders — query consumers; *stub:* canned queries.
+- M1 Marketplace — prediction consumer (via M2); *stub:* print predictions.
 - M3a–M3g sub-specs — individual sim implementations; *stub:* each returns fixed predictions.
 
 ## 7. Invariants / laws
@@ -70,24 +80,26 @@ sub-processes it orchestrates.
   steps and update less frequently. Each horizon completes its forecast window in **~40s wall
   time**. Each horizon runs **in parallel** — they are concurrent, not sequential. No horizon
   runs slower than 90:1.
-- **L4 (C4):** sims are **read-only from traders' perspective** — a query never mutates sim
-  state. Calibration happens only from Data Feeds (M2).
+- **L4 (C4):** sims are **read-only from traders' perspective** — traders consume predictions
+  from the Marketplace; they cannot mutate sim state. Calibration happens only from Data Feeds
+  (M2).
 - **L5 (C4):** each sim type is **independent** — failure in one sim does not cascade to others.
   Degraded sims report their status; traders handle missing predictions.
 - **L6 (C3):** Pops are **simulation constructs, not AI actors** — they follow mathematical
   rules within the sim. Traders (M5) are the AI actors.
 
 ## 8. Build steps
-1. Define `BoundedPrediction` shape and query protocol.
+1. Define `BoundedPrediction` shape (value, bounds, confidence/correctness/certainty).
 2. Build the sim runner (lifecycle management for always-on sims).
 3. Wire M2 Data Feeds → calibration pipeline.
 4. Implement sub-specs M3a–M3g as they land.
-5. Wire trader query interface.
+5. Wire continuous prediction publishing → M2 → Marketplace.
 
 ## 9. Tests
 Always-on: sim running after init without external trigger. Bounded output: every prediction has
-lower ≤ value ≤ upper. Query: trader receives prediction without mutating sim. Independence:
-one sim's failure doesn't affect others. Calibration: new data updates model state.
+lower ≤ value ≤ upper. Three metrics: confidence, correctness, certainty all present in every
+output. Publishing: predictions flow continuously to Marketplace via M2. Independence: one sim's
+failure doesn't affect others. Calibration: new data updates model state.
 
 ## 10. Open items
 - Pop lifecycle (birth/death/mutation within sims, or fixed populations?).