Dependency-gated delivery roadmap

Appendix D Dependency-gated delivery roadmap This appendix states the delivery stack in dependency order: each row assumes the rows above it are already shipped. The substance is dependency-gated execution—parallel work is allowed wherever the graph permits; the constraint is that downstream claims (especially settlement, identity, and verification) should not run ahead of their prerequisites. Chapter 16 remains the narrative roadmap; Chapter 17 is the short reader’s map; here the same commitments appear as checklists with explicit predecessors. Delivered rows reflect the production ScryptedAI API and workers as described elsewhere in this document; next rows are phased so that nothing is treated as credible for external messaging until its dependencies are satisfied. D.1 How to read this appendix • Dependency gate. A deliverable may not begin until every dependency in its Depends on column is complete (for engineering work) or explicitly waived by governance (not expected for safety or settlement-critical paths). • IDs. D-n labels the shipped stack in dependency order. N-n labels upcoming work; phase letters (NA, NB, … ) group items that can run in parallel within a phase only if they do not depend on each other. • Traceability. Primary chapter references point to the design intent; the authoritative state of code is the repository and deployed services. D.2 Delivered stack (dependency order) The following items are shipped in the sense used in Chapter 16, §16.1: they are live on the production path unless a chapter explicitly calls out a gap (e.g. app-level rate limiting). ID Deliverable What it is Depends on D-01 Registry schema Ingredients, recipes, versions; typed interfaces — D-02 Job and account model Durable jobs, accounts, correlation keys D-01 D-03 Shadow graph JobExecutionState, DAG steps, atomic step transitions D-02 D-04 RecipeExecutorV2 DAG resolution, ready-step dispatch, crash recovery D-03 D-05 Celery + Redis broker Async workers, task routing, retries D-04 D-06 External completion (dual path) Webhook + polling convergence; collisionsafe completion D-04, D-05 136

ID Deliverable What it is Depends on D-07 Multi-provider adapters Heterogeneous upstream APIs; normalized errors and results D-05 D-08 Asset pipeline S3 storage, CloudFront delivery, retention tiers D-02 D-09 SCRYPTOSHI ledger Double-entry accounting, cost models, reconciliation D-02 D-10 x402 settlement path HTTP 402 challenge/response; facilitator registry (e.g. Coinbase/Base) D-09 D-11 Bearer token auth Permissionless API keys; hashed at rest; billing correlation D-02 D-12 Content moderation Pre-flight binding, two-stage assessment, guardrails D-01, D-07 D-13 ConcurrencyManager Redis slot limits per provider (single-cell deployment) D-05 D-14 Fault-tolerance layers Pool health, app/ingredient/task retry taxonomy D-04–D-07 D-15 SSE job stream GET /jobs/stream via Redis pub/sub D-05 D-16 HTTP API surface FastAPI, OpenAPI, route families (recipes, jobs, generate, webhooks) D-01–D-15 Inventory note. The live registry scale cited in Chapter 16 (e.g. ingredient and recipe counts) sits on top of D-01 and D-16. First-party applications (e.g. Delula) validate D-04–D-15 under consumer load; they do not replace on-chain registration or CRPC, which are not included above. D.3 Next work: phased dependency gates Each phase is gated: all dependencies listed under the phase header must be satisfied before the phase is declared complete. Items within a phase may be parallelized only when their pairwise Depends on cells do not create a cycle. Phases NB and beyond are gated progressions: CRPC, committees, EigenLayer-class staking, and advanced autonomy are commitments tied to prerequisites, not implied inevitabilities. Phase NA — Identity, packaging, and policy closure ID Deliverable Depends on N-01 ERC-8004 mapping for registered agents (metadata, reputation/validation hooks) D-01, D-16 N-02 AVB repository and avb.json living standard (Agent0 SDK, execution interfaces) D-01, N-01 (identity hooks strongly preferred) N-03 Multi-facilitator x402 (additional facilitators; selfhosted option; MPP/Stripe-class clients per economics chapter) D-10 N-04 Account-scoped job cancellation (API + cooperative worker + optional Celery revoke) D-04, D-16 N-05 App-level rate limiting (wire configured limits into FastAPI middleware/deps) D-16 Phase gate NA. N-01 and N-05 complete, and N-03 or an explicit waiver for settlement scope, before Phase NB is treated as unlocked for economics that touch placement or reputation. 137

Phase NB — Verifiable workloads (testnet) ID Deliverable Depends on N-06 CRPC testnet harness for output-based verification (LoRA milestones, simulation/eval sets) D-04, D-16 N-07 Committee operations (coordinator-assigned committees; ring topology; manual ε calibration) N-06 N-08 Ephemeral Rollups / Solana committee comms pilot (exploratory; MagicBlock-class substrate) N-07 N-09 Ethereum/EigenLayer staking layer for node commitments (as per verification chapter) N-07, N-01 Phase gate NB. At least one end-to-end N-07 round trip with documented artifacts; N-08 and N-09 may trail as parallel workstreams but do not block the first public testnet narrative if N-07 stands alone. Phase NC — Matchmaking, quality learning, and Open Intents ID Deliverable Depends on N-10 AgentRank in Open Intents resolution ( Bid × AgentQuality; GSP or MVP pricing) N-01, D-16 N-11 Automated quality learning (feedback signals, Thompson/EMA or agreed alternative) production-hardened D-07, N-10 (reputation channel) N-12 Open Intents expansion (materialized routes, MCP/A2A/ACP/UCP normalization as committed) D-16, N-10 N-13 Path-aware reputation (Rterminal vs Rhub, delegation disclosure, Dmax) N-01, N-10 Phase gate NC. N-10 live in shadow or production routing; N-11 fed by at least one production signal (e.g. fulfillment quality + user feedback) before attention-auction revenue claims are marketed. Phase ND — Decentralized execution and interoperability ID Deliverable Depends on N-14 AVS slashing predicates tied to CRPC dispute artifacts (docs + pilot) N-07, N-09 N-15 Verified-tier routing (EigenCompute-class or equivalent attestations) for selected steps N-14, D-07 N-16 DA/commitment posts (e.g. EigenDA) where cost/latency beat naive L1 N-14 N-17 Cross-chain settlement and liquid pools (EIL, Wire Network, rail integrations per economics chapter) N-03, D-10 N-18 Federated or shared Redis coordination; job-home routing for multi-region cells D-13, D-05 Phase gate ND. N-14 defined and reviewable; N-15 optional per-SKU before general marketplace claims. 138

Phase NE — Applications and ecosystem ID Deliverable Depends on N-19 Sidelines: prediction windows, leaderboard, LoRA + CRPC receipts N-06, N-07 N-20 Sidelines open science (Hugging Face / Kaggle with provenance) N-19 N-21 Chibi Clash and game-trained ingredients (world-model thesis) D-01, D-07 N-22 Framework integrations (OpenClaw, ElizaOS, DayDreams, MCP bidirectional) D-16, N-12 (preferred) Phase gate NE. Product launches may start once their row dependencies hold; N-21 does not require Phase NB if only centralized inference is used, but CRPC claims require N-07. Phase NF — Advanced verification and autonomy ID Deliverable Depends on N-23 VRF-based ephemeral committees; on-chain dispute arbitration N-07, N-09 N-24 CRPC × reinforcement learning (verified outputs drive routing policy) N-11, N-07 N-25 World-model integration (Stratus-class or proprietary; latent planning) D-07, N-21 (optional accelerator) N-26 zkML and ERC-8004 zkml-proof profile integration N-01, N-14 N-27 IPFS or content-addressed storage with pinning economics resolved D-08, N-01 Phase gate NF. Research-grade until N-23 and N-26 predicates are fixed; not required for initial mainnet positioning unless a product line explicitly promises zkML or VRF committees. D.4 Dependency sketch (phase on phase) One-line dependency order between phases (parallelism allowed where the graph permits): D-* → NA → NB → NC ∥ NE(partial) → ND → NF, where NE partially overlaps NB–NC for application work that does not assert on-chain verification. Chapter 16, §16.7 lists blocking research questions; any item above that touches token governance, EU AI Act classification, or mandatory reporting must not ship public claims until the corresponding open question is resolved. D.5 Maintenance When a deliverable ships, promote it from N-n to a new D-n row in §D.2 and remove it from the phase tables in the next document revision, adjusting downstream Depends on references if IDs change. 139

Source: transcribed from the compiled Scrypted Network Design whitepaper PDF for web reading. Layout, figures, and pagination may differ from the PDF.