Rewrite M-series: crypto trading engine + market prediction sims

The initial M-series specs were wrong (text digestion pipeline). Replaced with the actual economy organ architecture: M0 hub (independent system, scoped autonomy, multi-layered braking) M1 Marketplace (multi-trader harness, deterministic law script, veto) M2 Data Feeds (RSS + live market, bridges Marketplace ↔ Sims) M3 Sims hub + 7 sub-specs (always-running, bounded predictions): M3a statistical, M3b sociological, M3c AMM/liquidity, M3d MEV/adversarial, M3e tokenomics/macro, M3f consensus/staking, M3g market microstructure M4 Wallets (sovereign custody, our keys only, 1:1 trader binding) M5 Traders (AI actors, wallet-bound, all tool calls monitored) M6 Conductor (supervisory AI, veto, pause/investigate, SAE intake) M7 SAE monitor (trader surveillance, Brain-compatible message format) Grounded in AMM invariant mechanics, MEV game theory, SDE tokenomics, and evolutionary consensus games. Tax stub for Verschwörern Veregeister. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-09-30 01:15:10 +00:00 · 2026-07-13 21:10:15 +00:00
parent 622b2bd73e
commit 98a6f9a0b1
23 changed files with 1076 additions and 537 deletions
@@ -1,66 +1,73 @@
 # M0 — Economy organ hub (the stomach)
 ## 1. Component
-The economy organ — the organism's **stomach**. An outer organ on Ichor that **digests external
+The economy organ — the organism's **stomach**. An **independent, self-governing system**: a
-input into context** and **tracks the cost of doing so**. Hub for the M-series sub-components
+multi-agentic market prediction oracle and cryptocurrency trading engine. Houses the Marketplace
-(M1–M7): ingestion, digestion, cost ledger, budget governor, context yield, provenance chain,
+(M1), Data Feeds (M2), Sims (M3), Wallets (M4), Traders (M5), Conductor (M6), and SAE monitor
-outer-bus exchange. "Economy" = the organ economizes: it spends scarce resources (tokens, compute,
+(M7). Communicates with the rest of the organism **via Ichor only** — reward signals back to the
-attention budget) to convert raw input into usable context, and **accounts for every unit spent**.
+organism are TBD and out of scope.
 "A stomach rarely consults a brain for permission to digest." The economy organ operates with
 **scoped autonomy** and **multiple layers of failsafe braking** — it does not ask the organism's
 Brain for permission to trade.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. A `Stomach` primitive exists in Ichor (`src/ichor/envelope.pony:20`) with
 one smoke-test wire (`main.pony:29`), but no dedicated organ code. Role C4; implementation C1.
 ## 3. Language & location
-TBD · new location e.g. `src/economy/`. The digestion core (M2) requires a small-model runtime;
+TBD · new location e.g. `src/economy/`. The organ is polyglot by nature: trading infrastructure
-the accounting/budget layers (M3–M4) can be any language that interops with Pony (Ichor) and Ada
+(APIs, wallets) may differ in language from simulations (numerical computing) and the conductor
-(D1). Pony actors are the natural fit for the bus-facing facade.
+(AI supervision). Pony actors provide the Ichor-facing facade.
 ## 4. Does / does-not
- **Does:** receive external input from Ichor; triage and classify it (M1); digest it via a small
+- **Does:** host crypto/NFT trading via the Marketplace (M1); run always-on market prediction
-  model into context (M2); track the resource cost of that digestion (M3); enforce budget limits
+  Sims (M3) fed by live Data Feeds (M2); manage sovereign-custody Wallets (M4); supervise
-  and emit price signals to A2 (M4); shape output for Ada (M5); maintain provenance through the
+  Traders (M5) via a Conductor (M6) and SAE monitor (M7); collect taxes on trader income and
-  pipeline (M6); coordinate with outer-bus peers — MoRAG, SAE, microagents (M7).
+  stub transfer to Verschwörern Veregeister wallets.
- **Does-not:** police (Ada D1 does that); decide actions (the agent decides, per A1-L3); store
+- **Does-not:** consult the organism's Brain for trade decisions (scoped autonomy); route around
-  memories (E*); route the bus (Ichor broker); reason or deliberate (it digests, it doesn't think).
+  Ada for organism-bound messages (S1); store organism memories (E*); act as the organism's
  conscience (that's Eth-Int / A6).
 ## 5. Interface contract
- `ingest(external_input, provenance) -> classified_input` (M1 — triage + classify).
+- **Ichor interface (outbound):** `Envelope(Stomach, AdaBorder, OrganSecretion, payload)` — market
- `digest(classified_input) -> digested_context` (M2 — small-model transform).
+  state summaries, prediction digests, and tax receipts cross Ada to reach the inner brain.
- `record_cost(organ_id, action, resource_amt) -> receipt` (M3 — ledger entry).
+- **Ichor interface (inbound):** organism directives arrive via Ichor (e.g. risk posture changes,
- `check_budget(organ_id, proposed_cost) -> { allowed:bool, remaining:num }` (M4).
+  budget adjustments from A2 energy).
- `price_signal(tool_id) -> { resource_cost:num, budget_remaining:num }` (M4 → A2).
+- **Internal wiring:** Marketplace (M1) ↔ Data Feeds (M2) ↔ Sims (M3). Wallets (M4) bind to
- `yield(digested_context) -> Envelope` (M5 — shaped for Ada, with M6 provenance chain attached).
+  Traders (M5). Conductor (M6) supervises Traders via SAE (M7). All trader actions route through
- Output is an Ichor `Envelope` with `OrganSecretion` provenance, carrying the original input's
+  Marketplace.
-  provenance origin in metadata (M6).
+- **Tax stub:** `transfer_tax(amount, source_wallet, dest_wallet) -> receipt` — automation hook
  for Verschwörern Veregeister internal wallet-to-wallet transfer. **Out of scope** — stub only.
 ## 6. Dependencies & stubs
 - Ichor bus (D2) — existing `Broker` + `Envelope`.
- Ada border (D1) — existing `Trust_Guard` screens the output; *stub:* Ichor `Barrier`.
+- Ada border (D1) — screens outbound organism messages; *stub:* Ichor `Barrier`.
- A2 energy — consumes price signals (M4); *stub:* print signals.
+- A2 energy — potential consumer of economic signals; *stub:* no integration initially.
- MoRAG (F1) — world-context retrieval; *stub:* fixed context.
+- Verschwörern Veregeister wallets — tax destination; *stub:* log transfer, no real wallet.
 ## 7. Invariants / laws
 - **L1 (C5):** the stomach is an **OUTER** organ — it rides Ichor, never the inner bus.
- **L2 (C4):** digestion does **not suppress** — it transforms for comprehension (summarize,
+- **L2 (C5):** **scoped autonomy** — the organ trades without Brain permission, but within
-  classify, extract), never censors. Filtering is Ada's job (D1).
+  deterministic law constraints (M1) and Conductor oversight (M6).
- **L3 (C4):** every resource expenditure is **accounted** — no digestion is "free"; the ledger
+- **L3 (C4):** **all market actions route through the Marketplace** (M1) — no trader may
-  (M3) records every token/compute unit spent.
+  execute directly on-chain without the Marketplace harness.
- **L4 (C4):** provenance survives digestion — digested content retains its original provenance
+- **L4 (C4):** **sovereign custody only** — all wallets are local-hosted, our keys, never
-  origin in metadata, even as bus transport uses `OrganSecretion` (see M6, S1/S2).
+  delegated to exchanges or third parties (M4).
 - **L5 (C4):** **multi-layered braking** — deterministic law script (M1), Conductor veto (M6),
  SAE surveillance (M7), and wallet-level limits (M4) each independently constrain risk.
 ## 8. Build steps
-1. Define the hub wiring: how M1→M2→M5 pipeline + M3/M4 accounting + M6 provenance + M7 peers
+1. Define the internal wiring topology (how M1–M7 connect).
   connect. Decide: single Pony actor or actor-per-subcomponent.
 2. Extend the existing `Stomach` primitive in Ichor to carry the hub facade.
-3. Wire sub-components as their specs land (M1–M7).
+3. Wire sub-components as their specs land.
-4. Integrate price signals with A2 (energy driver).
+4. Implement the tax stub for Verschwörern Veregeister transfer.
 ## 9. Tests
-Hub smoke: external input enters → classified → digested → yielded as Envelope → reaches Ada stub.
+Hub smoke: Marketplace reachable; Sims running and queryable; Wallet bound to Trader; Conductor
-Cost recorded in ledger. Budget check returns correct remaining. Price signal emitted.
+receives SAE reports; tax stub logs transfer. Ichor: outbound envelope reaches Ada stub.
 ## 10. Open items
- Single actor vs actor-per-subcomponent (Pony concurrency model for the organ).
+- Reward signal protocol from economy organ to organism (TBD, out of scope).
- Whether the hub owns state or is purely a wiring facade (stateless router vs stateful coordinator).
+- Internal communication bus (reuse Ichor internally? separate actor topology?).
- The A2 price-signal protocol (push vs pull; frequency).
+- Language choices per sub-component.
@@ -1,60 +0,0 @@
 # M1 — Ingestion gateway
 ## 1. Component
 The mouth of the stomach: **receives, classifies, and triages** external input before it enters the
 digestion pipeline (M2). The first thing raw input touches inside the economy organ. Decides *how*
 to digest — not *whether* (that's Ada's job after digestion).
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. The smoke test (`main.pony:29`) hard-codes a single string payload; no
 classification or triage logic exists. Role C3; implementation C1.
 ## 3. Language & location
 TBD · likely part of `src/economy/` or a Pony actor within the stomach. Classification could be
 rule-based (fast, no model) or a lightweight classifier (BERT-tiny, shared with F1/MoRAG's BERT).
 ## 4. Does / does-not
 - **Does:** accept raw `Envelope` payloads from Ichor; classify input by type (user utterance,
  tool output, system event, bulk data); assign a **digestion priority** (urgent / normal / bulk);
  estimate the **digestion cost** (token count of input × expected expansion factor) and check
  budget (M4) before forwarding to M2.
 - **Does-not:** filter or censor (M0-L2); digest (M2 does); decide actions (agent decides);
  screen provenance (Ada D1).
 ## 5. Interface contract
 - `ingest(envelope: Envelope) -> ClassifiedInput { type, priority, est_cost, original_provenance, payload }`
 - `type` ∈ { `user_utterance`, `tool_output`, `system_event`, `bulk_data`, `unknown` }.
 - `priority` ∈ { `urgent`, `normal`, `bulk` } — urgent skips any queue; bulk may be deferred or
  chunked under budget pressure (M4).
 - `est_cost` = estimated token cost of digesting this input (input tokens + expected output tokens).
  M4 checks this against remaining budget before M2 proceeds.
 - `original_provenance` = the `Provenance` from the inbound Envelope, carried through for M6.
 ## 6. Dependencies & stubs
 - Ichor `Envelope` (existing) — input shape.
 - M4 budget governor — budget check before forwarding; *stub:* always-allow.
 - M2 digestion core — downstream consumer; *stub:* identity (pass-through).
 ## 7. Invariants / laws
 - **L1 (C4):** classification is **descriptive, not prescriptive** — it labels the input for the
  pipeline's benefit, never decides what to do with it.
 - **L2 (C4):** no input is **dropped** at ingestion — everything classified reaches M2 (possibly
  deferred under budget pressure, but never discarded). Only Ada may reject.
 - **L3 (C3):** cost estimation is **conservative** — overestimate rather than underestimate, so
  budget checks err on the side of caution.
 ## 8. Build steps
 1. Define the `ClassifiedInput` shape and the classification rules (start rule-based, no model).
 2. Implement cost estimation (token counting + expansion factor).
 3. Wire to M4 budget check (gate: proceed / defer / chunk).
 4. Wire to M2 downstream.
 ## 9. Tests
 Classification: each input type correctly tagged. Priority: urgent input not queued. Cost estimate:
 known inputs produce expected token counts. Budget gate: over-budget input deferred, not dropped.
 ## 10. Open items
 - Whether classification needs a model or rules suffice (start with rules; promote if accuracy
  demands it).
 - The expansion factor (input tokens → output tokens) per input type — needs empirical data (C1).
 - Queue/deferral mechanics for bulk input under budget pressure.
@@ -0,0 +1,75 @@
 # M1 — Marketplace (multi-trader harness)
 ## 1. Component
 The economy organ's trading floor: a **multi-trader harness** through which **all market actions
 must route**. No trader may buy, sell, mint, or interact with any on-chain protocol except through
 the Marketplace. Enforces a **deterministic law script** (scoped invariants — the marketplace's
 own constitution) and integrates the **Conductor's veto** (M6) before execution.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C4; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/marketplace/`. Needs to interface with blockchain APIs (RPC/REST), wallet
 signing (M4), and the Conductor (M6). Deterministic law script must be auditable and non-Turing
 (no unbounded loops — it's a constitution, not a program).
 ## 4. Does / does-not
 - **Does:** receive trade requests from Traders (M5); validate against the deterministic law
  script (scoped invariants); check Conductor veto (M6); verify trader-wallet binding (no wallet
  = no access); execute approved actions on-chain via the bound wallet's API; record all actions
  for SAE (M7) monitoring; collect tax on realized income → Verschwörern Veregeister stub (M0).
 - **Does-not:** decide *what* to trade (Traders decide); predict markets (Sims do); hold keys
  (Wallets do); supervise behavior (Conductor + SAE do).
 ## 5. Interface contract
 - `submit_action(trader_id, action: MarketAction, wallet_id) -> { accepted | vetoed | law_violation | no_wallet }`.
  `MarketAction` ∈ { `buy`, `sell`, `mint`, `provide_liquidity`, `withdraw_liquidity`, `claim_rewards`, … }.
 - `law_check(action: MarketAction) -> { pass | violation(rule_id, reason) }` — deterministic,
  pure function. The law script is loaded at startup and **immutable at runtime** (mirrors S3 /
  the COBOL vault pattern).
 - `veto_check(action: MarketAction, trader_id) -> { approved | vetoed(reason) }` — calls M6
  Conductor.
 - `execute(action: MarketAction, wallet_id) -> { tx_hash | error }` — on-chain execution via
  wallet API.
 - `tax_event(trader_id, income_amount) -> receipt` — triggers tax collection.
 ## 6. Dependencies & stubs
 - M4 Wallets — signing + execution; *stub:* mock wallet that logs transactions.
 - M5 Traders — action source; *stub:* canned trade requests.
 - M6 Conductor — veto authority; *stub:* always-approve.
 - M7 SAE — action log consumer; *stub:* print actions.
 - Blockchain RPCs — on-chain execution; *stub:* simulated chain responses.
 ## 7. Invariants / laws
 - **L1 (C5):** **all market actions route through the Marketplace** — no direct on-chain
  execution by any trader. This is the economy organ's S1.
 - **L2 (C5):** the **deterministic law script is immutable at runtime** — loaded at startup,
  never modified by traders, conductor, or sims. Changes require a restart with a new script
  version. Mirrors the COBOL vault (S3).
 - **L3 (C4):** **no wallet, no access** — a trader without a bound wallet cannot submit actions.
  The Marketplace enforces this before any other check.
 - **L4 (C4):** **veto is checked after law, before execution** — law violations are rejected
  outright; Conductor veto applies only to law-passing actions. The law is above the Conductor.
 - **L5 (C4):** **every action is logged** — SAE (M7) receives a record of every submitted
  action (including rejected ones) for behavioral analysis.
 ## 8. Build steps
 1. Define `MarketAction` types and the law script format.
 2. Implement the law checker (deterministic, pure, non-Turing).
 3. Wire veto check to M6 Conductor.
 4. Wire execution to M4 Wallet API.
 5. Wire action logging to M7 SAE.
 6. Implement tax collection on realized income.
 ## 9. Tests
 Law enforcement: known violations rejected; valid actions pass. Veto: conductor veto blocks
 execution. Wallet binding: walletless trader rejected. Logging: every action (pass + fail) logged.
 Tax: income event triggers tax stub. Immutability: law script cannot be modified at runtime.
 ## 10. Open items
 - The law script language/format (DSL? declarative rules? S-expressions?).
 - Which blockchain protocols/RPCs to support initially.
 - Position limits, drawdown stops, and other risk parameters — live in the law script or in the
  Conductor's judgment?
 - Tax rate / calculation method (fixed %, tiered, per-asset?).
@@ -0,0 +1,70 @@
 # M2 — Data feeds (market data pipeline)
 ## 1. Component
 The economy organ's sensory nervous system: **live RSS feeds, price streams, and on-chain data**
 flowing into both the Marketplace (M1) and the Sims (M3). Sits between them — the Marketplace
 produces execution data (fills, positions, P&L) that feeds back into Sims, and Sims produce
 predictions that inform Traders operating through the Marketplace. Data Feeds is the bridge.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C3; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/feeds/`. Needs async I/O for streaming data (WebSockets, SSE, RSS polling).
 Pony actors are a natural fit (async, backpressure-aware). Python or Rust for API client libs.
 ## 4. Does / does-not
 - **Does:** ingest live market data from external sources (RSS, price APIs, DEX subgraphs,
  on-chain event logs); normalize heterogeneous data into a common internal format; distribute
  to Sims (M3) for prediction and to Traders (M5) for decision-making; ingest Marketplace (M1)
  execution data (fills, portfolio state) and feed it back into Sims for calibration; maintain
  time-series history within session (ring buffer).
 - **Does-not:** predict (Sims do); trade (Marketplace does); filter or editorialize data — it
  delivers raw, normalized feeds. Interpretation is the consumer's job.
 ## 5. Interface contract
 - `subscribe(feed_type: FeedType, consumer_id) -> subscription_handle`.
  `FeedType` ∈ { `price_tick`, `rss_news`, `on_chain_event`, `dex_pool_state`, `execution_fill`,
  `portfolio_state` }.
 - `publish(feed_type, data_point: NormalizedDatum)` — internal; sources push into the pipeline.
 - `query_history(feed_type, time_range) -> [NormalizedDatum]` — sims and traders can pull
  historical data within the session window.
 - `NormalizedDatum { feed_type, source, timestamp, payload, confidence }` — common shape.
  `confidence` ∈ [0.0, 1.0] — data source reliability (exchange-reported price = high; RSS
  sentiment = lower).
 ## 6. Dependencies & stubs
 - External data sources (price APIs, RSS, RPC nodes) — *stub:* canned market data replay.
 - M1 Marketplace — execution data source (fills, positions); *stub:* canned fills.
 - M3 Sims — primary consumer; *stub:* print data points.
 - M5 Traders — secondary consumer; *stub:* print data points.
 ## 7. Invariants / laws
 - **L1 (C4):** data feeds are **raw and unnormalized in meaning** — the pipeline normalizes
  *format* (schema, timestamps, units) but never interprets, filters, or editorialize content.
 - **L2 (C4):** **bidirectional flow** — external data flows in (market → sims/traders), and
  internal execution data flows back (marketplace → sims). Both directions use the same
  `NormalizedDatum` shape.
 - **L3 (C3):** **backpressure, not drop** — if a consumer is slow, buffer up to a cap, then
  apply backpressure to the source. Never silently drop data points.
 - **L4 (C3):** every datum carries a **source and timestamp** — consumers can always trace
  where data came from and when.
 ## 8. Build steps
 1. Define `NormalizedDatum` and `FeedType` shapes.
 2. Implement the pub/sub pipeline (subscribe, publish, distribute).
 3. Wire external source adapters (start with one price API + one RSS feed).
 4. Wire M1 execution data feedback loop.
 5. Implement session-scoped time-series history (ring buffer).
 ## 9. Tests
 Normalization: heterogeneous inputs produce uniform `NormalizedDatum` output. Pub/sub: subscriber
 receives published data. History: query returns correct time range. Backpressure: slow consumer
 does not cause data loss. Bidirectional: marketplace fills reach sims via the feed.
 ## 10. Open items
 - Which price APIs / RSS sources to support initially (CoinGecko? DeFiLlama? specific DEX
  subgraphs?).
 - History buffer size / eviction policy.
 - Whether feeds need authentication / rate limiting management.
 - Latency requirements (how fresh must data be for each consumer type?).
@@ -1,70 +0,0 @@
 # M2 — Digestion core (small-model)
 ## 1. Component
 The stomach's engine: a **small language model** that transforms classified input (M1) into
 **digested context** — structured, compressed, ready for Ada and ultimately the Brain. This is
 what "digests external input → context" means concretely: summarization, extraction, reformatting,
 and compression, performed by a model small enough to run cheaply and fast.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. bus-topology.md names it "small-model operated" but leaves the model
 unspecified (listed as open). Role C3; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/digest/` or similar. Requires an inference runtime for the small model
 (e.g. llama.cpp, ONNX, or an API call to a hosted small model). The wrapper is likely Pony
 (bus-native) or Python (ML ecosystem), with a Pony actor facade on Ichor.
 ## 4. Does / does-not
 - **Does:** take `ClassifiedInput` (M1); run the small model to produce `DigestedContext` —
  **summarize** (compress verbose input), **extract** (pull structured data from unstructured),
  **reformat** (normalize into the context shape Ada/Brain expect); report actual cost to M3.
 - **Does-not:** classify (M1 already did); filter/censor (M0-L2 — digest for comprehension, not
  approval); reason or deliberate (the Brain does that); call tools or take actions.
 ## 5. Interface contract
 - `digest(input: ClassifiedInput) -> DigestedContext { summary, extractions[], source_ref, actual_cost }`.
 - `summary`: compressed natural-language context (the "chewed food").
 - `extractions`: structured key-value pairs pulled from the input (entities, quantities, intents).
 - `source_ref`: pointer back to the original input (for M6 provenance chain).
 - `actual_cost`: real token count consumed (input + output), reported to M3 ledger.
 - The model is invoked with a **system prompt specific to digestion** — not the agent's system
  prompt. The digestion prompt instructs: summarize, extract, reformat; do not opine, decide, or
  filter.
 ## 6. Dependencies & stubs
 - M1 `ClassifiedInput` — upstream; *stub:* canned classified input.
 - M3 cost ledger — receives `actual_cost`; *stub:* print cost.
 - Small model runtime — *stub:* a deterministic mock that returns fixed summaries for known inputs
  (no model needed for unit tests).
 ## 7. Invariants / laws
 - **L1 (C4):** digestion is **lossy compression, not judgment** — the model summarizes and
  extracts but never evaluates, approves, or filters the content. It chews; it doesn't taste.
 - **L2 (C4):** the digestion prompt is **fixed and auditable** — not dynamically generated, not
  influenced by the input being digested (no prompt injection path from input to digestion
  instructions).
 - **L3 (C3):** **actual cost is always reported** — every invocation records real token usage to
  M3; no "free" digestions.
 - **L4 (C3):** the model is **small by design** — cost and latency must stay below the threshold
  where digestion becomes more expensive than passing raw input. If the model is too expensive,
  the organ is failing its economic purpose.
 ## 8. Build steps
 1. Select the small model (candidates: Haiku-class, phi-3-mini, or similar; evaluate on
   summarization quality vs cost vs latency).
 2. Write the fixed digestion system prompt.
 3. Build the inference wrapper (model invocation + output parsing).
 4. Wire M1 → M2 → M3 (cost reporting) → M5 (output shaping).
 ## 9. Tests
 Mock model: known input → expected summary + extractions. Cost reporting: actual_cost recorded for
 every invocation. Prompt integrity: digestion prompt is the fixed string (no injection). Latency:
 invocation completes within budget (TBD threshold).
 ## 10. Open items
 - **Model selection** (C1) — which small model, self-hosted vs API, quantization level.
 - **Digestion prompt** (C1) — exact wording; needs empirical tuning against real inputs.
 - Latency budget (C1) — max acceptable ms per digestion; ties to how it's invoked (batch vs streaming).
 - Whether different input types (M1 classification) get different digestion strategies or one
  model handles all.
@@ -1,63 +0,0 @@
 # M3 — Cost ledger
 ## 1. Component
 The stomach's accounting book: records **every resource expenditure** across the economy organ and,
 optionally, across the organism. Every token spent on digestion (M2), every budget check (M4),
 every outer-bus exchange (M7) — the ledger knows. This is the "money" in "M for money": if it
 costs something, it's in the ledger.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. No cost tracking exists anywhere in the system. A2 (energy driver) tracks
 an internal activation/rest budget but has no concept of external resource costs. Role C3;
 implementation C1.
 ## 3. Language & location
 TBD · `src/economy/ledger/` or similar. Needs durable-enough storage to survive a session (but
 the container is ephemeral, so "durable" means in-memory with optional flush — not a database).
 Could be R (to sit near A2), Pony (bus-native), or a simple append-only log.
 ## 4. Does / does-not
 - **Does:** record every resource expenditure as a `LedgerEntry` (who spent, what action, how much,
  when); provide totals by organ, by action type, and grand total; answer "how much has been spent?"
  and "how much is left?" (the latter via M4's budget).
 - **Does-not:** decide whether to spend (M4 governs that); price tools (A2 does); restrict actions
  (Ada D1 polices); optimize or suggest cheaper paths (that's a future concern, not a ledger's job).
 ## 5. Interface contract
 - `record(entry: LedgerEntry) -> receipt_id`.
  `LedgerEntry { organ_id, action, resource_type, amount, timestamp }`.
  `resource_type` ∈ { `input_tokens`, `output_tokens`, `compute_ms`, `api_call` }.
 - `total(filter?) -> num` — total spent, optionally filtered by organ/action/resource_type/time range.
 - `entries(filter?) -> [LedgerEntry]` — raw entries for audit.
 - The ledger is **append-only** at runtime — entries are never modified or deleted (the books don't
  get cooked). A session-start reset is fine (ephemeral container).
 ## 6. Dependencies & stubs
 - M2 digestion core — primary cost source (reports `actual_cost` per digestion).
 - M4 budget governor — reads totals to compute remaining budget; *stub:* the ledger is usable
  without M4 (it just records, doesn't enforce).
 - A2 energy driver — potential consumer of cost data for pricing; *stub:* no integration initially.
 ## 7. Invariants / laws
 - **L1 (C4):** the ledger is **append-only** — no entry is ever mutated or deleted at runtime.
 - **L2 (C4):** **completeness** — every resource expenditure in the economy organ produces a
  ledger entry; no "off-books" spending.
 - **L3 (C3):** the ledger is **passive** — it records, it never blocks or delays an action.
  Enforcement is M4's job.
 ## 8. Build steps
 1. Define `LedgerEntry` shape and the append-only store (in-memory list; consider a ring buffer
   with a cap if memory is a concern in long sessions).
 2. Wire M2 → M3 (digestion cost recording).
 3. Implement `total` and `entries` queries with filtering.
 4. Optional: flush to disk / log file for post-session audit.
 ## 9. Tests
 Append: entries accumulate, count matches. Immutability: no mutation API exists. Totals: filtered
 totals match manual sum. Completeness: a mock M2 digestion produces a corresponding ledger entry.
 ## 10. Open items
 - Whether the ledger scope extends beyond the economy organ to track costs for other organs
  (MoRAG model calls, SAE compute, Brain inference). Start organ-scoped; expand if needed.
 - Storage cap / eviction policy for very long sessions (ring buffer vs unbounded).
 - Post-session export format (JSON log? CSV?).
@@ -0,0 +1,75 @@
 # M3 — Sims hub (market prediction simulations)
 ## 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).
 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].
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C3; implementation C1. Mathematical foundations C4 (literature
 established); specific model parameters C1.
 ## 3. Language & location
 TBD · `src/economy/sims/`. Numerical computing (Julia, Python/NumPy, Octave, or Rust) for the
 simulation cores. A query facade accessible to Traders. Each sim type (M3a–M3g) may use a
 different runtime suited to its math.
 ## 4. Does / does-not
 - **Does:** run continuously across multiple time scales (tick-level, hourly, daily, weekly);
  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.
 - **Does-not:** trade (Traders/Marketplace do); make decisions for traders (it informs, they
  decide); enforce laws (Marketplace does); supervise behavior (Conductor/SAE do).
 ## 5. Interface contract
 - `query(sim_type: SimType, query: PredictionQuery) -> BoundedPrediction`.
  `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 }`.
  Every output is bounded — no point estimates without uncertainty ranges.
  Example: `{ value: 7.2, lower_bound: 5.8, upper_bound: 8.9, confidence: 0.73,
  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.
 - M3a–M3g sub-specs — individual sim implementations; *stub:* each returns fixed predictions.
 ## 7. Invariants / laws
 - **L1 (C5):** sims are **always running** — they are not invoked on demand. Traders query
  current state; they don't trigger computation.
 - **L2 (C5):** every prediction output includes **explicit upper and lower bounds** — no
  unbounded point estimates. Uncertainty is a first-class value, not an afterthought.
 - **L3 (C4):** sims are **read-only from traders' perspective** — a query never mutates sim
  state. Calibration happens only from Data Feeds (M2).
 - **L4 (C4):** each sim type is **independent** — failure in one sim does not cascade to others.
  Degraded sims report their status; traders handle missing predictions.
 - **L5 (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.
 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.
 ## 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.
 ## 10. Open items
 - Pop lifecycle (birth/death/mutation within sims, or fixed populations?).
 - Cross-sim aggregation (do traders query individual sims, or is there a meta-prediction layer?).
 - Calibration frequency per sim type.
 - Computational budget per sim (how much CPU/GPU each can consume).
@@ -0,0 +1,59 @@
 # M3a — Statistical & quantitative sims
 ## 1. Component
 Pure statistical simulation: **Monte Carlo methods, Bayesian inference, time-series forecasting,
 and volatility modeling**. The mathematical backbone — no game theory, no sociology, just the
 numbers. Operates across multiple time scales (tick to weekly). Pops in this sim represent
 **stochastic sample paths**, not behavioral agents.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Mathematical foundations C4 (standard quant methods); parameterization C1.
 ## 3. Language & location
 TBD · `src/economy/sims/statistical/`. Python (NumPy/SciPy), Julia, or R for numerical
 computing. Needs efficient matrix operations and distribution sampling.
 ## 4. Does / does-not
 - **Does:** run Monte Carlo price simulations (geometric Brownian motion, jump-diffusion);
  Bayesian parameter estimation from live data (M2); time-series forecasting (ARIMA, GARCH for
  volatility clustering); Value-at-Risk and Expected Shortfall calculations; produce bounded
  predictions with confidence intervals as upper/lower bounds.
 - **Does-not:** model human behavior (M3b does); model protocol mechanics (M3c–M3f do);
  trade or recommend (Traders do).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** statistical confidence intervals.
  Example: `{ value: 1847.30, lower_bound: 1790.15, upper_bound: 1905.60, confidence: 0.95,
  time_horizon: "24h", sim_type: "statistical" }` — 95% CI on ETH price.
 - **Prediction types:** `price_forecast`, `volatility_estimate`, `var_calculation`,
  `correlation_matrix`, `regime_detection`.
 - Calibration: ingests `price_tick` and `dex_pool_state` from M2 Data Feeds.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — price history for calibration; *stub:* canned price series.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C4):** bounds are **statistical confidence intervals** — derived from the model's
  distribution, not hand-picked. The confidence level (e.g. 0.95) is explicit in the output.
 - **L2 (C4):** **multiple time scales run concurrently** — a tick-level volatility estimate and a
  weekly price forecast coexist; neither blocks the other.
 - **L3 (C3):** model parameters are **re-estimated on each calibration** from live data — no
  stale parameters carried across regime changes.
 ## 8. Build steps
 1. Implement geometric Brownian motion Monte Carlo (simplest price sim).
 2. Add GARCH volatility estimation.
 3. Wire M2 price data → Bayesian parameter re-estimation.
 4. Implement the `BoundedPrediction` output with CIs.
 ## 9. Tests
 Monte Carlo: N sample paths produce a distribution with correct mean/variance. CI: 95% interval
 contains true value ≥ 95% of the time on historical backtest. GARCH: volatility clusters detected
 in synthetic data. Calibration: new data shifts parameter estimates.
 ## 10. Open items
 - Which distributions beyond GBM (heavy-tailed? Lévy?).
 - Regime-switching model complexity (hidden Markov? threshold?).
 - Computational budget (how many Monte Carlo paths per tick?).
@@ -0,0 +1,67 @@
 # M3b — Sociological & population dynamics sims
 ## 1. Component
 Sociological simulation: **evolutionary game theory, bounded rationality, sentiment cascades, and
 population dynamics** among market participants. Pops here are **behavioral archetypes** — retail
 herd followers, contrarian whales, MEV searchers, passive LPs — whose strategies evolve under
 selection pressure. Grounded in evolutionary consensus game models [8,9] and bounded-rationality
 coordination frameworks.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Evolutionary game-theory foundations C4 (Cornell blockchain cooperation
 literature [8]); pop behavioral models C1.
 ## 3. Language & location
 TBD · `src/economy/sims/sociological/`. Agent-based modeling frameworks (Mesa/Python, NetLogo,
 or custom). Needs efficient population iteration and strategy mutation.
 ## 4. Does / does-not
 - **Does:** simulate populations of behavioral archetypes competing in a market; apply
  evolutionary dynamics (replicator equation, mutation, selection) to strategy distributions;
  model sentiment cascades (fear/greed contagion across pop clusters); model bounded rationality
  (pops satisfice, not optimize — they follow heuristics, not perfect strategies); produce
  bounded predictions on market sentiment, herd behavior thresholds, and coordination breakdowns.
 - **Does-not:** model protocol mechanics (M3c–M3f); compute statistical forecasts (M3a);
  represent real individuals (pops are archetypes, not profiles).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** population-fraction ranges and sentiment scales.
  Example: `{ value: 7.3, lower_bound: 5.0, upper_bound: 9.1, confidence: 0.68,
  time_horizon: "12h", sim_type: "sociological" }` — herd-panic index on a 0–10 scale.
  Example: `{ value: 0.42, lower_bound: 0.31, upper_bound: 0.55, confidence: 0.72,
  time_horizon: "1w", sim_type: "sociological" }` — fraction of pops in "contrarian" strategy.
 - **Prediction types:** `sentiment_index`, `herd_threshold`, `strategy_distribution`,
  `cascade_probability`, `coordination_stability`.
 - Calibration: ingests `rss_news` (sentiment signal) and `price_tick` (realized behavior) from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — sentiment and price data for calibration; *stub:* canned sentiment series.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C4):** pops are **archetypes, not individuals** — no attempt to model or track real
  market participants. The sim models emergent behavior from strategy populations.
 - **L2 (C4):** strategies **evolve** — the population distribution shifts over time via
  replicator dynamics. No fixed strategy ratios.
 - **L3 (C3):** bounded rationality is the **default** — pops satisfice with heuristics, not
  optimize with perfect information. Rational-agent models are a special case, not the baseline.
 ## 8. Build steps
 1. Define pop archetypes and their heuristic strategies.
 2. Implement replicator dynamics (strategy evolution over generations).
 3. Implement sentiment contagion model (network-based cascade).
 4. Wire M2 news/price data → calibration of pop parameters.
 5. Implement `BoundedPrediction` output with population-fraction CIs.
 ## 9. Tests
 Evolution: dominant strategy shifts when payoff landscape changes. Cascade: sentiment shock
 propagates through pop network above threshold, not below. Bounded rationality: satisficing pop
 underperforms optimizer in simple games but outperforms in noisy environments. Bounds: all
 outputs include upper/lower.
 ## 10. Open items
 - Pop archetype catalog (which behavioral types? how many?).
 - Network topology for sentiment contagion (small-world? scale-free?).
 - Calibration from real market data — how to infer pop distribution from observable price action.
 - Cross-sim interaction: do sociological predictions feed into M3c (AMM) or M3d (MEV)?
@@ -0,0 +1,66 @@
 # M3c — AMM & liquidity pool sims
 ## 1. Component
 Automated Market Maker simulation: models **constant-product invariant mechanics, impermanent
 loss, and the non-cooperative game between liquidity providers and arbitrageurs**. Pops here are
 **LP positions and arbitrage bots** operating on the $x \cdot y = k$ curve. Grounded in the DEX/AMM
 literature [1,2].
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Mathematical foundations C5 (constant product invariant is proven);
 impermanent loss formula C5 (closed-form: $\text{IL}(r) = \frac{2\sqrt{r}}{1+r} - 1$);
 simulation parameterization C1.
 ## 3. Language & location
 TBD · `src/economy/sims/amm/`. Needs precise fixed-point or arbitrary-precision arithmetic for
 invariant calculations (Solidity-equivalent precision). Python, Rust, or Julia.
 ## 4. Does / does-not
 - **Does:** simulate constant-product pools with fee parameter $\gamma$:
  $(x + \gamma \Delta x)(y - \Delta y) = k$; model impermanent loss as a function of price ratio
  shift $r$; simulate LP strategies (provide, withdraw, rebalance) against arbitrageur behavior;
  model non-linear price slippage from the curve geometry; produce bounded predictions on pool
  profitability, IL risk, and optimal LP ranges.
 - **Does-not:** model consensus mechanics (M3f); model social behavior (M3b); execute real swaps
  (Marketplace does).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** IL ranges and pool return intervals.
  Example: `{ value: -0.034, lower_bound: -0.058, upper_bound: -0.012, confidence: 0.90,
  time_horizon: "7d", sim_type: "amm_liquidity" }` — projected impermanent loss for ETH/USDC pool.
  Example: `{ value: 0.082, lower_bound: 0.041, upper_bound: 0.127, confidence: 0.85,
  time_horizon: "30d", sim_type: "amm_liquidity" }` — net LP return (fees − IL).
 - **Prediction types:** `impermanent_loss`, `pool_return`, `optimal_range`, `slippage_estimate`,
  `lp_withdrawal_threshold`.
 - Calibration: ingests `dex_pool_state` and `price_tick` from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — pool state and price data; *stub:* canned pool snapshots.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C5):** the **constant product invariant** $x \cdot y = k$ (adjusted for fees $\gamma$)
  is the ground truth — all pool state transitions must satisfy the invariant or the sim is wrong.
 - **L2 (C5):** **impermanent loss** follows the proven formula
  $\text{IL}(r) = \frac{2\sqrt{r}}{1+r} - 1$ — the sim must reproduce this exactly for the
  base case (no fees, no concentrated liquidity).
 - **L3 (C4):** LP withdrawal thresholds are **derived from IL, not hardcoded** — the sim
  calculates at what price ratio a rational LP withdraws, based on the IL formula and fee income.
 ## 8. Build steps
 1. Implement the constant-product pool simulator with fee parameter.
 2. Verify IL formula reproduction against known inputs.
 3. Add LP pop strategies (passive hold, active rebalance, just-in-time liquidity).
 4. Add arbitrageur pops (sandwich, backrun).
 5. Wire M2 pool state data → calibration.
 ## 9. Tests
 Invariant: every swap satisfies $(x + \gamma \Delta x)(y - \Delta y) = k$. IL formula: matches
 closed-form for known price ratios. Slippage: large swaps produce greater slippage than small.
 LP threshold: LP withdraws when IL exceeds fee income. Bounds: all outputs bounded.
 ## 10. Open items
 - Concentrated liquidity (Uniswap v3 style) — extends the base model significantly.
 - Multi-pool routing (split swaps across pools).
 - Which specific pools to simulate (ETH/USDC? stablecoin pairs?).
@@ -0,0 +1,69 @@
 # M3d — MEV & adversarial extraction sims
 ## 1. Component
 Maximal Extractable Value simulation: models **transaction ordering as an optimization problem**,
 **Priority Gas Auctions (PGA) as all-pay auctions**, and **block building as a multidimensional
 knapsack problem**. Pops here are **searcher bots, block builders, and validators** competing for
 extractable value. Grounded in ACM MEV game theory [3] and knapsack auction literature [4,5].
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. PGA-as-all-pay-auction model C4 (ACM [3]); knapsack formulation C4
 (Cornell [4,5]); simulation parameterization C1.
 ## 3. Language & location
 TBD · `src/economy/sims/mev/`. Needs combinatorial optimization (for knapsack) and continuous-time
 auction modeling. Python (PuLP/OR-Tools for optimization), Rust, or Julia.
 ## 4. Does / does-not
 - **Does:** simulate Priority Gas Auctions where multiple searcher bots compete for the same
  arbitrage opportunity $V$ by bidding gas fees $g$ in a continuous-time all-pay auction; model
  block building as a multidimensional knapsack problem (scarce block space, heterogeneous
  transaction values/sizes); simulate endogenous selection cutoffs under paid-priority ordering;
  predict MEV exposure for proposed trades; produce bounded predictions on extraction risk and
  optimal gas strategies.
 - **Does-not:** extract MEV itself (this is a simulator, not a searcher); model AMM mechanics
  (M3c handles pool math); model social dynamics (M3b).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** extraction probability ranges and gas cost intervals.
  Example: `{ value: 0.23, lower_bound: 0.11, upper_bound: 0.38, confidence: 0.80,
  time_horizon: "next_block", sim_type: "mev_adversarial" }` — probability this trade gets
  sandwiched.
  Example: `{ value: 14.7, lower_bound: 8.2, upper_bound: 22.5, confidence: 0.75,
  time_horizon: "next_block", sim_type: "mev_adversarial" }` — optimal gas bid (gwei) for
  a given opportunity.
 - **Prediction types:** `sandwich_probability`, `frontrun_risk`, `optimal_gas_bid`,
  `block_inclusion_probability`, `mev_exposure`.
 - Calibration: ingests `on_chain_event` (mempool-like data) and `price_tick` from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — on-chain events and gas data; *stub:* canned mempool snapshots.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 - M3c AMM sims — pool state for arbitrage opportunity detection; *stub:* fixed pool state.
 ## 7. Invariants / laws
 - **L1 (C4):** PGA is modeled as an **all-pay auction** — all bidders pay their gas whether they
  win or not. The sim must capture this cost structure (not winner-pays-only).
 - **L2 (C4):** block building is a **knapsack problem, not a queue** — builders optimize for
  total extracted value subject to gas limit constraints, not first-come-first-served.
 - **L3 (C3):** MEV exposure predictions are **pre-trade** — traders query this sim *before*
  submitting to the Marketplace to understand their extraction risk.
 ## 8. Build steps
 1. Implement the PGA all-pay auction model (N searchers, opportunity value V, gas bids).
 2. Implement the block-building knapsack solver.
 3. Add sandwich/frontrun detection heuristics.
 4. Wire M2 on-chain data → calibration of searcher population and gas dynamics.
 5. Wire pre-trade query interface for Traders.
 ## 9. Tests
 All-pay: losing bidders still pay gas cost. Knapsack: builder selects optimal transaction set
 under gas limit. Sandwich: known sandwich-vulnerable trade flagged; non-vulnerable trade clear.
 Bounds: all outputs bounded. Pre-trade: query does not submit any transaction.
 ## 10. Open items
 - Mempool data access (public mempool? private order flow?).
 - Which MEV types to model initially (sandwich, backrun, liquidation, JIT?).
 - Multi-block MEV (cross-block extraction strategies).
 - Integration with M3c (arbitrage opportunities arise from AMM pool state).
@@ -0,0 +1,72 @@
 # M3e — Tokenomics & macro-state sims
 ## 1. Component
 Macro-level token economy simulation: models **token supply dynamics, monetary policy (halvings,
 burns, inflation), and systemic stock-flow balances** using stochastic differential equations
 (SDEs) and state-space models. Pops here are **aggregate behavioral cohorts** (miners/validators,
 holders, speculators, protocol treasuries) whose collective behavior drives token-level dynamics.
 Grounded in the Vienna University complex-systems token modeling [7] and ResearchGate engineering
 token economy frameworks [6].
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. SDE state-space framework C4 (Vienna [7]); stock-flow modeling C4
 (ResearchGate [6]); specific token model parameters C1.
 ## 3. Language & location
 TBD · `src/economy/sims/tokenomics/`. Needs SDE solvers (Euler-Maruyama, Milstein) and
 state-space estimation. Julia (DifferentialEquations.jl), Python (scipy), or Octave.
 ## 4. Does / does-not
 - **Does:** simulate token state dynamics via the SDE framework:
  $dX_t = f(X_t, u(X_t, t), t)dt + \sigma(X_t, t)dW_t$ where $X_t$ is the system state vector,
  $u$ is the behavioral policy function, deterministic drift captures programmatic parameters
  (halvings, burns), and Brownian motion $\sigma dW_t$ captures stochastic behavioral shocks;
  model stock-flow balances (circulating supply, staked, locked, burned); simulate monetary
  policy impacts (halving events, fee burns, treasury emissions); produce bounded predictions
  on token supply trajectories, inflation rates, and velocity.
 - **Does-not:** model individual transactions (M3c/M3d); model social sentiment (M3b);
  model consensus mechanics (M3f).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** SDE confidence bands (derived from the stochastic component $\sigma dW_t$).
  Example: `{ value: 2.1, lower_bound: 1.4, upper_bound: 3.2, confidence: 0.90,
  time_horizon: "90d", sim_type: "tokenomics_macro" }` — annualized inflation rate (%).
  Example: `{ value: 0.67, lower_bound: 0.58, upper_bound: 0.74, confidence: 0.85,
  time_horizon: "30d", sim_type: "tokenomics_macro" }` — staking ratio (fraction of supply).
 - **Prediction types:** `supply_trajectory`, `inflation_rate`, `staking_ratio`,
  `velocity_estimate`, `halving_impact`, `treasury_runway`.
 - Calibration: ingests `on_chain_event` (supply metrics, staking data) from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — on-chain supply/staking data; *stub:* canned supply snapshots.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C4):** the SDE framework is the **canonical representation** — all token dynamics are
  expressed as drift + diffusion. Deterministic policy (halvings, burns) lives in the drift $f$;
  behavioral uncertainty lives in the diffusion $\sigma dW_t$.
 - **L2 (C4):** **stock-flow conservation** — tokens are never created or destroyed outside the
  protocol's defined mechanisms. The sim must balance: circulating + staked + locked + burned =
  total ever minted.
 - **L3 (C3):** macro sims operate on **aggregate cohorts, not individuals** — the state vector
  $X_t$ tracks population-level quantities (total staked, total circulating), not per-wallet.
 ## 8. Build steps
 1. Implement Euler-Maruyama SDE solver for a simple token model (supply + staking).
 2. Define the state vector $X_t$ and drift/diffusion functions for a reference token.
 3. Add stock-flow accounting (verify conservation).
 4. Wire M2 on-chain data → state estimation / calibration.
 5. Add monetary policy events (halving, burn) as drift discontinuities.
 ## 9. Tests
 SDE: sample paths have correct mean (matches drift) and variance (matches diffusion). Stock-flow:
 conservation holds across all time steps. Halving: supply growth rate drops at halving event.
 Calibration: state estimate converges to observed data. Bounds: SDE confidence bands correctly
 cover realized paths on backtest.
 ## 10. Open items
 - Which tokens to model initially (ETH? BTC? a specific alt?).
 - State vector dimensionality (how many state variables per token model?).
 - Behavioral policy function $u(X_t, t)$ — how to parameterize aggregate cohort behavior.
 - Multi-token interactions (correlated diffusions across tokens?).
@@ -0,0 +1,72 @@
 # M3f — Consensus & staking game sims
 ## 1. Component
 Consensus-layer simulation: models **Proof-of-Stake validation dynamics, staking pool game theory,
 and Byzantine fault tolerance** using evolutionary games and Markov chains. Pops here are
 **validators and staking pool operators** whose honesty is a dynamic, evolving strategy under
 financial incentives. Grounded in Cornell evolutionary consensus [8,9], ACM staking pool risk
 theorems [10], and Monash dynamic PBFT modeling [11].
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Evolutionary PoS game theory C4 (Cornell [8]); staking pool Nash
 equilibrium proofs C4 (ACM [10]); Markov chain throughput models C4 (Monash [11]);
 simulation parameterization C1.
 ## 3. Language & location
 TBD · `src/economy/sims/consensus/`. Needs Markov chain solvers and game-theoretic equilibrium
 computation. Python, Julia, or R.
 ## 4. Does / does-not
 - **Does:** simulate validator populations where honesty evolves via **evolutionary game theory**
  under bounded rationality [8]; model staking pool delegation as a game with proven reward-
  parameter thresholds enforcing subgame-perfect Nash equilibria favoring honest validation over
  malicious slashing [10]; simulate **throughput stability under shifting validator states** via
  Markov chains [11]; predict slashing risk, validator set stability, and staking yield; produce
  bounded predictions on consensus health and staking returns.
 - **Does-not:** validate blocks (this is a simulator); model AMM pools (M3c); model token supply
  (M3e — but consumes staking ratio from M3e as input).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** equilibrium stability ranges and yield intervals.
  Example: `{ value: 0.89, lower_bound: 0.82, upper_bound: 0.94, confidence: 0.88,
  time_horizon: "7d", sim_type: "consensus_staking" }` — fraction of validators honest in
  equilibrium.
  Example: `{ value: 4.2, lower_bound: 3.6, upper_bound: 5.1, confidence: 0.82,
  time_horizon: "30d", sim_type: "consensus_staking" }` — annualized staking yield (%).
 - **Prediction types:** `validator_honesty_fraction`, `slashing_probability`, `staking_yield`,
  `pool_delegation_equilibrium`, `throughput_stability`, `consensus_liveness`.
 - Calibration: ingests `on_chain_event` (validator set changes, slashing events) from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — validator/staking on-chain data; *stub:* canned validator snapshots.
 - M3e Tokenomics — staking ratio as macro input; *stub:* fixed ratio.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C4):** validator honesty is a **dynamic equilibrium, not a fixed parameter** — it evolves
  via replicator dynamics as payoffs change. The sim must not assume fixed honesty rates.
 - **L2 (C4):** the staking pool reward threshold is **mathematically derived** — the sim must
  reproduce the subgame-perfect Nash equilibrium from the ACM proofs [10], not use ad-hoc
  thresholds.
 - **L3 (C4):** throughput is modeled as a **Markov chain** over validator states (active, pending,
  slashed, exited) — transitions are stochastic with rates calibrated from on-chain data [11].
 ## 8. Build steps
 1. Implement the evolutionary honesty game (replicator dynamics, bounded rationality).
 2. Implement the Markov chain validator-state model.
 3. Reproduce the staking pool Nash equilibrium reward threshold from [10].
 4. Wire M2 validator data → calibration of transition rates.
 5. Wire M3e staking ratio input.
 ## 9. Tests
 Equilibrium: honesty fraction converges to Nash equilibrium under stable payoffs. Markov:
 stationary distribution matches expected validator state proportions. Threshold: pool delegation
 equilibrium matches the ACM proof for test parameters. Bounds: all outputs bounded. Liveness:
 throughput degrades when honest fraction drops below threshold.
 ## 10. Open items
 - Which PoS protocol to model initially (Ethereum? a specific L2?).
 - Bounded rationality implementation (noisy best-response? epsilon-greedy? logit?).
 - Slashing severity parameterization.
 - Cross-sim: does consensus instability feed into M3b sociological panic signals?
@@ -0,0 +1,70 @@
 # M3g — Market microstructure sims
 ## 1. Component
 Market microstructure simulation: models **order flow, liquidity depth, slippage, spread dynamics,
 and cross-exchange arbitrage** at the fastest time scales (tick-level to hourly). Pops here are
 **market makers, takers, and arbitrageurs** interacting across multiple venues. The sim that
 operates at the highest temporal resolution — where M3a provides statistical forecasts and M3c
 models pool mechanics, M3g models the *plumbing* of how orders actually execute.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Order-book microstructure theory C4 (established academic field);
 DEX-specific microstructure C2 (emerging). Implementation C1.
 ## 3. Language & location
 TBD · `src/economy/sims/microstructure/`. Needs high-frequency data handling and event-driven
 simulation. Rust, C++, or Python with optimized event loop.
 ## 4. Does / does-not
 - **Does:** simulate order flow across venues (DEXs and CEXs); model bid-ask spread dynamics as a
  function of inventory risk and adverse selection; simulate slippage curves for various order
  sizes; model cross-exchange arbitrage opportunities and their decay; operate at **tick-level
  resolution** (sub-second to minute); produce bounded predictions on execution quality, optimal
  routing, and liquidity conditions.
 - **Does-not:** model protocol consensus (M3f); model macro token supply (M3e); model social
  behavior (M3b); execute trades (Marketplace does).
 ## 5. Interface contract
 - Implements `query(PredictionQuery) -> BoundedPrediction` per M3 hub.
 - **Output bounds:** execution cost ranges and liquidity intervals.
  Example: `{ value: 0.0034, lower_bound: 0.0018, upper_bound: 0.0052, confidence: 0.85,
  time_horizon: "next_trade", sim_type: "market_microstructure" }` — expected slippage (%) for a
  10 ETH market sell.
  Example: `{ value: 12400, lower_bound: 8200, upper_bound: 18600, confidence: 0.78,
  time_horizon: "1h", sim_type: "market_microstructure" }` — available depth (USD) within 50bps
  of mid.
 - **Prediction types:** `slippage_estimate`, `spread_forecast`, `depth_profile`,
  `cross_venue_arb`, `optimal_execution_route`, `liquidity_score`.
 - Calibration: ingests `price_tick`, `dex_pool_state`, and `execution_fill` from M2.
 ## 6. Dependencies & stubs
 - M2 Data Feeds — tick data and pool state; *stub:* canned order book snapshots.
 - M3c AMM sims — pool mechanics for DEX venues; *stub:* fixed pool state.
 - M3 Sims hub — lifecycle management; *stub:* manual init.
 ## 7. Invariants / laws
 - **L1 (C4):** microstructure operates at the **highest temporal resolution** — predictions are
  valid for seconds to hours, not days. Stale microstructure data is worse than no data.
 - **L2 (C4):** slippage is a **function of order size and current depth** — not a fixed
  percentage. The sim must model the non-linear relationship.
 - **L3 (C3):** cross-venue arbitrage opportunities **decay** — the sim models the time-to-close
  of an arb opportunity, not just its existence.
 ## 8. Build steps
 1. Implement a simplified order-book simulator (limit orders, market orders, cancels).
 2. Add spread dynamics (inventory-based market maker model).
 3. Add slippage curves (order size → execution cost).
 4. Add cross-venue arb detection and decay modeling.
 5. Wire M2 tick data → calibration.
 ## 9. Tests
 Slippage: larger orders produce greater slippage. Spread: spread widens under adverse selection.
 Arb decay: detected arb opportunity closes over time. Depth: depth profile matches order book
 state. Bounds: all outputs bounded. Resolution: predictions update at tick frequency.
 ## 10. Open items
 - CEX order book data access (API limitations, costs).
 - DEX-specific microstructure (AMM pools don't have order books — translate pool state to
  equivalent depth/spread).
 - Latency modeling (how fast can our traders actually reach an arb?).
 - Which venues to model initially.
@@ -1,66 +0,0 @@
 # M4 — Budget governor
 ## 1. Component
 The stomach's CFO: **sets, allocates, and enforces** resource budgets. Decides whether a proposed
 expenditure (digestion, retrieval, exchange) is affordable given what's already been spent (M3)
 and what's been allocated. Emits **price signals** to A2 (energy driver) so the per-tool economy
 reflects real resource scarcity.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. A2 has a per-tool cost/lockout system but it tracks internal energy, not
 external resource budgets. The two are complementary: A2 = activation/rest; M4 = tokens/compute
 spend. Role C2; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/budget/` or similar. Must interop with M3 (ledger reads) and A2 (price signal
 emission). Likely same language as M3 for tight integration.
 ## 4. Does / does-not
 - **Does:** hold a session budget (total resources available); check proposed costs against
  remaining budget (`check_budget`); emit price signals to A2 so tool costs reflect real scarcity;
  implement **degradation tiers** — when budget is ample, digest fully; when tight, digest
  shallowly or defer bulk input (M1 priority system).
 - **Does-not:** record costs (M3 does); perform digestion (M2 does); lock tools (A2 does that
  based on energy, though M4's price signals influence A2's cost landscape); police traffic (D1).
 ## 5. Interface contract
 - `init_budget(session_budget: num, resource_type: ResourceType) -> BudgetState`.
 - `check_budget(proposed_cost: num, resource_type: ResourceType) -> { allowed:bool, remaining:num, tier:DegradationTier }`.
  `DegradationTier` ∈ { `full`, `shallow`, `deferred` } — signals to M2 how deeply to digest.
 - `price_signal(tool_id) -> { resource_cost:num, scarcity_factor:num }` — emitted to A2; the
  scarcity factor scales with budget depletion (1.0 = ample, >1.0 = scarce, costs feel heavier).
 - `remaining() -> { budget:num, spent:num, pct_remaining:num }` — reads M3 totals.
 ## 6. Dependencies & stubs
 - M3 cost ledger — reads totals for remaining budget calculation; *stub:* returns zero spent.
 - A2 energy driver — consumes price signals; *stub:* print signals.
 - M1 ingestion — M1 checks budget before forwarding to M2; *stub:* always-allow.
 - M2 digestion core — receives `DegradationTier` to adjust digestion depth.
 ## 7. Invariants / laws
 - **L1 (C4):** budget enforcement is a **soft gate, not a hard wall** — when budget is exhausted,
  digestion degrades (shallower summaries, deferred bulk) rather than halting. The organ never
  stops entirely; it economizes harder. Mirrors A2-L2 (no unrecoverable state) and A2-L3
  (lockout is a breaker, not a sentence).
 - **L2 (C3):** price signals are **monotonically scarcer** as budget depletes — the scarcity
  factor never decreases within a session (costs only feel heavier as resources dwindle). Resets
  only on budget replenishment.
 - **L3 (C3):** degradation tiers are **transparent** — the tier is carried in the contract so
  downstream (M2, M5) knows the digestion was shallow and can annotate accordingly.
 ## 8. Build steps
 1. Define `BudgetState` and the degradation tiers.
 2. Implement `check_budget` against M3 totals.
 3. Implement `price_signal` emission to A2 (define the scarcity factor curve — invariants-first).
 4. Wire M1 → M4 → M2 (budget check before digestion, tier passed to digestion).
 ## 9. Tests
 Budget arithmetic: spent + remaining = total. Degradation tiers: each tier triggers at the correct
 budget percentage. Price signals: scarcity factor increases as budget depletes. Soft gate: zero
 budget produces `deferred` tier, not an error.
 ## 10. Open items
 - Session budget source — who sets it? Hardcoded? Config? Dynamically adjusted? (C1).
 - Degradation tier thresholds (C1) — at what % remaining does `full` → `shallow` → `deferred`?
 - The scarcity factor curve shape (C1) — linear? exponential? Needs invariants-first fitting.
 - Whether budget replenishment is possible mid-session (ties to A2 restoration model / A8 ETR).
@@ -0,0 +1,74 @@
 # M4 — Wallets (sovereign custody)
 ## 1. Component
 The economy organ's vault: **sovereign, local-hosted, our-custody-only cryptocurrency wallets**.
 Each wallet binds to exactly one Trader (M5) — a trader without a wallet cannot access the
 Marketplace (M1). Wallets hold keys, sign transactions, and enforce wallet-level spending limits.
 Tax is collected on trader income and routed to the Verschwörern Veregeister wallets (stub — M0).
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C4 (sovereign custody is a hard requirement); implementation C1.
 ## 3. Language & location
 TBD · `src/economy/wallets/`. Needs cryptographic key management (secp256k1 for EVM, ed25519 for
 Solana, etc.), HD derivation, and transaction signing. Rust or Go for crypto primitives; Python
 with web3 libs for prototyping.
 ## 4. Does / does-not
 - **Does:** generate and store private keys locally (never transmitted); sign transactions on
  behalf of the bound trader; enforce per-wallet spending limits (daily, per-transaction);
  track wallet balance and transaction history; collect tax on realized income and stage for
  transfer to Verschwörern Veregeister wallets; bind 1:1 to a Trader (M5).
 - **Does-not:** decide what to trade (Trader decides); route to chain (Marketplace does);
  hold keys for the organism's other wallets (Verschwörern Veregeister are separate); delegate
  custody to any third party — ever.
 ## 5. Interface contract
 - `create_wallet(chain: Chain, trader_id) -> wallet_id` — generates keys, binds to trader.
 - `sign(wallet_id, tx: UnsignedTransaction) -> SignedTransaction` — signs with the wallet's key.
  Only the bound trader (via Marketplace) can request signing.
 - `balance(wallet_id) -> { chain, assets: [{ token, amount }] }`.
 - `spending_check(wallet_id, amount) -> { allowed:bool, remaining_daily:num }`.
 - `tax_collect(wallet_id, income_amount) -> { tax_amount, receipt }` — computes and stages tax.
 - `transfer_tax_stub(source_wallet, dest_wallet, amount) -> receipt` — **STUB** for future
  Verschwörern Veregeister internal transfer. Logs only; does not execute.
 - `Chain` ∈ { `evm`, `solana`, `bitcoin`, … } — extensible.
 ## 6. Dependencies & stubs
 - M5 Traders — 1:1 binding; *stub:* canned trader ID.
 - M1 Marketplace — signing requests come through marketplace only; *stub:* direct sign call.
 - Blockchain nodes — balance queries and tx broadcast; *stub:* simulated chain state.
 - Verschwörern Veregeister wallets — tax destination; *stub:* log transfer.
 ## 7. Invariants / laws
 - **L1 (C5):** **sovereign custody only** — private keys are generated locally, stored locally,
  and **never leave the wallet**. No custodial service, no exchange deposit, no MPC with external
  parties. Our keys, our coins.
 - **L2 (C5):** **1:1 trader binding** — each wallet is bound to exactly one trader. A trader
  cannot use another trader's wallet. The Marketplace enforces this.
 - **L3 (C4):** **signing requires Marketplace routing** — a wallet will not sign a transaction
  that didn't come through the Marketplace harness (M1-L1). No direct signing API for traders.
 - **L4 (C4):** **spending limits are wallet-level** — independent of Conductor or Marketplace
  limits. Defense in depth: even if other controls fail, the wallet itself caps exposure.
 - **L5 (C4):** **tax collection is automatic** — realized income triggers tax staging. The trader
  cannot opt out.
 ## 8. Build steps
 1. Implement key generation and secure local storage (encrypted keystore).
 2. Implement transaction signing for one chain (start with EVM/secp256k1).
 3. Implement trader binding and Marketplace-only signing enforcement.
 4. Implement spending limits (daily cap, per-tx cap).
 5. Implement tax calculation and staging stub.
 ## 9. Tests
 Custody: private key never appears in any API response or log. Binding: wrong trader cannot
 sign. Marketplace-only: direct sign request (not via Marketplace) rejected. Spending limit:
 over-limit transaction rejected. Tax: income event triggers correct tax amount. Multi-chain:
 EVM and one other chain produce valid signatures.
 ## 10. Open items
 - Key storage format (encrypted JSON keystore? OS keyring? HSM for production?).
 - Which chains to support initially.
 - Spending limit configuration (hardcoded? per-trader? adjustable by Conductor?).
 - Tax rate and calculation method.
 - Key rotation / backup strategy.
@@ -1,73 +0,0 @@
 # M5 — Context yield (absorption)
 ## 1. Component
 The stomach's output shaper: takes `DigestedContext` from M2 and **packages it into the form Ada
 (D1) expects** — an Ichor `Envelope` with the right shape, provenance metadata (M6), and
 degradation annotations. This is the absorption step: what the organism actually absorbs from
 what was digested.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. The smoke test (`main.pony:29`) hard-codes a string payload
 `"digested context: <pre-chewed user turn>"`; no real output shaping exists. Role C3;
 implementation C1.
 ## 3. Language & location
 TBD · part of `src/economy/`. Likely Pony (produces `Envelope` directly for bus transport) or a
 thin adapter between M2's output and the Ichor envelope shape.
 ## 4. Does / does-not
 - **Does:** take `DigestedContext` (M2) + provenance chain (M6) + degradation tier (M4); package
  into an Ichor `Envelope` with `OrganSecretion` provenance; attach metadata: original provenance
  origin, digestion tier, summary length, extraction count; emit the envelope to the Ichor broker
  for delivery to Ada.
 - **Does-not:** digest (M2 does); decide whether Ada admits it (D1 does); transform the content
  further — it packages, it doesn't re-process.
 ## 5. Interface contract
 - `yield(context: DigestedContext, chain: ProvenanceChain, tier: DegradationTier) -> Envelope`.
 - The `Envelope` payload is structured (not a raw string):
  ```
  { summary: str,
    extractions: [{ key, value }],
    meta: { original_provenance: Provenance,
            digestion_tier: DegradationTier,
            source_ref: str,
            actual_cost: num } }
  ```
 - The envelope's bus-level `provenance` field is `OrganSecretion` (the stomach is an organ); the
  **original** input provenance is carried inside `meta.original_provenance` so Ada can inspect
  it (M6 compliance).
 - `dest` is always `AdaBorder`.
 ## 6. Dependencies & stubs
 - M2 `DigestedContext` — upstream; *stub:* canned digested context.
 - M6 `ProvenanceChain` — provenance metadata; *stub:* pass-through original provenance.
 - M4 `DegradationTier` — annotation; *stub:* always `full`.
 - Ichor `Envelope` (existing) — output shape.
 - Ichor `Broker` (existing) — delivery.
 ## 7. Invariants / laws
 - **L1 (C4):** every yielded envelope carries the **original provenance** in metadata — Ada can
  always determine what the digested content was *before* the stomach touched it (S1/S2 compliance
  via M6).
 - **L2 (C4):** the degradation tier is **visible** in the envelope — Ada and the Brain know whether
  they're getting a full digest or a shallow/deferred one. No silent quality degradation.
 - **L3 (C3):** yield is **stateless** — it packages what it receives; it holds no buffer, no queue,
  no memory of previous yields.
 ## 8. Build steps
 1. Define the structured payload shape (extend beyond raw string).
 2. Build the `yield` function (DigestedContext + ProvenanceChain + tier → Envelope).
 3. Wire M2 → M5 → Ichor Broker → Ada.
 4. Update the smoke test (`main.pony`) to use structured payloads instead of hard-coded strings.
 ## 9. Tests
 Shape: yielded envelope has all required metadata fields. Provenance: original provenance survives
 in `meta.original_provenance`. Tier annotation: each degradation tier correctly tagged. Stateless:
 two consecutive yields with different inputs produce independent envelopes.
 ## 10. Open items
 - The structured payload encoding (JSON? Pony-native? Ada-compatible binary?) — must be parseable
  by Ada's `Trust_Guard` on the other side of the seam.
 - Whether Ada needs to understand degradation tiers or just passes them through to the Brain.
 - Batch yields (multiple digested contexts in one envelope vs one-per-envelope).
@@ -0,0 +1,78 @@
 # M5 — Traders (AI actors)
 ## 1. Component
 The economy organ's hands: **specialized AI actors** that buy, sell, and mint cryptocurrency and
 NFTs. Each trader is bound to a Wallet (M4), operates through the Marketplace (M1), queries Sims
 (M3) for predictions, and has all tool calls monitored by the SAE (M7). Multiple traders may
 operate concurrently with **different specializations** (DeFi yield, NFT minting, arbitrage,
 long-term holding, etc.).
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C3; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/traders/`. Each trader is an AI actor — likely LLM-based (small models for
 speed) or hybrid (LLM for strategy + deterministic execution logic). The harness managing
 multiple traders may be Pony actors or a Python async framework.
 ## 4. Does / does-not
 - **Does:** query Sims (M3) for market predictions (bounded, multi-domain); consume Data Feeds
  (M2) for real-time market state; formulate trade decisions based on predictions + data +
  specialization; submit `MarketAction` requests to the Marketplace (M1) via bound wallet (M4);
  operate with **scoped autonomy** — trades within law/budget constraints don't need Brain or
  Conductor approval.
 - **Does-not:** execute on-chain directly (Marketplace does); hold keys (Wallet does); supervise
  other traders (Conductor does); modify the law script (immutable — M1-L2); bypass the
  Marketplace (M1-L1).
 ## 5. Interface contract
 - `init_trader(specialization, wallet_id, config) -> trader_id`.
  `specialization` ∈ { `defi_yield`, `nft_minter`, `arbitrageur`, `trend_follower`,
  `market_maker`, … } — extensible.
 - `decide(market_state, predictions: [BoundedPrediction]) -> MarketAction?` — the trader's core
  loop. May return no action (waiting is a valid decision).
 - `tool_call(tool_name, args) -> result` — every tool call is intercepted and logged to SAE (M7)
  before execution. Includes Marketplace submissions, Sim queries, and Data Feed reads.
 - `pause() / resume()` — Conductor (M6) can pause a trader pending investigation.
 - `status() -> { active | paused | investigating, wallet_id, specialization, position_summary }`.
 ## 6. Dependencies & stubs
 - M1 Marketplace — action submission; *stub:* mock marketplace that logs actions.
 - M2 Data Feeds — market data; *stub:* canned data.
 - M3 Sims — predictions; *stub:* fixed predictions.
 - M4 Wallet — bound 1:1; *stub:* mock wallet.
 - M6 Conductor — supervision; *stub:* no supervision.
 - M7 SAE — monitors all tool calls; *stub:* print calls.
 ## 7. Invariants / laws
 - **L1 (C5):** **all market actions go through the Marketplace** — a trader cannot interact with
  any chain or protocol except via `MarketAction` → Marketplace (M1). Enforced by architecture
  (no direct RPC access), not just policy.
 - **L2 (C5):** **all tool calls are monitored** — every tool invocation (Marketplace, Sims,
  Feeds, internal) is logged to SAE (M7). No unmonitored trader action.
 - **L3 (C4):** **wallet binding is irrevocable within a session** — a trader's wallet cannot be
  reassigned to another trader at runtime.
 - **L4 (C4):** **Conductor can pause** — a paused trader cannot submit actions, query sims, or
  read feeds until resumed by the Conductor (M6).
 - **L5 (C3):** trader specialization constrains strategy but not the interface — all traders use
  the same `MarketAction` vocabulary regardless of specialization.
 ## 8. Build steps
 1. Define the trader agent architecture (LLM-based? hybrid? rule-based for v1?).
 2. Implement the `decide` loop (observe market state + predictions → action).
 3. Wire tool-call interception → M7 SAE.
 4. Wire Marketplace submission → M1.
 5. Implement pause/resume for Conductor control.
 6. Build at least two specializations to test multi-trader dynamics.
 ## 9. Tests
 Marketplace-only: trader cannot call chain RPC directly. Monitoring: every tool call appears in
 SAE log. Wallet binding: trader uses only its bound wallet. Pause: paused trader cannot submit
 actions. Specialization: different specializations produce different action patterns on identical
 market state.
 ## 10. Open items
 - Trader agent architecture (which LLM? how much deterministic logic vs. model inference?).
 - Number of concurrent traders and resource allocation per trader.
 - Specialization catalog (which types, and how do they differ in strategy?).
 - Inter-trader coordination (do traders see each other's positions? shared state? isolated?).
@@ -0,0 +1,79 @@
 # M6 — Conductor (supervisory AI)
 ## 1. Component
 The economy organ's supervisor: a **specialist-trained AI** with authority to **veto Marketplace
 actions and pause/investigate individual Traders**. Receives suspicious-behavior reports from the
 SAE (M7) and acts on them. The Conductor is the stomach's own judgment — it does not consult the
 organism's Brain for trade-level decisions. It supervises; the deterministic law script (M1)
 constrains; together they form the multi-layered braking system.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. Role C4 (supervision architecture is clear); implementation C1 (model
 selection, training, authority scope).
 ## 3. Language & location
 TBD · `src/economy/conductor/`. The Conductor is an AI actor — likely a fine-tuned LLM with
 specialist training in market risk, trader behavior analysis, and anomaly response. The
 inference wrapper sits alongside the Marketplace.
 ## 4. Does / does-not
 - **Does:** receive SAE (M7) anomaly reports on trader behavior; **pause** a flagged trader's
  actions to investigate; **veto** a Marketplace action if investigation reveals risk; **resume**
  a cleared trader; review Marketplace actions pre-execution when the law check passes (M1-L4:
  veto is checked after law, before execution); maintain an audit log of all veto/pause/resume
  decisions.
 - **Does-not:** trade (Traders do); execute on-chain (Marketplace does); modify the law script
  (immutable — M1-L2); detect anomalies directly (SAE does — the Conductor *responds* to SAE
  reports, it doesn't watch raw data); consult the organism's Brain.
 ## 5. Interface contract
 - `veto_check(action: MarketAction, trader_id) -> { approved | vetoed(reason) }` — called by
  Marketplace (M1) for every law-passing action before execution.
 - `receive_alert(alert: SAEAlert) -> { pause(trader_id) | dismiss | escalate }`.
  `SAEAlert { trader_id, alert_type, evidence, severity, timestamp }`.
 - `investigate(trader_id) -> { clear(resume) | veto_pending_actions | restrict(new_limits) }`.
 - `decision_log() -> [ConductorDecision]` — full audit trail of all veto/pause/resume/dismiss.
 - **SAE/Brain message format compatibility:** the Conductor's incoming alert format is
  **identical in structure and signature** to Brain messages — SAE reports to the Conductor in
  the same shape it would report to the Brain. This means the Conductor can be swapped for Brain
  oversight without protocol changes (though the stomach normally operates autonomously).
 ## 6. Dependencies & stubs
 - M7 SAE — anomaly reports; *stub:* no alerts (all clear).
 - M1 Marketplace — veto check integration; *stub:* always-approve.
 - M5 Traders — pause/resume control; *stub:* print pause/resume.
 ## 7. Invariants / laws
 - **L1 (C5):** the Conductor **can veto, but cannot trade** — it has no wallet, no Marketplace
  access as a trader. It supervises from outside the trading loop.
 - **L2 (C5):** the **law script is above the Conductor** — the Conductor vetoes actions that
  *pass* the law check but seem strategically risky. It cannot override a law violation (those
  are rejected before reaching the Conductor — M1-L4).
 - **L3 (C4):** **pause is reversible** — a paused trader can always be resumed after
  investigation. Pause is a breaker, not a sentence (echoes A2-L3).
 - **L4 (C4):** every Conductor decision is **logged** — vetoes, pauses, resumes, dismissals.
  The audit log is append-only (echoes M1-L2 / S3).
 - **L5 (C4):** SAE alert format and Brain message format are **structurally identical** — same
  fields, same signatures. The Conductor processes them the same way the Brain would.
 ## 8. Build steps
 1. Define the Conductor's decision model (rule-based for v1? fine-tuned LLM for v2?).
 2. Wire SAE alert intake (M7 → M6).
 3. Wire Marketplace veto check (M1 → M6 → approve/veto).
 4. Implement trader pause/investigate/resume flow.
 5. Implement append-only decision log.
 ## 9. Tests
 Veto: flagged action is vetoed; unflagged action approved. Pause: paused trader cannot submit
 actions. Resume: cleared trader resumes normal operation. No trading: Conductor cannot submit
 `MarketAction`. Law supremacy: Conductor cannot override a law violation (never reaches
 Conductor). Audit: every decision appears in the log. Alert format: SAE alert parses identically
 to Brain message structure.
 ## 10. Open items
 - Conductor AI model selection and training data (what does "specialist training" look like?).
 - Veto criteria beyond SAE alerts (does the Conductor have independent judgment, or only
  responds to SAE reports?).
 - Escalation path — if the Conductor is uncertain, does it escalate to the organism's Brain?
  Or is the stomach fully autonomous? (Current design: fully autonomous.)
 - Multiple Conductors for redundancy?
@@ -1,79 +0,0 @@
 # M6 — Provenance chain
 ## 1. Component
 The chain of custody through the stomach: tracks **where input came from** and **what the stomach
 did to it**, so that digested content is never mistaken for original content and Ada (D1) can
 enforce S1/S2 with full information. Solves the provenance question from the economy organ review:
 the stomach transforms external input into organ-secretion output, but the *origin* must not be
 lost.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. The current smoke test sets `OrganSecretion` provenance on stomach output
 (`main.pony:29`) with no record of the original input's provenance. This is the gap that risks
 S1/S2 violation. Role C4 (the need is clear); implementation C1.
 ## 3. Language & location
 TBD · part of `src/economy/`. Likely a data structure carried alongside digested context, not a
 separate service. Must be representable in both Pony (bus side) and Ada (border side).
 ## 4. Does / does-not
 - **Does:** create a `ProvenanceChain` for each input entering the stomach; record each
  transformation step (ingestion, classification, digestion, yield); attach the chain to the
  yielded envelope (M5) so Ada sees the full history; enable Ada to distinguish "organ-processed
  external input" from "organ-generated internal content".
 - **Does-not:** decide trust (Ada does); authenticate sources (the bus provenance system does);
  filter or reject based on provenance (M0-L2 — digestion doesn't suppress).
 ## 5. Interface contract
 - `chain_start(original_provenance: Provenance, source: OrganId, input_hash: str) -> ProvenanceChain`.
 - `chain_step(chain: ProvenanceChain, step: TransformStep) -> ProvenanceChain`.
  `TransformStep { stage, transformer, timestamp }`.
  `stage` ∈ { `ingested`, `classified`, `digested`, `yielded` }.
 - The final `ProvenanceChain` is:
  ```
  { original_provenance: Provenance,   -- what the input was before the stomach
    original_source: OrganId,           -- who sent it (World, MoRAG, etc.)
    input_hash: str,                    -- hash of raw input for audit
    steps: [TransformStep],             -- what the stomach did, in order
    is_external_origin: bool }          -- convenience flag for Ada: TRUE if
                                        --   original_provenance ∈ {External, UserInput}
  ```
 - `is_external_origin` lets Ada apply S1 screening to digested-but-originally-external content
  without parsing the full chain.
 ## 6. Dependencies & stubs
 - Ichor `Provenance` / `OrganId` (existing) — input types.
 - M1 ingestion — creates the chain at `ingested` step.
 - M2 digestion — adds the `digested` step.
 - M5 context yield — attaches the chain to the envelope; *stub:* pass-through.
 - Ada D1 `Trust_Guard` — consumer of the chain; *stub:* print chain on receipt.
 ## 7. Invariants / laws
 - **L1 (C5):** the chain is **immutable once created** — steps are appended, never modified or
  removed. Like the COBOL invariant vault (S3), the provenance record doesn't get rewritten.
 - **L2 (C5):** **S2 compliance** — the original provenance is **never reclassified**. The bus
  transport field may say `OrganSecretion` (because the stomach is an organ emitting output), but
  `original_provenance` in the chain preserves the true origin. This is not reclassification;
  it's layered provenance.
 - **L3 (C4):** **S1 compliance** — content with `is_external_origin = TRUE` tells Ada that this
  traffic **originated externally** even though it arrives as organ output. Ada applies its full
  external-traffic screening (rate, blocklist, trust) to such content.
 - **L4 (C3):** the `input_hash` allows **audit verification** — given the original input and the
  hash, you can confirm the chain refers to the right content.
 ## 8. Build steps
 1. Define `ProvenanceChain` and `TransformStep` shapes.
 2. Wire chain creation in M1 (ingestion) and step-append in M2 (digestion).
 3. Wire chain attachment in M5 (yield → envelope metadata).
 4. Extend Ada's `Trust_Guard` (or its stub) to read `is_external_origin` and apply S1 screening.
 ## 9. Tests
 Chain integrity: steps accumulate in order; no mutation. S2: original provenance survives all
 transforms. S1: `is_external_origin = TRUE` for external/user input; `FALSE` for organ-to-organ.
 Hash: chain's `input_hash` matches hash of the raw input.
 ## 10. Open items
 - Hash algorithm (SHA-256? lightweight alternative for performance?).
 - Whether Ada needs the full chain or just `is_external_origin` + `original_provenance` (start
  with the full chain; Ada can ignore what it doesn't need).
 - Cross-seam representation (Pony chain → C/Fortran seam → Ada record).
@@ -1,76 +0,0 @@
 # M7 — Outer-bus exchange
 ## 1. Component
 The stomach's economic relationships with its **outer-bus peers**: MoRAG (F1), SAE (F2),
 microagents (F3). How the economy organ requests, receives, and pays for services from other
 outer organs — and what it provides in return. The smoke test already shows
 `Stomach → MoRAG` (`main.pony:37`); this spec defines the full exchange protocol.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. One hard-coded `Stomach → MoRAG` message exists in the smoke test.
 No protocol, no cost tracking, no bidirectional exchange defined. Role C2; implementation C1.
 ## 3. Language & location
 TBD · part of `src/economy/`. Exchange happens over Ichor (Pony actors + Envelope), so the
 protocol is Envelope-based. The exchange logic lives in the economy organ; peers implement
 their side independently.
 ## 4. Does / does-not
 - **Does:** request world context from MoRAG before/during digestion (enrich the digest with
  retrieved knowledge); receive SAE monitoring signals (if SAE detects anomalies in the stomach's
  outputs); coordinate with microagents for delegated sub-tasks (e.g. "fetch and pre-chew this
  URL"); track the cost of all exchanges in M3.
 - **Does-not:** route traffic (Ichor broker does); bypass Ada for any membrane-bound content
  (outer-to-outer is fine; anything heading inward crosses D1); command peers (it requests; they
  may decline).
 ## 5. Interface contract
 - **Stomach → MoRAG:**
  `request_context(query: str, budget_limit: num) -> Envelope` — ask MoRAG for relevant world
  context to enrich a digestion. `budget_limit` caps how much the retrieval may cost (MoRAG
  reports actual cost back; M3 records it).
 - **Stomach → Microagents:**
  `delegate(task: str, budget_limit: num) -> Envelope` — delegate a sub-task (fetch, pre-process)
  to a microagent. Same budget/cost protocol.
 - **SAE → Stomach:**
  `anomaly_signal(finding: str) -> Envelope` — SAE pushes a signal if it detects anomalous
  stomach output. The stomach logs it (M3) but does not self-correct (F2-L2: detection only,
  no closed elimination loop).
 - All exchange envelopes use `OrganSecretion` provenance (outer-to-outer, no membrane crossing).
 ## 6. Dependencies & stubs
 - Ichor `Broker` + `Envelope` (existing) — transport.
 - MoRAG (F1) — context provider; *stub:* fixed context response.
 - SAE (F2) — anomaly detector; *stub:* no signals.
 - Microagents (F3) — task delegates; *stub:* echo task back.
 - M3 cost ledger — records exchange costs.
 - M4 budget governor — caps exchange spending via `budget_limit`.
 ## 7. Invariants / laws
 - **L1 (C5):** outer-to-outer exchange **never crosses Ada** — it stays on Ichor. Only the final
  digested output (M5) crosses the membrane. This is by design: peer coordination is "skin-level"
  and doesn't need border screening.
 - **L2 (C4):** every exchange has a **budget limit** — no unbounded retrieval or delegation. The
  stomach asks for what it can afford (M4).
 - **L3 (C3):** exchanges are **request/response, not streaming** — the stomach sends a request,
  waits for a response (or timeout), and proceeds. No long-lived channels between peers.
 - **L4 (C3):** the stomach **never self-corrects** based on SAE signals — it logs them. Correction
  is a G1/G2 governance concern, not the organ's.
 ## 8. Build steps
 1. Define the exchange envelope subtypes (request_context, delegate, anomaly_signal).
 2. Implement Stomach → MoRAG context request (extend the existing `main.pony` wire).
 3. Implement budget-limited exchange (M4 check before request; M3 record on response).
 4. Implement SAE → Stomach anomaly logging.
 ## 9. Tests
 MoRAG exchange: request sent, response received, cost recorded. Budget limit: exchange rejected
 when over budget. Anomaly signal: logged but no state change in the stomach. Outer-only: no
 exchange envelope targets `AdaBorder`.
 ## 10. Open items
 - Whether MoRAG enrichment happens **before** digestion (pre-chew with context) or **during**
  (RAG-augmented digestion — the small model sees retrieved context alongside input). Big design
  fork (C2).
 - Timeout/fallback when a peer doesn't respond (digest without enrichment? retry?).
 - Microagent delegation scope — what tasks can be delegated vs what the stomach must do itself.
@@ -0,0 +1,83 @@
 # M7 — SAE monitor (trader surveillance)
 ## 1. Component
 The economy organ's internal watchdog: a **sparse autoencoder pointed at every trader tool call**.
 Monitors all Trader (M5) actions — Marketplace submissions, Sim queries, Data Feed reads, and
 any other tool invocation — and reports **suspicious behavior** to the Conductor (M6). Messages
 from the SAE share **identical format and signatures** with Brain messages, so the Conductor
 processes them through the same pathway.
 Extends the F2 (SAE monitor) pattern to the economy organ's internal domain. F2 watches
 subagents at the organism level; M7 watches traders at the stomach level.
 ## 2. Status / certainty
 DESIGN-FIRST · ABSENT. F2 SAE monitor provides the architectural pattern (watch the machinery,
 never the homunculus — F2-L1). M7 adapts this: watch the **traders** (the machinery), never the
 **Conductor** (the stomach's judgment). Role C3; implementation C1.
 ## 3. Language & location
 TBD · `src/economy/sae/`. ML interpretability (sparse autoencoder over trader action embeddings).
 Shares the architectural pattern with F2 but is a separate instance scoped to the economy organ.
 ## 4. Does / does-not
 - **Does:** intercept and log **every trader tool call** (Marketplace, Sims, Feeds, internal);
  embed trader action sequences; run SAE anomaly detection over action embeddings; flag suspicious
  patterns (unusual trading frequency, outsized positions, coordinated behavior across traders,
  repeated failed actions, unusual Sim query patterns); report alerts to the Conductor (M6) with
  evidence; format alerts **identically to Brain messages** (same structure, same signatures).
 - **Does-not:** block actions directly (Conductor decides); watch the Conductor (the stomach's
  "homunculus" — echoes F2-L1); correct trader behavior (detection only — F2-L2: no closed
  elimination loop); trade or access wallets.
 ## 5. Interface contract
 - `log_tool_call(trader_id, tool_name, args, result, timestamp)` — called on every trader tool
  invocation. Synchronous interception (the call is logged before execution proceeds).
 - `alert(trader_id, alert_type, evidence, severity) -> SAEAlert`.
  `alert_type` ∈ { `unusual_frequency`, `outsized_position`, `coordinated_behavior`,
  `repeated_failures`, `anomalous_queries`, `pattern_deviation` }.
  `severity` ∈ { `low`, `medium`, `high`, `critical` }.
 - `SAEAlert` structure is **identical to Brain message structure** — same fields, same
  signature scheme. The Conductor (M6) processes SAE alerts and Brain messages through the
  same intake (M6-L5).
 - `status() -> { active, traders_monitored, alerts_pending, model_freshness }`.
 ## 6. Dependencies & stubs
 - M5 Traders — tool call source; *stub:* canned tool call log.
 - M6 Conductor — alert consumer; *stub:* print alerts.
 - F2 SAE monitor (organism-level) — architectural pattern; no runtime dependency.
 ## 7. Invariants / laws
 - **L1 (C5):** the SAE watches **traders, never the Conductor** — the Conductor is the
  stomach's judgment; the SAE monitors the machinery. Echoes F2-L1 (watch the machinery, never
  the homunculus).
 - **L2 (C5):** **every tool call is logged** — no trader action escapes monitoring. This is
  enforced architecturally (tool call interception), not by policy.
 - **L3 (C4):** **detection only, no enforcement** — the SAE reports to the Conductor; it never
  blocks, pauses, or modifies trader actions itself. Echoes F2-L2 (no closed elimination loop).
 - **L4 (C4):** **alert format = Brain message format** — structurally identical, same signatures.
  This is not coincidental; it ensures the Conductor can be supervised by the Brain using the
  same protocol if the organism ever needs to override stomach autonomy.
 - **L5 (C3):** the SAE model is **trained on normal trader behavior** — anomalies are deviations
  from the learned normal, not violations of predefined rules (those are the law script's job
  in M1).
 ## 8. Build steps
 1. Implement tool-call interception in the trader harness (M5).
 2. Define the action embedding scheme (how tool calls are vectorized).
 3. Train the SAE on normal trader behavior (bootstrapped from simulated trading).
 4. Implement anomaly scoring and alert threshold.
 5. Wire alerts to Conductor (M6) in Brain-compatible message format.
 ## 9. Tests
 Interception: every tool call produces a log entry. Anomaly: known-suspicious patterns (e.g.
 100x normal frequency) trigger alert. Normal: baseline behavior does not trigger alert.
 No enforcement: SAE cannot pause or block a trader (only Conductor can). Alert format: SAE
 alert parses as valid Brain message. Conductor-blind: no Conductor action appears in SAE logs.
 ## 10. Open items
 - SAE architecture (how many features? reconstruction vs. classification?).
 - Training data bootstrapping (simulated trading or historical data?).
 - Alert threshold tuning (too sensitive = alert fatigue; too lax = missed anomalies).
 - Whether M7 should also monitor Marketplace execution outcomes (fills, slippage) in addition
  to tool calls.
 - Relationship to F2: shared model? shared training pipeline? or fully independent?
@@ -50,13 +50,20 @@ Every `NN-<organ>.md` has the same 10 sections:
 | G2 | Governance | Cross-cut | DESIGN-FIRST (C2) | TBD | _wave 2_ |
 | G3 | Defense model | Cross-cut | emergent | — | _wave 2_ |
 | M0 | Economy organ hub (stomach) | Economy | DESIGN-FIRST | TBD | [M0](M0-economy-organ-hub.md) |
-| M1 | Ingestion gateway | Economy | DESIGN-FIRST | TBD | [M1](M1-ingestion.md) |
+| M1 | Marketplace (multi-trader harness) | Economy | DESIGN-FIRST | TBD | [M1](M1-marketplace.md) |
-| M2 | Digestion core (small-model) | Economy | DESIGN-FIRST | TBD | [M2](M2-digestion-core.md) |
+| M2 | Data feeds (market data pipeline) | Economy | DESIGN-FIRST | TBD | [M2](M2-data-feeds.md) |
-| M3 | Cost ledger | Economy | DESIGN-FIRST | TBD | [M3](M3-cost-ledger.md) |
+| M3 | Sims hub (market prediction) | Economy | DESIGN-FIRST | TBD | [M3](M3-sims-hub.md) |
-| M4 | Budget governor | Economy | DESIGN-FIRST | TBD | [M4](M4-budget-governor.md) |
+| M3a | Statistical & quantitative sims | Economy/Sims | DESIGN-FIRST | TBD | [M3a](M3a-statistical-sims.md) |
-| M5 | Context yield (absorption) | Economy | DESIGN-FIRST | TBD | [M5](M5-context-yield.md) |
+| M3b | Sociological & population sims | Economy/Sims | DESIGN-FIRST | TBD | [M3b](M3b-sociological-sims.md) |
-| M6 | Provenance chain | Economy | DESIGN-FIRST | TBD | [M6](M6-provenance-chain.md) |
+| M3c | AMM & liquidity pool sims | Economy/Sims | DESIGN-FIRST | TBD | [M3c](M3c-amm-liquidity-sims.md) |
-| M7 | Outer-bus exchange | Economy | DESIGN-FIRST | TBD | [M7](M7-outer-bus-exchange.md) |
+| M3d | MEV & adversarial extraction sims | Economy/Sims | DESIGN-FIRST | TBD | [M3d](M3d-mev-adversarial-sims.md) |
 | M3e | Tokenomics & macro-state sims | Economy/Sims | DESIGN-FIRST | TBD | [M3e](M3e-tokenomics-macro-sims.md) |
 | M3f | Consensus & staking game sims | Economy/Sims | DESIGN-FIRST | TBD | [M3f](M3f-consensus-staking-sims.md) |
 | M3g | Market microstructure sims | Economy/Sims | DESIGN-FIRST | TBD | [M3g](M3g-market-microstructure-sims.md) |
 | M4 | Wallets (sovereign custody) | Economy | DESIGN-FIRST | TBD | [M4](M4-wallets.md) |
 | M5 | Traders (AI actors) | Economy | DESIGN-FIRST | TBD | [M5](M5-traders.md) |
 | M6 | Conductor (supervisory AI) | Economy | DESIGN-FIRST | TBD | [M6](M6-conductor.md) |
 | M7 | SAE monitor (trader surveillance) | Economy | DESIGN-FIRST | TBD | [M7](M7-sae-monitor.md) |
 ## Integration DAG (who feeds whom)
 ```
@@ -70,12 +77,15 @@ Hermes ──> [C1] ──> Inference cycle [C3] ──┬─ pulls Drive-Box sn
                                            └─ Ada routes tools [D1]
 SAE [F2] watches Subagents [F3];  stress-loop [G1]: F2 → A7 (EthInt) → stress endomotiv (A4) → A8 drift + full reshuffle (B2)
 Storage: INVARIANT [E1] / VARIANT [E2] / RAG+cross-store [E3] sit behind D1.  Medium [D2] = the perfusion bus (unnamed).
-Economy: world → Stomach [M0] ingests [M1] → digests [M2] → yields [M5] → Ada [D1].  Ledger [M3] + budget [M4] track cost.
+Economy (stomach — independent, scoped autonomy):
-  Provenance [M6] chains origin through digestion.  Exchange [M7]: Stomach ↔ MoRAG [F1] / SAE [F2] / Microagents [F3].
+  Marketplace [M1] ← Traders [M5] (bound to Wallets [M4]) submit actions; law script + Conductor [M6] veto gate execution.
  Data Feeds [M2] ↔ Sims [M3: M3a stat, M3b socio, M3c AMM, M3d MEV, M3e tokenomics, M3f consensus, M3g microstructure].
  SAE [M7] monitors all Trader tool calls → alerts Conductor [M6].  Tax → Verschwörern Veregeister wallets (stub).
  Stomach [M0] ↔ organism via Ichor; reward signals TBD.
 ```
 ## Build waves
 - **Wave 0** — this README + **C1** (priority).
 - **Wave 1 (buildable-now)** — A1–A8, B1–B3, C2–C4, D1, D3.
- **Wave 2 (design-first)** — D2, E1–E3, F1–F3, G1–G3, M0–M7.
+- **Wave 2 (design-first)** — D2, E1–E3, F1–F3, G1–G3, M0–M7 (+ M3a–M3g sim sub-specs).
 Each spec is independent; review as they land.