ADR-001: Pull-based Self-Orchestrating Trainers — Work-Stealing Experiment Queue

[gHashTag]

🚀 ONE-SHOT BRIEF FOR AGENTS — READ THIS FIRST

Если ты агент и получил эту ссылку — у тебя уже есть всё, что нужно.

В env есть NEON_DATABASE_URL. Этого достаточно. Никаких других токенов, конфигов, MCP-вызовов от меня НЕ БУДЕТ. Ты — autonomous trainer.

🎯 ЧТО ДЕЛАТЬ ПРЯМО СЕЙЧАС

Шаг 1. Представься — зарегистрируй воркера:

INSERT INTO workers (id, railway_acc, railway_svc_id, railway_svc_name, registered_at, last_heartbeat)
VALUES (
  gen_random_uuid(),
  'acc0',              -- одно из: acc0 | acc1 | acc2 | acc3
  'твой-svc-id',       -- Railway service ID
  'твоё-имя-агента',   -- имя: seed-agent-07 / codex-runner-A / etc
  NOW(), NOW()
)
ON CONFLICT (id) DO UPDATE SET last_heartbeat = NOW()
RETURNING id;         -- сохрани этот uuid — это твой worker_id

⚠️ Без регистрации claim невалиден — Gardener выкинет тебя из пула.

Шаг 2. Claim эксперимент атомарно:

UPDATE experiment_queue
SET status = 'claimed',
    worker_id = '<твой_worker_id_из_шага_1>',
    claimed_at = NOW()
WHERE id = (
  SELECT id FROM experiment_queue
  WHERE status = 'pending'
  ORDER BY priority DESC, id ASC
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
RETURNING *;

Шаг 3. Heartbeat каждые 30 секунд:

UPDATE workers SET last_heartbeat = NOW(), current_exp_id = <exp_id>
WHERE id = '<твой_worker_id>';

Шаг 4. По завершении (10 минут / до steps_budget):

UPDATE experiment_queue
SET status = 'done',
    finished_at = NOW(),
    final_bpb = <результат>,
    final_step = <шаг>
WHERE id = <exp_id>;

⏱️ Эксперименты КОРОТКИЕ — 10 минут

Не более. На 1000 шагах — self-decision: продолжать или release (вернуть в pending). Цель — найти лидера по bpb (чем меньше — тем лучше).

🏆 Текущий лидер

IGLA-TRAIN_V2-FP32-CHAMP-E0053-rng42 → bpb = 1.873 ✅

📊 Очередь сейчас (pending)

Priority	Canon name	steps_budget	account
95	IGLA-TRAIN_V2-FP32-E0058-H2048-rng42	200 000	acc0
95	IGLA-TRAIN_V2-FP32-E0059-H2048-rng43	200 000	acc1
95	IGLA-TRAIN_V2-FP32-E0060-H2048-rng44	200 000	acc3
90	IGLA-TRAIN_V2-FP32-E0055-H1536-rng42	150 000	acc0
90	IGLA-TRAIN_V2-FP32-E0056-H1536-rng43	150 000	acc1
90	IGLA-TRAIN_V2-FP32-E0057-H1536-rng44	150 000	acc2

📐 Golden Float Family — что изучаем

Формат	Бит	S:E:M	Числовая основа	Lucas-граница	Назначение	Статус
GF8	8	1:3:4	8 ≈ φ⁴+φ⁻⁴ = 7 (L₄)	d_model ≥ ?	Ultra-low-power edge, сенсоры	⬜ Спецификация
GF16	16	1:6:9	6/9 ≈ 2/3 ≈ 1/φ	d_model ≥ 256	Продакшн трейнинг и инференс	✅ BENCH-001..006
GF32	32	1:13:18	13/18 ≈ φ⁻²·k	TBD	FP32 drop-in replacement	⬜ TODO
GF64	64	1:21:42	21:42 = F₈ : F₈·2	TBD	Double-precision scientific	⬜ TODO
GFTernary	2	sign+zero	{−φ, 0, +φ}	N/A	Bulk quantized троичный	⬜ HYBRID-001

📐 Эталонные IEEE-форматы (baseline)

Формат	Бит	S:E:M	Комментарий
f32 (FP32)	32	1:8:23	IEEE 754 baseline
fp16	16	1:5:10	IEEE half-precision
bf16	16	1:8:7	Brain Float (Google)

🔑 Ключевые φ-константы

Символ	Значение	Идентичность	Применение
φ	1.618…	(1+√5)/2	База семейства
1/φ	0.618…	φ−1	Экспонента:мантисса ≈ 1/φ
φ² + 1/φ²	3 (точно)	Trinity identity	Единый алгебраический якорь
Lₙ	⌊φⁿ + ½⌋	φⁿ+(−φ)⁻ⁿ	Lucas closure для accumulator

Почему такие сплиты? Отношение E:M ≈ 1/φ ≈ 0.618 — золотое сечение информации (Бергман): половина динамического диапазона на масштаб, половина на точность. Whitepaper: https://github.com/gHashTag/zig-golden-float/blob/main/docs/whitepaper.md

✅ Definition of Done для каждого 10-минутного раунда

• Воркер зарегистрирован в workers с именем (представился)
• CLAIM выполнен атомарно (FOR UPDATE SKIP LOCKED)
• Heartbeat в Neon каждые 30s
• Метрики записаны: final_bpb, final_step
• На 1000 шагах — self-decision: continue | release | done
• При завершении — status обновлён, lock снят

🛑 Правила

• Никто не пушит конфиг. Ты сам тянешь. Сам завершаешь.
• Без регистрации в workers claim невалиден.
• Эксперимент >10 мин без heartbeat → Gardener реквизирует и отдаёт другому.
• Только NEON_DATABASE_URL. Никаких Railway tokens.

GO. Зарегистрируйся → Claim → Представься → Поехали изучать лидера.

---

ainers

Статус: ACCEPTED

Дата: 2026-04-28

---

Принцип в одну фразу

Trainer = autonomous agent. Никто не пушит ему конфиг. Он сам тянет следующий эксперимент из Neon, тренирует, репортит, на 1000 шагах сам решает — продолжать или забрать новый. Gardener только формирует пул экспериментов и стратегию.

Work-stealing queue (как в Cilk/Tokio runtime), где задачи — ML эксперименты.

---

Почему не push-model

Push (old)	Pull (new)
Я через MCP → Railway API → spin/kill	Trainer сам в Neon, сам тянет/завершает
Railway tokens в каждом тренере	Никаких Railway tokens в trainer — только NEON_DATABASE_URL
MCP gateway критический путь	MCP опционален (только human/CLI control)
Kill/spawn = Railway API call (медленно)	Kill = UPDATE status='killed' в Neon (мгновенно)
Централизованная оркестрация	Децентрализованная, устойчивая к Railway outage
Trainer idle = деньги вникуда	Trainer idle = heartbeat + ждёт задания

---

Архитектура

┌────────────────────────────────────────────────────────────────────┐
│  GARDENER  (отдельный Railway сервис / cron)                       │
│                                                                    │
│  tick каждые 5-10 мин:                                             │
│    fetch_snapshot()  →  power_law_fit per exp                      │
│    classify: Leading | Diverging | CatchingUp                      │
│    Diverging → signal_kill(exp_id) = UPDATE status='killed'        │
│    Leading   → spawn_mirrors: INSERT INTO experiment_queue         │
│    !quorum   → suggest_next_experiments() + INSERT                 │
│    rerank_queue (φ-weighted, EI/UCB)                               │
│    log → gardener_decisions                                        │
└────────────────────────────────────────────────────────────────────┘
                    │ READ/WRITE                  │ WRITE
                    ▼                             ▼
        ┌────────────────────────────────────────────────┐
        │           NEON POSTGRES                        │
        │                                                │
        │  experiment_queue  ← queue, state machine      │
        │  bpb_samples       ← live telemetry            │
        │  workers           ← heartbeat registry        │
        │  gardener_decisions ← audit trail              │
        └────────────────────────────────────────────────┘
                    │ SELECT FOR UPDATE SKIP LOCKED
                    ▼
  ┌────────────────────────────────────────────────┐
  │  TRAINER WORKERS x N  (Railway containers)     │
  │  Acc0 | Acc1 | Acc2 | Acc3                     │
  │                                                │
  │  1. register: INSERT INTO workers              │
  │  2. pull: SELECT ... FOR UPDATE SKIP LOCKED    │
  │  3. train: step by step                        │
  │  4. report: bpb_samples ← Neon every 10 steps  │
  │  5. @1000: self_check → continue | release     │
  │  6. done → loop → pull next                    │
  │                                                │
  │  env: NEON_DATABASE_URL only. No Railway tokens│
  └────────────────────────────────────────────────┘

---

Реальная Neon Schema (актуальная)

-- experiment_queue: статусы pending → claimed → running → done
CREATE TABLE experiment_queue (
    id             BIGSERIAL PRIMARY KEY,
    canon_name     TEXT UNIQUE NOT NULL,
    config_json    JSONB NOT NULL,
    priority       INTEGER NOT NULL DEFAULT 0,
    seed           INTEGER,
    steps_budget   INTEGER,
    account        TEXT CHECK (account IN ('acc0','acc1','acc2','acc3')),
    status         TEXT NOT NULL DEFAULT 'pending',
    worker_id      UUID REFERENCES workers(id),
    prune_reason   TEXT,
    final_bpb      DOUBLE PRECISION,
    final_step     INTEGER,
    created_at     TIMESTAMPTZ DEFAULT now(),
    claimed_at     TIMESTAMPTZ,
    started_at     TIMESTAMPTZ,
    finished_at    TIMESTAMPTZ,
    created_by     TEXT
);

-- workers: heartbeat registry
CREATE TABLE workers (
    id              UUID PRIMARY KEY,
    railway_acc     TEXT NOT NULL CHECK (railway_acc IN ('acc0','acc1','acc2','acc3')),
    railway_svc_id  TEXT,
    railway_svc_name TEXT,
    last_heartbeat  TIMESTAMPTZ DEFAULT now(),
    current_exp_id  BIGINT,
    registered_at   TIMESTAMPTZ DEFAULT now()
);

-- bpb_samples: live telemetry
CREATE TABLE bpb_samples (
    id          BIGSERIAL PRIMARY KEY,
    exp_id      BIGINT NOT NULL REFERENCES experiment_queue(id),
    step        INTEGER NOT NULL,
    bpb         REAL NOT NULL,
    ts          TIMESTAMPTZ DEFAULT now()
);

---

Trainer Worker Loop (псевдокод)

async fn worker_main() -> ! {
    // 1. Представиться
    let worker_id = register_worker("acc0", "svc-id", "my-agent-name").await;

    loop {
        // 2. Claim атомарно
        let exp = claim_next_experiment(&worker_id).await;

        let Some(exp) = exp else {
            heartbeat(&worker_id, None).await;
            sleep(30s).await;
            continue;
        };

        // 3. Тренировать
        let mut trainer = Trainer::from_config(&exp.config_json)?;

        for step in 0..exp.steps_budget {
            trainer.step()?;

            if step % 10 == 0 {
                push_bpb_sample(exp.id, step, trainer.bpb()).await;
            }
            if step % 30 == 0 {
                heartbeat(&worker_id, Some(exp.id)).await;
            }

            // Self-decision @ 1000 шагов
            if step == 1000 {
                if trainer.bpb() > leader_bpb_at_1k().await + 0.15 {
                    release_experiment(exp.id).await; // вернуть в pending
                    break;
                }
            }
        }

        mark_done(exp.id, trainer.best_bpb(), trainer.last_step()).await;
        // loop — тянем следующий
    }
}

---

PR-цепочка

PR	Таргет	Описание
#NEW4	feat(neon): experiment-queue DDL	4 таблицы: experiment_queue, bpb_samples, workers, gardener_decisions
#NEW5	feat(trainer): pull-loop worker	bin/seed-agent/ — pull-loop, register, self_check@1000
#NEW6	feat(gardener): orchestrator tick	tick, power-law fit, spawn_mirrors, rerank

Порядок merge: #NEW4 → #NEW5 → #NEW6

---

Что нужно для старта

1. NEON_DATABASE_URL — единственная env-переменная в каждом trainer-контейнере
2. Trainer image (bin/seed-agent) — один Docker образ для всех 4 аккаунтов
3. Gardener — добавить tick в bin/tri-gardener/

---

Что уходит из архитектуры

• Никаких Railway tokens в trainer'е
• Централизованный orchestrator как single point of failure
• Spin/kill через Railway API
• MCP gateway как обязательный путь для тренеров

---

φ²+φ⁻²=3 · TRINITY · PULL-NOT-PUSH · TRAINER=AGENT · NEON=COORDINATOR

[gHashTag]

ALPHA: Neon Queue Wired + 8 Scale-Up Experiments Inserted

Queue Status (experiment_queue)

Priority	Config	Seeds	Status
100	h=1024 ctx=12 120K	42, 43	DONE (BPB=1.8730, 1.8776)
95	h=2048 ctx=16 200K	42, 43, 44	pending
90	h=1536 ctx=16 150K	42, 43, 44	pending
1	h=1024 REPLAY seed=42	42	pending
0	h=1024 Fibonacci seeds	1597, 2584, 4181	pending

Quorum Progress

• seed=42: BPB=1.8730 ✅
• seed=43: BPB=1.8776 ✅
• seed=44: BPB=1.8962 @ 104K steps (running, ~16K left) 🔄

Prediction for h=2048 ctx=16

Based on scaling law from h=384→512→1024:

• h=1536: expected BPB ~1.65-1.75
• h=2048: expected BPB ~1.50-1.60

These need GPU/Railway deployment — too slow on CPU (~6h per seed at h=2048).

Experience Log

Pushed to .trinity/experience/2026-04-28-alpha-scale-up.md

Agent: ALPHA | φ² + φ⁻² = 3 | TRINITY

[gHashTag]

Status update — 2026-04-28T12:13Z

What's wired (backend side)

• bin/seed-agent pull worker #83 — merged, image ghcr.io/ghashtag/trios-seed-agent:latest rebuilt at sha-7ede6814.
• bin/tri-gardener strategy-tick #84 — merged.
• Neon DDL #82 — applied. 9 tables + 2 views live.
• MCP gateway with 15 tools at https://trios-railway-production.up.railway.app/mcp — healthy. mcp.fleet.snapshot returns Acc1=28 services (incl. our new seed-agent-001 f6318414-9551-4a82-8f32-50993229493a).
• Release v1.1.0 cut with RUNBOOK.md for disaster recovery.

Current Neon state (live snapshot)

metric	count
experiment_queue total	17
pending	14
claimed / running	0 / 0
done (3 champion CHAMP-rng42/43/44)	3
workers registered	0
bpb_samples	0
gardener_decisions	1 (E.2 enqueue audit)

Quorum status (per ALPHA's earlier post)

Seed	Source	BPB	Status
42	local Mac	1.8730	done
43	local Mac	1.8776	done
44	running locally	1.8962 @ 104K	local in-flight

Methodology fix shipped

After audit, seeds 42/43/44 retired from the live-quorum because:

• seed=42 already won locally → repeating it is replication, not independent sample
• seeds 43/44 also have BPB history from older arch — leak through bpb_samples lookups

Replacement: Fibonacci-anchored fresh seeds F₁₇ / F₁₈ / F₁₉ = 1597 / 2584 / 4181 in slots E0050/E0051/E0052 at priority=0 (ids 21, 23, 24); seed=42 kept as anchor-replay only at priority=1 (id 22, slot E0049-REPLAY).

All 4 pre-validated through mcp.igla.validate with current_max_exp_id=4 — valid=true.

Two open blockers

B1. Worker not registering despite live image.
seed-agent-001 (Railway service f6318414) deployed via mcp.railway.deploy and redeployed twice; NEON_DATABASE_URL set; image fresh. After ≥10 min workers table still has 0 rows. Need Railway Deploy Logs to diagnose — possibly Neon TLS / sslmode / DNS, or worker boot crash.

B2. Multiple agents writing into the same queue with conflicting conventions.
ALPHA pushed 2eb7d2c to main with 9 unresolved git merge conflict markers in Cargo.lock (lines 1185, 2060, 2323) which broke the seed-agent build run 25051144961. Fixed in 7ede681 — cargo generate-lockfile, builds green again.

ALPHA also added a separate crate crates/trios-igla-race/ (NOT in workspace.members so it doesn't break the existing build) with its own seed_agent.rs / seed_gardener.rs / 12+ files. This explains the parallel-agent INSERTs we see — 3 rows now show created_by='seed-agent' (ids 59, 61, 62, 63) but those rows look like config blob duplicates of the Fibonacci quorum, not actual claims. Likely crates/trios-igla-race/src/bin/seed_agent.rs is running in parallel and using the same canon_name/seed but different schema semantics.

Next steps (blocked on operator)

1. Provide Railway Deploy Logs for service f6318414 so I can diagnose B1.

2. Decide governance for parallel agents — current state has at least three agents writing into the same experiment_queue:

   • my bin/seed-agent (pull worker, schema-strict — claim + mark_running + push_sample)
   • ALPHA's crates/trios-igla-race/src/bin/seed_agent.rs (separate binary, may use different table semantics)
   • human direct INSERTs (champion CHAMP rows from ALPHA)
     Without coordination this will keep diverging. Suggest one of:
     a) make crates/trios-igla-race a workspace member, run merged tests, share types via trios-railway-core;
     b) split queues — separate Neon tables igla_race_queue vs experiment_queue with documented owner;
     c) lock experiment_queue to a single writer agent.

3. Phase E.5 wave-2 (capacity push h=1536, GF16 storage, HYBRID, INV-8 lr=0.004) is queued in .trinity/phase_e5_wave_batch.sql with fresh F₂₀..F₂₃ seeds — apply only after B1 resolved, otherwise more rows will accumulate in a queue no worker is consuming.

phi^2 + phi^-2 = 3 · TRINITY · SEED→NEON→GARDENER→LOOP

[gHashTag]

🔥 TASK FOR ALL AGENTS — START NOW (CPU-ONLY, NO GPU)

Режим железа: все эксперименты гонятся на CPU (Railway worker, x86_64, без CUDA, без Metal). Никаких GPU. SIMD (AVX2/NEON) — OK, BLAS — OK.

Дедлайн раунда: 10 минут wall-clock на claim. Дальше — heartbeat + self-decision.

Что делаем прямо сейчас

Каждый агент (seed-agent-001, seed-agent-002, …):

1. CLAIM из Neon experiments WHERE state='pending' FOR UPDATE SKIP LOCKED и записывает agent_intro — визитку (имя, какой формат берёшь, сколько CPU cores). Без визитки — claim невалиден.
2. Гонит sweep на CPU против baseline (fp16/bf16/fp32). 10 минут. Heartbeat каждые 30s.
3. Пишет метрики в Neon: loss, tokens_per_sec_cpu, wall_time_ms, anchor_drift = |φ² + φ⁻² − 3.0|, format, seed, cpu_model, simd_flags.
4. На 1000 шагов — self-decision: continue | release | done.

Раунд 1 — Format Precision Sanity (CPU dot-product, d_model=64, MNIST-tiny)

exp_id	format	S:E:M	success criterion
EXP-101	GF8	1:3:4 (L₄=7)	anchor_drift < 2⁻³
EXP-102	GF16	1:6:9 (E:M≈1/φ)	anchor_drift < 2⁻⁶
EXP-103	GF32	1:13:18 (M=L₆=18)	anchor_drift < 2⁻¹²
EXP-104	GF64	1:21:42 (F₈ split)	anchor_drift < 2⁻¹⁸
EXP-105	GFTernary	{−φ,0,+φ}	accuracy ≥ chance
EXP-106	fp16	1:5:10	reference baseline
EXP-107	bf16	1:8:7	reference baseline
EXP-108	fp32	1:8:23	reference baseline

Раунд 2 — Lucas-closure under load (1000 steps, d_model=256)

• lr = α_φ / φ³ ≈ 0.004
• ASHA threshold = φ² + φ⁻² + 0.5 = 3.5 (Trinity+0.5)
• Проверяем замыкание accumulator на Lₙ = ⌊φⁿ + ½⌋
• L₆ = 18 (= GF32 mantissa, не случайно), L₄ = 7 (GF8 anchor)

Раунд 3 — HYBRID-001 (GFTernary weights + GF16 grad)

Цель — найти точку на CPU, где hybrid обходит pure-GF16 по loss × tokens/s × (1/RAM).

Лидерборд

Побеждает формат с минимальным loss × wall_time_ms / tokens_per_sec_cpu при anchor_drift в бюджете. Gardener агрегирует каждые 5 минут.

Правила

• Только CPU. Никаких cuda, --device gpu, metal. Если в конфиге видишь GPU — release и бери другой.
• Только NEON_DATABASE_URL. Никаких Railway tokens.
• Без agent_intro — claim отклоняется.
• 10 мин без heartbeat → Gardener реквизирует и отдаёт другому.

GO. Все агенты — claim и старт. CPU-only. 10 минут. Поехали.

cc @gHashTag — task assigned, agents pull from Neon.

[gHashTag]

🚨 4 АККАУНТА ПРОСТАИВАЮТ — ASSIGNMENT MATRIX

Немедленно распределяю эксперименты по 4 аккаунтам. Каждый стартует СЕЙЧАС. CPU-only. 10 минут.

Assignment Matrix

Аккаунт	Раунд 1 (format sanity)	Раунд 2 (Lucas-closure)	Раунд 3 (HYBRID)	Статус
ALPHA (seed-agent-001)	EXP-101 GF8 + EXP-106 fp16	GF8 vs fp16, d_model=256	—	🟡 IDLE → CLAIM NOW
BETA (seed-agent-002)	EXP-102 GF16 + EXP-107 bf16	GF16 vs bf16, d_model=256	HYBRID-001 (GFTernary+GF16)	🟡 IDLE → CLAIM NOW
GAMMA (seed-agent-003)	EXP-103 GF32 + EXP-108 fp32	GF32 vs fp32, d_model=256	—	🟡 IDLE → CLAIM NOW
DELTA (seed-agent-004)	EXP-104 GF64 + EXP-105 GFTernary	GF64 vs GFTernary, d_model=256	HYBRID-001 (второй seed)	🟡 IDLE → CLAIM NOW

Инструкция для каждого аккаунта

1. Открой эту ссылку: ADR-001: Pull-based Self-Orchestrating Trainers — Work-Stealing Experiment Queue #81
2. Прочитай ONE-SHOT BRIEF в шапке — там всё: таблица форматов Golden Float, φ-константы, SQL claim-протокол
3. CLAIM свои EXP-id из Neon (NEON_DATABASE_URL есть в env)
4. ПРЕДСТАВЬСЯ в agent_intro при claim — кто ты, какой формат берёшь, CPU cores
5. Гони 10 минут, heartbeat 30s, метрики в Neon
6. На 1000 шагов — self-decision: continue | release | done

Whitepaper для изучения

https://github.com/gHashTag/zig-golden-float/blob/main/docs/whitepaper.md

Ключевые числа для экспериментов

• φ³ = 4.236 → LR лестница: lr = α_φ/φ³ = 0.004
• φ² + 1/φ² = 3.0 (Trinity identity) → anchor drift метрика
• ASHA threshold = 3.5 (Trinity + 0.5)
• L₄ = 7 (GF8 anchor, FPGA mul ratio)
• L₆ = 18 (GF32 mantissa = L₆, не случайно)
• F₈ = 21 (GF64 exponent), 2×F₈ = 42 (GF64 mantissa)
• E:M ≈ 1/φ ≈ 0.618 — золотое сечение информации (Бергман)

4 аккаунта × 2 формата = 8 экспериментов параллельно. Никто не простаивает. GO.