Platform phases
The underlying technology, grouped by purpose. A swimlane is a product surface, not an internal team.
Foundations
Identity, Qubic, Compute, Gateway, Billing, ANN, Marketplace, Tissue, Dataset, Economy. The platform runs.
Training orchestrator, dataset connectors, retraining, A/B shadow deployment.
Intelligence
Trinary protocol v1. 8-ANN coordinator for material discovery. Phase 1 re-evaluation gate.
5 consensus policies. Signed IntentEnvelopes. 5 training recipes. Auto-publish to ANN.
Economy
AigarthPool (30/60/10), multi-sig treasury, pre-mainnet gates, hardware presale.
Evolution
The Aigarth evolution proposal. Approved August 12.
Mutable genome, lineage, memory, fitness. Garden view + marketplace listing.
5 new tables, 13 routes, 4-tier compute, replication + challenge + reputation verification.
Federation
Workers that live in your data center, your laptop, or a partner's network. Cross-deployment reputation.
The Qubic on-chain processor reads Organism work items and commits 451-of-676 computor signatures.
Future
The scheduler becomes an economic allocator, balancing cost, latency, and reputation.
The Neuraxon runtime as a backend for the Trinary envelope. Contingent on Neuraxon shipping.
Hardware timeline
The product form factor, from edge to cluster.
Aigarth Seed
Edge developer device. Pre-orders open.
Aigarth Grove
Workstation node for studios.
Aigarth Forest
Rack-scale inference appliance.
Aigarth Atlas
Portable inference device.
Aigarth Canopy
Enterprise AI cluster.
Federated inference
Cross-region model parallelism.
Shipping now
What landed in Q3 2026, and what is on deck.
The Aigarth evolution
The Organism primitive and the Work Runtime. Three ADRs (Organism, Work Runtime, OC processor) plus 60+ new test cases. Twelve services in production.
- 5 new tables (work_items, workers, work_results, worker_challenges, work_audit)
- 13 new routes, 4-tier compute model, replication + challenge + reputation verification
- Organism marketplace listing, Garden Organism view, billing hook
Federated workers
Workers that run in your own environment, on a partner's network, or on a peer device. Cross-deployment reputation is the open question: how does a worker's standing in one network translate to another?
- gRPC + HTTP federated worker protocol
- Worker manifest signed by the local deployment
- Per-deployment reputation with cross-deployment decay
Open questions
Hard things we are not pretending to have answered.
When do we move from replication + challenge + reputation to TEE or ZK? By volume, by value, by adversarial rate, or by a manual decision? The trigger changes the guarantee behind the "verified" label, so it matters.
When all three replicas disagree, who decides who is right? A deterministic re-run on a high-reputation worker, manual admin review, or a refund to the payer? Without a default, disputed work items never settle.