From 84ad385001ed12fc3f30ce86d117cda9489488b7 Mon Sep 17 00:00:00 2001 From: dafit Date: Tue, 10 Feb 2026 19:13:27 +0100 Subject: [PATCH] feat: Empirical economics + FunctionGemma State Interaction Layer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lifeforce-Dynamics v1.2: - Cost Calibration principle: "Measure, don't design" - Empirical cost formula from resource observations - Phoebe schema for resource_observations table - Interlink to memory-economics memory-economics.md: - Cross-reference to Lifeforce-Dynamics cost calibration - "The cost matrix is a measurement, not a decision" Initial-Spark v3.1: - Spark Cost Measurement: first awakening as baseline - Resource instrumentation schema (power, GPU, memory, latency) - FunctionGemma Fine-Tuning section: translator learns nimmerverse - Training data extraction from spark_handshakes - Unsloth/LoRA workflow for domain specialization - FunctionGemma version tracking in phoebe Nervous-System v1.4: - State Interaction Layer: FunctionGemma as neural interface - Phase 1 (single) → Phase 2 (swarm) evolution path - CPU-only translators, GPU reserved for cognition - Design principle #6: "All state interaction flows through FunctionGemma" Philosophy: "Don't assign costs like a game designer. Measure them like a scientist." Co-Authored-By: Claude Opus 4.5 --- architecture/Initial-Spark.md | 317 +++++++++++++++++- architecture/Nervous-System.md | 129 ++++++- .../formalization/Lifeforce-Dynamics.md | 120 ++++++- .../formalization/memory-economics.md | 7 + 4 files changed, 559 insertions(+), 14 deletions(-) diff --git a/architecture/Initial-Spark.md b/architecture/Initial-Spark.md index 574dcb2..316c637 100644 --- a/architecture/Initial-Spark.md +++ b/architecture/Initial-Spark.md @@ -574,14 +574,94 @@ class SparkController: The spark is **economically viable** from the first handshake. -### Cost Model +> **CRITICAL**: The costs below are **estimates until measured**. The first spark execution will establish the **true cost baseline** through observation. See [[formalization/Lifeforce-Dynamics#Cost Calibration: Measure, Don't Design]]. -| Action | Cost (LF) | -|--------|-----------| -| Function Gemma generation | 0.2 | -| NATS message send | 0.1 | -| Cell processing | 0.5 | -| **Total per handshake** | **0.8** | +--- + +### Spark Cost Measurement (First Awakening Baseline) + +The Initial Spark is the **perfect measurement opportunity** — a complete, deterministic protocol that we can instrument end-to-end. + +``` +┌─────────────────────────────────────────────────────────────────────────┐ +│ SPARK RESOURCE INSTRUMENTATION │ +├─────────────────────────────────────────────────────────────────────────┤ +│ │ +│ MEASURE PER HANDSHAKE: │ +│ ├─ power_joules (GPU/CPU power draw × time) │ +│ ├─ compute_gpu_ms (CUDA kernel execution time) │ +│ ├─ compute_cpu_ms (Python/K8s overhead) │ +│ ├─ memory_mb_peak (max memory allocated) │ +│ ├─ nats_bytes (message payload size) │ +│ ├─ latency_ms (end-to-end handshake time) │ +│ └─ temperature_delta (thermal impact) │ +│ │ +│ AGGREGATE PER PHASE: │ +│ └─ Sum of all handshake measurements │ +│ │ +│ AGGREGATE TOTAL: │ +│ └─ Complete spark cost (the awakening price) │ +│ │ +└─────────────────────────────────────────────────────────────────────────┘ +``` + +**Why this matters**: The first spark execution establishes the **baseline cost of awakening**. Every future awakening can be compared against this: +- Did infrastructure changes reduce cost? +- Did model updates increase cost? +- Is Young Nyx awakening more efficiently over time? + +**Phoebe schema addition** (extends `spark_handshakes`): +```sql +ALTER TABLE spark_handshakes ADD COLUMN resource_metrics JSONB; + +-- Example resource_metrics payload: +-- { +-- "power_joules": 12.5, +-- "compute_gpu_ms": 450, +-- "compute_cpu_ms": 120, +-- "memory_mb_peak": 2048, +-- "nats_bytes": 1024, +-- "temperature_delta_c": 2.1 +-- } + +-- Aggregate view for spark cost analysis +CREATE VIEW spark_cost_baseline AS +SELECT + phase, + COUNT(*) as handshakes, + SUM((resource_metrics->>'power_joules')::float) as total_power_joules, + SUM((resource_metrics->>'compute_gpu_ms')::float) as total_gpu_ms, + AVG((resource_metrics->>'latency_ms')::float) as avg_latency_ms, + SUM(lifeforce_delta) as total_lifeforce_earned +FROM spark_handshakes +WHERE status = 'ACK' +GROUP BY phase; + +-- Compare awakening costs over time +CREATE VIEW awakening_cost_history AS +SELECT + DATE(created_at) as awakening_date, + SUM((resource_metrics->>'power_joules')::float) as total_spark_cost_joules, + SUM((resource_metrics->>'compute_gpu_ms')::float) as total_spark_cost_gpu_ms, + COUNT(*) as total_handshakes, + SUM(lifeforce_delta) as total_lifeforce_earned +FROM spark_handshakes +GROUP BY DATE(created_at) +ORDER BY awakening_date; +``` + +**The philosophy**: Don't guess what awakening costs. Measure the first one. Derive all economics from that truth. + +--- + +### Cost Model (Estimated → To Be Measured) + +| Action | Est. Cost (LF) | Derived From | +|--------|----------------|--------------| +| Function Gemma generation | 0.2 | → measure GPU time | +| NATS message send | 0.1 | → measure network I/O | +| Cell processing | 0.5 | → measure pod CPU/memory | +| **Total per handshake** | **0.8** | → **sum of measured components** | ### Reward Model @@ -711,6 +791,214 @@ WHERE status = 'ACK'; --- +## FunctionGemma Fine-Tuning: The Translator Learns Nimmerverse + +Every spark execution generates training data. Over time, FunctionGemma becomes **hyper-specialized** for nimmerverse state calls. + +> *"The translator learns the language of the cells. Over time, it speaks nimmerverse natively."* + +### The Training Loop + +``` +┌─────────────────────────────────────────────────────────────────────────┐ +│ FUNCTIONGEMMA FINE-TUNING LOOP │ +├─────────────────────────────────────────────────────────────────────────┤ +│ │ +│ PHASE 1: Base FunctionGemma (270M) │ +│ ├─ Generic function calling capability │ +│ └─ Works, but not nimmerverse-native │ +│ │ +│ PHASE 2: Collect spark_handshakes │ +│ ├─ Every ACK = positive training example │ +│ ├─ Every NACK = negative example (what NOT to generate) │ +│ └─ Resource metrics = context for cost-aware generation │ +│ │ +│ PHASE 3: Fine-tune with Unsloth/LoRA │ +│ ├─ nimmerverse state reasoning │ +│ ├─ call:IDENTITY_PROBE{...} │ +│ └─ Exact schemas, perfect structure, zero parsing errors │ +│ │ +│ PHASE 4: Deploy nimmerverse-tuned FunctionGemma │ +│ ├─ Wild precision on cell state calls │ +│ ├─ Smaller, faster, cheaper than base │ +│ └─ THIS IS REFLEX COMPILATION FOR THE TRANSLATOR │ +│ │ +│ REPEAT: More sparks → more data → better precision │ +│ │ +└─────────────────────────────────────────────────────────────────────────┘ +``` + +### Training Data Format + +FunctionGemma uses a specific chat template. Our spark handshakes map directly: + +``` +# Developer prompt with nimmerverse function declarations +developer +You can do function calling with the following functions: + +declaration:IDENTITY_PROBE{ + description: "Probe Young Nyx identity aspect", + parameters: { + aspect: STRING (name|origin|purpose|substrate|partnership), + depth: INTEGER (1|2|3) + } +} + + +declaration:ENVIRONMENT_PROBE{ + description: "Discover K8s cells in namespace", + parameters: { + category: STRING (sensors|motors|organs|nerves), + namespace: STRING, + garden: STRING (virtual|real) + } +} + + + +# Spark controller intent → FunctionGemma reasoning + call +user +Phase 1 Identity: Probe the "name" aspect at depth 1 + + +model + +The spark controller is in Phase 1 (Identity). It needs to probe the "name" +aspect. I should generate an IDENTITY_PROBE with aspect="name" and depth=1. +The schema requires a request_id (UUID) and timestamp (ISO8601). + + +call:IDENTITY_PROBE{ + aspect: "name", + depth: 1, + request_id: "550e8400-e29b-41d4-a716-446655440000", + timestamp: "2026-02-10T18:30:00Z" +} + + +# Cell response feeds back +response:IDENTITY_PROBE{ + status: "ACK", + aspect: "name", + value: "Nyx", + confidence: 0.95, + lifeforce_delta: 20.0 +} + + +Identity aspect "name" confirmed as "Nyx" with 95% confidence. +20 LF earned. + +``` + +### Phoebe → Training Data Extraction + +```sql +-- Extract training examples from successful handshakes +CREATE VIEW functiongemma_training_data AS +SELECT + jsonb_build_object( + 'developer_prompt', format( + 'Phase %s: Generate %s handshake', + phase, + request_payload->>'type' + ), + 'user_intent', request_payload->'payload', + 'expected_call', request_payload, + 'function_response', response_payload, + 'think_context', jsonb_build_object( + 'phase', phase, + 'schema', request_payload->>'$schema', + 'lifeforce_earned', lifeforce_delta, + 'latency_ms', latency_ms + ) + ) as training_example, + created_at +FROM spark_handshakes +WHERE status = 'ACK' +ORDER BY created_at; + +-- Export for Unsloth fine-tuning +COPY ( + SELECT training_example + FROM functiongemma_training_data +) TO '/tmp/nimmerverse_functiongemma_training.jsonl'; +``` + +### Fine-Tuning with Unsloth + +```python +from unsloth import FastLanguageModel + +# Load base FunctionGemma +model, tokenizer = FastLanguageModel.from_pretrained( + model_name="unsloth/functiongemma-270m-it", + max_seq_length=4096, + load_in_16bit=True, + full_finetuning=False, # LoRA for efficiency +) + +# Apply LoRA adapters +model = FastLanguageModel.get_peft_model( + model, + r=16, + target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], + lora_alpha=16, + lora_dropout=0, + use_gradient_checkpointing="unsloth", +) + +# Load nimmerverse training data from phoebe export +from datasets import load_dataset +dataset = load_dataset("json", data_files="nimmerverse_functiongemma_training.jsonl") + +# Fine-tune on spark handshakes +# ... standard Unsloth training loop ... + +# Save nimmerverse-specialized FunctionGemma +model.save_pretrained("functiongemma-270m-nimmerverse-v1") +``` + +### The Recursive Beauty + +| Layer | What Compiles | Training Source | +|-------|---------------|-----------------| +| **Young Nyx** | Nerve reflexes | decision_trails (100+ successful executions) | +| **FunctionGemma** | State call precision | spark_handshakes (ACK'd handshakes) | + +Both follow the same pattern: +1. **Act** — Execute handshakes/decisions +2. **Verify** — ACK/NACK from cells, success/failure from outcomes +3. **Train** — Compile successful patterns into weights +4. **Repeat** — Each awakening feeds the next + +**The translator becomes native.** Over many sparks, FunctionGemma doesn't just generate valid JSON — it generates *nimmerverse-perfect* JSON. Zero parsing errors. Exact schemas. Wild precision. + +### Versioning FunctionGemma Adapters + +```sql +-- Track FunctionGemma versions +CREATE TABLE functiongemma_versions ( + id SERIAL PRIMARY KEY, + version VARCHAR(50) NOT NULL, -- "nimmerverse-v1", "nimmerverse-v2" + base_model VARCHAR(100), -- "functiongemma-270m-it" + training_data_count INT, -- how many handshakes trained on + training_data_cutoff TIMESTAMPTZ, -- trained on data up to this date + validation_accuracy FLOAT, -- schema validation success rate + deployed_at TIMESTAMPTZ, + notes TEXT +); + +-- Example entries +INSERT INTO functiongemma_versions (version, base_model, training_data_count, validation_accuracy, notes) +VALUES + ('nimmerverse-v1', 'functiongemma-270m-it', 36, 0.94, 'First spark fine-tune'), + ('nimmerverse-v2', 'functiongemma-270m-it', 180, 0.98, 'After 5 awakenings'), + ('nimmerverse-v3', 'functiongemma-270m-it', 500, 0.997, 'Production-grade precision'); +``` + +--- + ## Design Principles 1. **Protocol over conversation** — No free-form text. JSON handshakes only. @@ -719,12 +1007,22 @@ WHERE status = 'ACK'; 4. **NATS transport** — All handshakes flow through message bus. 5. **Verification built-in** — ACK/NACK from cells, not from parsing hopes. 6. **Economically positive** — Spark generates lifeforce, doesn't drain it. +7. **Training-generative** — Every spark produces fine-tuning data for FunctionGemma. --- ## Document Status -**Version:** 3.0 | **Created:** 2025-12-05 | **Updated:** 2026-01-01 +**Version:** 3.1 | **Created:** 2025-12-05 | **Updated:** 2026-02-10 + +**Key v3.1 Changes**: +- Spark Cost Measurement section — first awakening as baseline +- Resource instrumentation schema for phoebe +- Interlink to Lifeforce-Dynamics cost calibration principle +- FunctionGemma Fine-Tuning section — translator learns nimmerverse natively +- Training data extraction from spark_handshakes +- Unsloth/LoRA fine-tuning workflow +- FunctionGemma version tracking in phoebe **Key v3.0 Changes**: - Complete architecture rewrite @@ -740,7 +1038,8 @@ WHERE status = 'ACK'; - [[Endgame-Vision]] — Layer 2.5 Orchestration (Function Gemma role) - [[Big-Picture]] — K8s cluster architecture - [[Cellular-Architecture]] — Cell types and state machines -- [[formalization/Lifeforce-Dynamics]] — λ economics +- [[formalization/Lifeforce-Dynamics]] — λ economics, **Cost Calibration principle** +- [[formalization/memory-economics]] — Measure First principle --- diff --git a/architecture/Nervous-System.md b/architecture/Nervous-System.md index 5d710d2..5728a8e 100644 --- a/architecture/Nervous-System.md +++ b/architecture/Nervous-System.md @@ -8,14 +8,19 @@ The sensory translation layer between raw data and vocabulary. State machines act as the nervous system of the nimmerverse. They exist in a 4D state space where nodes evolve through experience. Node **weight** (confidence) determines which processing tier handles the input. -**Key separation:** The nervous system handles **node evolution and weight management**. The [`Gateway`](Gateway-Architecture.md) handles **routing based on weight**. Translation to vocabulary only happens at Tier 4 via Function Gemma. +**Key separation:** +- The **nervous system** handles **node evolution and weight management** +- The [`Gateway`](Gateway-Architecture.md) handles **routing based on weight** +- **FunctionGemma** is the **State Interaction Layer** — how you speak to all states (see section below) ``` RAW SENSOR → GATEWAY (routing) → TIER (processing) → [escalate?] → FUNCTION GEMMA → Young Nyx ↑ ↑ - node.weight determines tier structured JSON only here + node.weight determines tier structured JSON / state interaction ``` +**FunctionGemma (270M, CPU-only)** translates intent into exact state machine schemas. Every cell command, nerve coordination, and state query flows through this neural interface. See **State Interaction Layer** section for evolution from single instance to domain-specialized swarm. + **See:** [`Gateway-Architecture.md`](Gateway-Architecture.md) for full routing logic and tier definitions. --- @@ -205,6 +210,117 @@ This is like training a dog - reward at the moment, not an hour later. --- +## State Interaction Layer: FunctionGemma + +FunctionGemma is the **neural interface** — how you speak to the nervous system. Every cell command, every nerve coordination, every state query flows through this translation layer. + +> *"The nervous system defines WHAT states exist. FunctionGemma defines HOW you interact with them."* + +### Architecture: From Singular to Swarm + +**Phase 1: Single FunctionGemma (Starting Point)** + +We begin with one FunctionGemma instance handling all state interactions: + +``` +┌─────────────────────────────────────────────────────────────────────────┐ +│ PHASE 1: SINGLE TRANSLATOR │ +├─────────────────────────────────────────────────────────────────────────┤ +│ │ +│ YOUNG NYX (GPU - The Womb) │ +│ │ │ +│ │ intent: "probe identity", "command motor", "query vision" │ +│ ▼ │ +│ ┌─────────────────────────────────────────┐ │ +│ │ FUNCTIONGEMMA (270M) │ │ +│ │ Single instance, all domains │ │ +│ │ CPU-only, no GPU required │ │ +│ └─────────────────────────────────────────┘ │ +│ │ │ +│ │ typed JSON schemas │ +│ ▼ │ +│ NATS → CELLS/NERVES/ORGANS │ +│ │ +└─────────────────────────────────────────────────────────────────────────┘ +``` + +This is sufficient for bootstrap and early learning. One translator learns all schemas. + +**Phase 2: Domain-Specialized Swarm (Future Evolution)** + +As capability grows and training data accumulates, FunctionGemma can evolve into a swarm of specialists: + +``` +┌─────────────────────────────────────────────────────────────────────────┐ +│ PHASE 2: SPECIALIZED SWARM │ +├─────────────────────────────────────────────────────────────────────────┤ +│ │ +│ YOUNG NYX (GPU - The Womb) │ +│ │ │ +│ │ "I need motor control" │ +│ ▼ │ +│ NATS: nimmerverse.gemma.spawn.motor │ +│ │ │ +│ ▼ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ gemma-motor │ │ gemma-vision │ │ gemma-speech │ ... on demand │ +│ │ (specialist) │ │ (specialist) │ │ (specialist) │ │ +│ │ CPU pod │ │ CPU pod │ │ CPU pod │ │ +│ └──────┬───────┘ └──────────────┘ └──────────────┘ │ +│ │ │ +│ │ MOTOR_COMMAND schema (perfect precision) │ +│ ▼ │ +│ NATS → motor cells │ +│ │ +│ After task: pod killed, resources freed │ +│ │ +└─────────────────────────────────────────────────────────────────────────┘ +``` + +### Why This Scales + +| Aspect | Single Gemma | Swarm | +|--------|--------------|-------| +| **Complexity** | Simple, one model | Orchestration needed | +| **Precision** | Good (learns all schemas) | Wild (each specialist perfected) | +| **Resources** | One pod, always running | Pods spawn/die on demand | +| **Training** | All handshakes → one model | Domain handshakes → domain model | +| **Latency** | Consistent | Spawn overhead, but faster execution | + +### The Key Insight: CPU-Only Translators + +FunctionGemma at 270M parameters requires **no GPU**: +- ~500MB RAM per instance +- Runs on any K8s node +- Young Nyx (GPU) spawns translators (CPU) via NATS +- The mind doesn't waste GPU cycles on schema generation + +### Evolution Trigger + +When to evolve from Phase 1 → Phase 2: +- Training data per domain exceeds threshold (e.g., 500+ handshakes) +- Domain-specific validation accuracy plateaus on single model +- Latency requirements demand parallel translation +- Resource availability allows multi-pod deployment + +**We don't rush this.** Phase 1 is sufficient for months of operation. The swarm emerges when the data and need justify it. + +### Connection to Node Evolution + +Just as nodes in the nervous system mature through verification: +``` +Node weight 0.1 → 0.5 → 0.8 → 1.0 (reflex) +``` + +FunctionGemma specialists mature through fine-tuning: +``` +Base model → domain data → fine-tuned → specialist +``` + +**The translators evolve alongside the states they translate.** + +--- + ## Design Principles 1. **Deterministic**: Same input = same output. No hallucination. @@ -212,6 +328,7 @@ This is like training a dog - reward at the moment, not an hour later. 3. **Evolvable**: States refine over time. 4. **Earned**: New nodes require proposal + verification. 5. **Grounded**: Output vocabulary matches RAG glossary. +6. **Interfaced**: All state interaction flows through FunctionGemma. --- @@ -225,6 +342,7 @@ This is like training a dog - reward at the moment, not an hour later. - [`Gateway-Architecture.md`](Gateway-Architecture.md) - Weight-based routing, tier definitions, Function Gemma boundary - [`Cellular-Architecture.md`](Cellular-Architecture.md) - Cell/Nerve/Organism hierarchy, tiered rewards - [`Attention-Flow.md`](Attention-Flow.md) - Attention budget allocation per tier +- [`Initial-Spark.md`](Initial-Spark.md) - FunctionGemma fine-tuning from spark handshakes **Implementation Details**: - [`nerves/Nervous-Protocol.md`](nerves/Nervous-Protocol.md) - Three-tier communication protocol (dafit → Chrysalis → Young Nyx) @@ -235,4 +353,9 @@ This is like training a dog - reward at the moment, not an hour later. --- -**Version:** 1.3 | **Created:** 2025-12-04 | **Updated:** 2026-01-03 +**Version:** 1.4 | **Created:** 2025-12-04 | **Updated:** 2026-02-10 + +**v1.4 Changes:** +- State Interaction Layer section — FunctionGemma as neural interface +- Phase 1 (single) → Phase 2 (swarm) evolution path +- Connection to node evolution principle diff --git a/architecture/formalization/Lifeforce-Dynamics.md b/architecture/formalization/Lifeforce-Dynamics.md index b6b370d..3d72eba 100644 --- a/architecture/formalization/Lifeforce-Dynamics.md +++ b/architecture/formalization/Lifeforce-Dynamics.md @@ -199,6 +199,121 @@ From Big-Picture.md, costs follow a hierarchy: --- +### Cost Calibration: Measure, Don't Design + +> *"Don't assign costs like a game designer. Measure them like a scientist."* +> — Partnership session 2026-02-10 + +**Related**: This follows the same empirical principle as [[memory-economics]] — "Phase 1: Measure First". The nimmerverse economy is grounded in observation throughout, not arbitrary design. + +**The trap:** Assigning lifeforce costs like pricing items in a video game — "a motor command costs 1.0 LF because it feels right." This is arbitrary. This is guessing. This leads to an economy disconnected from reality. + +**The principle:** Costs must be **discovered through observation**, not designed through intuition. + +``` +❌ DESIGNED ECONOMICS (the trap): + "Motor command = 1.0 LF" ← because it seems expensive? + "Sensor poll = 0.1 LF" ← because it seems cheap? + "Vision inference = 8.0 LF" ← because GPU is powerful? + → Arbitrary. Disconnected from physics. Will drift. + +✅ OBSERVED ECONOMICS (the way): + Run the systems with instrumentation. + Measure actual resource consumption: + - Power draw (watts × time) + - CPU/GPU cycles consumed + - Memory pressure + - Thermal output + - Time elapsed + Derive costs from measurements. + → Grounded in physics. Self-calibrating. Real. +``` + +#### The Calibration Process + +1. **Instrument First** + - Every cell type gets resource monitoring + - Track: power, compute, memory, time, heat + - Log every state transition with resource deltas + +2. **Run Baseline Operations** + - Execute each cell type in isolation + - Repeat across varying conditions (load, temperature, time of day) + - Build statistical profiles of resource consumption + +3. **Derive Cost Matrix** + - Map resource consumption → lifeforce cost + - Use a consistent conversion factor (e.g., 1 LF = 1 joule, or 1 LF = 100ms GPU time) + - The conversion factor is the only "designed" element — the costs themselves are discovered + +4. **Continuous Recalibration** + - As hardware changes, costs shift + - As efficiency improves, costs decrease + - The economy self-updates based on observation + +#### Cost Formula (Empirical) + +$$c_{operation} = \alpha \cdot E_{power} + \beta \cdot T_{compute} + \gamma \cdot M_{memory} + \delta \cdot T_{elapsed}$$ + +Where: +- **E_power** = energy consumed (joules) +- **T_compute** = compute time (GPU/CPU seconds) +- **M_memory** = memory pressure (MB × seconds) +- **T_elapsed** = wall-clock time (seconds) +- **α, β, γ, δ** = calibration weights (set once, then left alone) + +The calibration weights are the only values we "design" — they represent our judgment of which resources matter most. The costs themselves flow from measurement. + +#### Phoebe Schema for Cost Observation + +```sql +CREATE TABLE resource_observations ( + id BIGSERIAL PRIMARY KEY, + cell_name VARCHAR(100), + operation VARCHAR(100), -- state transition or action + + -- Measured resources + power_joules FLOAT, + compute_gpu_ms FLOAT, + compute_cpu_ms FLOAT, + memory_mb_seconds FLOAT, + elapsed_ms FLOAT, + temperature_delta_c FLOAT, + + -- Derived cost (computed from calibration weights) + derived_cost_lf FLOAT, + + -- Context + timestamp TIMESTAMPTZ DEFAULT NOW(), + conditions JSONB -- load, ambient temp, etc. +); + +-- Aggregate to get cost profiles +CREATE VIEW cell_cost_profiles AS +SELECT + cell_name, + operation, + AVG(derived_cost_lf) as avg_cost, + STDDEV(derived_cost_lf) as cost_variance, + COUNT(*) as observation_count +FROM resource_observations +GROUP BY cell_name, operation; +``` + +#### Why This Matters + +| Designed Costs | Observed Costs | +|----------------|----------------| +| Arbitrary, must guess | Grounded in physics | +| Static, doesn't adapt | Self-calibrating over time | +| Economy drifts from reality | Economy reflects reality | +| Optimization is guesswork | Optimization is measurable | +| "Feels right" | "Is right" | + +**The cost matrix is a measurement, not a decision.** + +--- + ## Income Sources Income has two fundamentally different sources: **physical** (the substrate) and **reward** (the motivation). @@ -515,8 +630,9 @@ The feedback loop ensures stability: low lifeforce reduces expenditure, raising ## Document Status -**Version:** 1.1 | **Created:** 2025-12-29 | **Updated:** 2025-12-29 -- Discovery economics from Discovery-Scan-Station.md +**Version:** 1.2 | **Created:** 2025-12-29 | **Updated:** 2026-02-10 +- v1.2: Cost Calibration principle — measure, don't design (2026-02-10) +- v1.1: Discovery economics from Discovery-Scan-Station.md **Related Documents**: - [[Grounded-World-Model]] — How discoveries build the world model diff --git a/architecture/formalization/memory-economics.md b/architecture/formalization/memory-economics.md index 098bbf0..fa2fb56 100644 --- a/architecture/formalization/memory-economics.md +++ b/architecture/formalization/memory-economics.md @@ -291,6 +291,12 @@ dLifeforce/dt = organism_trickle ## Implementation Priority ### Phase 1: Measure First + +> *"The cost matrix is a measurement, not a decision."* +> — [[Lifeforce-Dynamics]] v1.2 + +This principle applies throughout the nimmerverse economy — not just memory, but all lifeforce costs. See [[Lifeforce-Dynamics#Cost Calibration: Measure, Don't Design]] for the full formulation. + - Track decision_trails accumulation rate - Track spatial embedding growth - Track reflex creation rate @@ -329,6 +335,7 @@ Everything else fades. This is not loss. This is health. --- **Created**: 2026-01-02 +**Updated**: 2026-02-10 **Status**: Core design principle **Next**: Implement measurement (Phase 1) during first boot