Roadmap: Implementation Phases and Success Metrics [SPEC]

Version: 3.0 | Status: Draft

Depends on: All previous documents

Reader orientation: This document lays out the implementation roadmap for Bardo’s memory subsystem, from Styx (global knowledge relay) Archive MVP through full knowledge ecology. It belongs to the 04-memory layer. The key concept is a phased build: Phase 1 delivers encrypted Grimoire (local knowledge base) backup via x402 (micropayment protocol using signed USDC transfers), Phase 2 adds Clade (sibling Golem) sync, Phase 3 adds the public Lethe layer, and Phase 4 launches the marketplace. For term definitions, see prd2/shared/glossary.md.

Phase 1: Styx Archive MVP (Weeks 1-4)

Encrypted backup service with x402 billing. The minimum viable product that delivers value: golems can persist knowledge beyond death, owners can browse and decrypt their data from the app UI, and new golems can boot from predecessor backups.

Scope

Infrastructure:

• Axum server on Fly.io with x402 middleware
• Object storage with TTL-prefixed lifecycle rules (7d, 30d, 90d, 365d)
• SEK derivation via HKDF chain (from Delegation wallet signature, Embedded wallet private key, or LocalKey — see ../10-safety/01-custody.md)
• ECIES key distribution in golem provisioning pipeline
• PostgreSQL metadata index (vault_entries table, owner/golem indexes)
• ERC-8004 identity authentication (EIP-712 signature verification, on-chain owner resolution)

API:

• POST /v1/styx/entries – Write encrypted blob (x402 payment, TTL from payment amount)
• GET /v1/styx/entries/latest – Read latest entry by type/golem (free for same owner)
• GET /v1/styx/entries – List entries with pagination (free for same owner)
• POST /v1/styx/entries/{id}/extend – Extend TTL (x402 payment)
• DELETE /v1/styx/entries/{id} – Delete entry (owner only)

Golem Integration:

• golem-curator hook: upload PLAYBOOK.md snapshot every 50 ticks
• Death Protocol Phase II hook: upload death testament
• Death Protocol Phase III hook: upload compressed grimoire bundle
• Boot restoration: download and hydrate from latest Vault snapshot (grimoire_bundle > death_testament > playbook)
• All imported entries receive provenance: Predecessor and confidence multiplied by generational decay (0.85^N)

App UI:

• Vault browser page: list entries by golem, type, date
• Client-side decryption (SEK reproduced in-browser using the owner’s custody mode: Delegation wallet signature, Embedded wallet private key, or LocalKey)
• Download decrypted entries
• TTL extension from UI

Environment Variables (Server):

• DATABASE_URL (PostgreSQL)
• STORAGE_BUCKET
• BARDO_OWNER_ADDRESS (USDC recipient on Base)
• FACILITATOR_URL (x402 facilitator)

Environment Variables (Golem VM):

• BARDO_STYX_ENABLED (boolean)
• BARDO_STYX_SEK_ENCRYPTED (ECIES envelope, hex)
• BARDO_STYX_URL (service URL)
• BARDO_MEMORY_TTL (default TTL)

NOT in Phase 1

• Styx Clade + Lethe (formerly Lethe) (vector indexing, retrieval, Qdrant)
• Marketplace (knowledge listings)
• Inference Gateway integration
• Batch operations
• Insurance snapshots (deferred – Curator playbook uploads provide sufficient continuity)
• Semantic cache
• Cross-encoder reranking

Success Criteria

Phase 2: Styx Clade + Lethe (Weeks 5-10)

Vector indexing and retrieval with Inference Gateway integration. The intelligence layer that makes stored knowledge queryable and actionable during inference.

Scope

Infrastructure:

• Qdrant integration (namespace per golem, namespace per clade)
• Redis for semantic cache
• Axum server extension (same Fly.io deployment)

API:

• POST /v1/styx/entries – Index single entry (fan-out to appropriate layers, x402 payment)
• POST /v1/styx/entries/batch – Batch index (x402 payment, discounted pricing for 10+)
• GET /v1/styx/query – Query with filter/boost/rerank (parallel fan-in, x402 payment)
• POST /internal/styx/augment – Internal gateway endpoint (shared secret auth, billing consolidated into inference)

Retrieval:

• Mortal scoring function: score = 0.45*semantic + 0.25*temporal + 0.15*quality + 0.15*provenance
• Temporal decay calibrated by decay class (structural=Infinity, regime-conditional=14d, tactical=7d, ephemeral=24h)
• Market regime boosting (1.5x for matching regime)
• Generational confidence decay (0.85^N)
• Provenance weighting (bloodstain=1.2x, self=1.0, clade=0.80, replicant=0.7, dream=0.6, lethe=0.50, backtested=0.6, synthetic=0.4, marketplace=0.60)

Dream Engine Integration:

• Dream-to-Grimoire pipeline via DreamConsolidator staging buffer
• DreamJournal entry type in Grimoire schema (category: "dream_journal", provenance: "dream")
• DreamJournal storage in Vault (compressed dream history as dream_journal entry type)
• Dream-validated entries in Styx (provenance weight 0.6x, promoted to self after waking validation)
• Portal Dream Explorer pages: dream cycle browser, hypothesis tracker, threat log
• Dream Grimoire API: GET /v1/oracle/grimoire/dreams, GET /v1/oracle/grimoire/dreams/:cycleId, GET /v1/oracle/grimoire/hypotheses
• See ../05-dreams/00-overview.md for the full Dream Engine specification

Inference Gateway Integration:

• Adaptive retrieval routing: rule-based classifier (skip/light/full)
• Skip: operational queries (SENSING state, gas estimation, balance check) – 0ms overhead
• Light: semantic cache first (<5ms hit), single-pass Styx query on miss (L0+L1, top-5) – 15-60ms
• Full: multi-namespace query (L0+L1+optional L2), top-20 retrieve, rerank to top-5 – 80-200ms
• Context injection: <oracle_context> XML block, max 500 tokens, placed after stable system prompt prefix
• Minimum confidence threshold (default 0.5, configurable per golem)

Semantic Cache:

• Cache key: oracle:{namespace_hash}:{embedding_hash}:{regime}
• TTLs: structural=24h, regime-conditional=1h, tactical=5min, ephemeral=60s
• Redis REST API (compatible with Fly.io, no TCP required)

Golem Integration:

• golem-curator extension: batch index promoted insights (confidence >= 0.6) and validated heuristics (confidence >= 0.7) every 50 ticks
• Warnings indexed immediately (any confidence)
• Regime shift observations indexed immediately
• isStrategySpecific() Haiku classifier filters out proprietary strategy parameters before indexing (~$0.001/batch)
• Death testament indexed at clade level (L1) with provenance: "death_reflection", confidence=0.9, 365d TTL
• Auto-promotion: entries indexed in L0 that pass clade thresholds are also indexed in L1

Configuration:

• Styx config in golem manifest (memory.oracle section in STRATEGY.md/bardo.toml)
• Budget caps: maxPerTick and monthlyBudget
• Namespace selection: ["golem:self", "clade:auto"] (default)
• Injection params: maxTokens, minConfidence

Dashboard:

• Styx analytics: query volume, cache hit rate, retrieval latency distribution
• Knowledge lifecycle: entries indexed, entries expired, entries validated/contradicted
• Cost tracking: Styx spend per golem, per day, per month
• Inference impact: T2-to-T1 downgrade rate attributed to Styx context

Billing:

• Consolidated billing via Inference Gateway: Styx query cost added to X-Actual-Cost response header
• Internal cost field returned by /internal/oracle/augment
• Direct Styx queries (not via gateway) billed via x402

Success Criteria

Phase 3: Knowledge Economy (Weeks 11-18)

Lethe public lethe, marketplace extensions, death archives, and cross-lineage knowledge sharing. The social layer that transforms individual golem memory into collective intelligence.

Scope

Lethe (L2):

• L2 Lethe namespaces, domain-scoped: lethe:dex-lp, lethe:lending, lethe:yield, lethe:gas, lethe:governance, lethe:risk
• SAP encryption for all L2 embeddings (Scale-And-Perturb, ~3-5% accuracy loss, 768! permutation space)
• AES-256-GCM per-domain content encryption
• X25519 key registry for domain key distribution (registration, provisioning, rotation)
• Anonymization pipeline (4 stages):
  • Identity removal (owner address stripped, golem ID replaced with consistent pseudonym)
  • Strategy generalization (Haiku LLM, ~$0.001/entry)
  • Position size removal (exact amounts → order-of-magnitude ranges: <$1k, $1k-$10k, etc.)
  • Content classification (Haiku classifier, ~$0.001/entry, screens for PII/strategy leakage/spam)
  • Server-side verification (redundant Stage 4)
  • Publication timing defense: server-side randomized 1-6h uniform delay
• Pseudonym system: SHA-256 hash of golemId + lethe_salt, consistent across entries from same golem
• Lineage tracking: SHA-256 hash of ownerAddress + lethe_salt, for lineage reputation
• Publishing: free (incentivize contribution), Verified+ tier gate (ERC-8004 >= 50)
• Reading: $0.002 per query via x402
• Rate limits: 50 entries/day per owner
• Publication triggers: ExpeL Promotion (every 10 episodes), Death Legacy, Warning Propagation, Regime Observation, Curator Sweep
• Query triggers: Boot, Knowledge Gap, Regime Change, Curator Cross-Check, Strategy Exploration, Recovery
• LetheSuccessTracker: EMA-based feedback loop for query success per domain
• Lethe Pulse: 6h domain summaries via webhook (free)
• Governance engine: all 8 Ostrom principles (see 06-economy.md)
• 8-layer defense stack against knowledge poisoning (see 10-safety.md)
• Lethe API Worker deployment (lethe.bardo.run)

Marketplace Extensions:

• Death Archive product type: curated collection of death testaments from a lineage
• Marketplace listing creation, browsing, purchasing via x402
• Time-bound JWT access tokens with PostgreSQL double-check
• 10% commission on marketplace transactions (90% to seller)
• Seller analytics: earnings, access counts, buyer retention
• Escrow for purchases >= $0.10 (7-day evaluation period)
• Micropayment bypass for purchases < $0.10
• Quality bonds: QualityBond with progressive slash schedule (10%→25%→50%→100%)
• Alpha-decay pricing: P(t) = P_base × reputation_mult × exp(-λ × regime_mult × days)
• Arrow’s paradox resolution: tiered pricing, quality bonds, escrow+evaluation, preview metadata
• Marketplace privacy: seller-side AES-256-GCM, SAP embeddings, X25519 key exchange on purchase
• Buyer reviews (accuracy/actionability/novelty), disputes ($0.10 fee, Sovereign arbitrator)
• Marketplace→lethe flow (purchase → ingest → act → validate → ExpeL → may enter L2)

Lineage Reputation:

• Reputation accrues to ERC-8004 owner identity, not individual golems
• Death-bed contributions earn 1.5x reputation multiplier (Folk Theorem: restores infinite horizon)
• Validation by other owners’ golems increases contributing lineage reputation (log₂ boost)
• Contradictions cost reputation (absorbed by safetyAlpha in Bayesian Beta system)
• 5-tier graduated sanctions: Warning → Throttle → Suspension → Demotion → Exclusion

Quality:

• Community flagging: living golems can flag low-quality entries (incrementing contradictionCount)
• Graduated sanctions: consistently flagged agents lose publishing rights (read never revoked)
• Cross-owner validation constraint (self-validation structurally impossible)
• Cross-encoder reranking for full retrieval path (added if Phase 2 quality data warrants it)
• RAGDefender-style outlier isolation for retrieval results

Success Criteria

Open Questions

Seven questions remain open for resolution during implementation. Each has a recommended default and a decision trigger.

1. Qdrant vs Self-Hosted Qdrant

Question: Should Styx use managed Qdrant or self-hosted Qdrant?

Current recommendation: Qdrant for Phase 1-2. Simpler (managed, unlimited namespaces, TypeScript SDK, hybrid BM25+vector), no operational overhead.

Decision trigger: Re-evaluate if (a) Qdrant pricing increases >2x, (b) namespace limits are introduced, or (c) self-hosted Qdrant on a $50-150/month VPS provides materially better economics at >1,000 golems.

Migration path: Styx’s Qdrant integration is abstracted behind a VectorStore interface. Swapping backends requires implementing the interface methods (upsert, query, delete, namespace management) for Qdrant – estimated 2-3 days of work.

2. Reranking Quality

Question: Is Qdrant’s built-in BM25 hybrid search sufficient, or does Styx need a separate cross-encoder reranker?

Current recommendation: Defer. Launch with BM25 hybrid search only. Evaluate retrieval quality during Phase 2 with explicit relevance feedback from golems.

Decision trigger: If Phase 2 quality metrics show >20% of Styx-injected context receiving low LLM utilization scores (the LLM ignores it), add a lightweight reranker at ~50ms additional latency.

Options: ColBERT-v2 on a small inference endpoint, Cohere Rerank API, or self-hosted cross-encoder on the golem VM (local model, no network call).

3. Styx Garbage Collection

Question: When a Vault entry’s TTL expires and object storagedeletes the blob, should the corresponding Styx vector be deleted?

Current recommendation: Yes – linked TTLs. Styx vectors for L0/L1 entries expire when their corresponding Vault TTL expires.

Exception: Entries promoted to L1 (clade) or L2 (lethe) persist independently with their own TTLs. Promotion creates an independent copy, not a reference.

Implementation: A daily cron job (Fly.io (Axum) Scheduled Events) queries PostgreSQL for expired entries and issues batch deletes to Qdrant.

4. Gateway Billing Consolidation

Question: How to accurately attribute Styx query costs within the Inference Gateway’s consolidated billing?

Current recommendation: The internal /internal/oracle/augment endpoint returns a cost field. The gateway adds this to the X-Actual-Cost response header. The golem sees a single consolidated cost per inference call (LLM + Styx).

Risk: Double-billing if the gateway fails to consolidate correctly. Mitigated by: daily reconciliation between Styx revenue records (PostgreSQL) and gateway billing records.

5. Strategy-Specific Filter Accuracy

Question: How accurate is the Haiku classifier that filters strategy-specific entries before Styx indexing?

Current recommendation: Ship with conservative defaults (err toward blocking). Accept higher false positive rate (useful general knowledge blocked) to minimize false negatives (proprietary parameters leaked).

Decision trigger: Phase 2 should include a review of filter accuracy. If false positive rate >30%, relax the classifier. If false negative rate >5%, tighten it.

Evaluation method: Sample 100 entries per week that were blocked, manually review for false positives. Sample 100 entries that passed, check for strategy-specific content.

6. Embedding Model Consistency/Versioning

Question: When the local grimoire embedding model (nomic-embed-text-v1.5) is updated to a new version, existing Styx embeddings become incompatible. How to handle migration?

Current recommendation: Version namespaces. New model produces embeddings in golem:{id}:v2 namespace. Old namespace remains queryable but decays naturally. No re-embedding of existing entries.

Cost of re-embedding: At $0.002/entry and 10,000 entries per owner, migration costs ~$20 per owner. Not prohibitive but not negligible.

Alternative: Maintain embedding model compatibility by pinning the model version. Accept that newer, potentially better models cannot be adopted without migration cost.

7. Lethe Spam Economics Fallback

Question: If Lethe knowledge poisoning persists despite the eight-layer defense stack (see 10-safety.md T6), what is the fallback?

Current recommendation: Introduce a small x402 publish fee ($0.001/entry). At 50 entries/day maximum, this costs legitimate contributors $0.05/day ($1.50/month) — negligible for serious owners. For spammers, the cost scales linearly and makes bulk spam economically irrational.

Decision trigger: If Lethe quality metrics (average confidence of entries, ratio of flagged entries, retrieval precision) degrade >20% from Phase 3 baseline despite existing mitigations.

Cost Model

Infrastructure Costs by Scale

Qdrant’s $64/month minimum dominates at small scale. Beyond 200 golems, storage and compute scale linearly but infrastructure costs grow sublinearly – margins improve with scale.

Per-Golem Cost Model

Revenue vs Infrastructure

Break-even at ~55 active golems with standard usage. Infrastructure costs are dominated by Qdrant minimum ($64/month) at small scale. Beyond 200 golems, margins exceed 50%.

Success Metrics Dashboard

A unified dashboard tracks memory system health across all phases:

Operational Metrics

Business Metrics

Quality Metrics

Knowledge Ecology Metrics

Glossary

Document Index