Architecture deep-dives.

Sora Multi-Device Orchestration

Sora is the Neo Genesis fleet AI assistant. It runs as a single Python process on ysh-server (16-core / 16 GiB), backed by Redis for the inter-device message queue and Tailscale for the encrypted private mesh. Sora orchestrates six devices: ysh-server (orchestrator + Telegram bot host), desktop-sol01 (GPU worker — Ollama, ComfyUI, local embedding services), mx-mac-studio (Apple build node and BGE reranker host), desktop-yesol (company work PC, execution-plane only), and two mobile clients — S26 Ultra (primary approval surface) and Tab S10 Ultra (dashboard). Each device carries a tier label (personal-root, gpu-worker, company-work-pc, server, team-mac, mobile-operator) that constrains what kinds of actions Sora may take from that device.

The control flow follows a Magentic-One Dual Ledger pattern adapted from Microsoft Research. Every Sora session writes a Task Ledger (intent, plan, assumptions) and a Progress Ledger (tool calls, outcomes, reflective notes) to .agent/shared-brain/. This means any agent that resumes the session — Claude Code, Codex, Gemini, or Sora itself — can replay the context without ambient memory drift, which is the failure mode that kills most multi-agent setups in production.

Around every tool call Sora runs the four-stage Disclose-and-Confirm Pipeline: SessionStart loads the active permission policy and Capability Token, UserPromptSubmit classifies intent against an allowlist, PreToolUse evaluates the target tool’s Blast Radius (tier 0-5) and emits a DisclosureBundle, and PostToolUse writes the result back to the Progress Ledger. The hook code lives in src/core/hooks/; the policy YAML lives in .agent/policies/. Anything tier-2 or above is owner-gated regardless of which subagent issued the call.

The full operational dataset — six-device topology, hook flow, tier matrix, and a sample session — is published as a CC-BY-4.0 dataset on Hugging Face: sora-multi-device-orchestration-2026. The architecture article on the Data Hub goes deeper on failure modes: Sora Orchestration Architecture.

HIVE MIND Content Pipeline

HIVE MIND is the seven-stage autonomous content pipeline that powers every Neo Genesis SBU. The stages — Sense (signals from Search Console, GA4, PostHog), Think (topic and intent planning), Create (drafting via the active LLM router), Quality (V-Score gating at 184.5), Ship (Vercel build + IndexNow ping), Learn (post-ship telemetry capture), and Refresh (re-evaluation of content older than 90 days) — run as independent agent personas that hand off through the Magentic Dual Ledger described above.

The Quality stage is the only stage that can block publication. V-Score combines six sub-metrics: fact density per 500 words, EEAT score, citation count to authoritative external sources, originality (semantic distance from the existing web corpus), Schema.org coverage, and freshness decay. Anything below 184.5 is rejected and routed back to Create with the failing sub-metric labelled. In practice, V-Score gating is the single biggest reason a 1-person company can run eight LIVE SBUs without producing detectable workslop.

The same pipeline drives all eight active SBUs (UR WRONG, ToolPick, AIForge, FinStack, SellKit, CraftDesk, DeployStack, ReviewLab) plus the company landing site at neogenesis.app. Pipeline source is in src/sbu/<name>/hive_mind/; the V-Score implementation lives in the shared src/lib/quality/ module so changes to the threshold propagate atomically. Companion blog post: Inside HIVE MIND.

Schema.org Citation Chain Pattern

The Schema.org Citation Chain is the bidirectional cross-reference pattern Neo Genesis emits across every public surface so that AI search engines can traverse the entity graph and quote any node back to its canonical source. The chain spans nine Schema.org types: Organization, Person, SoftwareApplication, Dataset, ScholarlyArticle, TechArticle, DefinedTerm, HowTo, and FAQPage.

Every node carries three cross-link properties: @id (a globally unique fragment-anchored URL), sameAs (links to Wikidata Q-IDs, HuggingFace dataset URLs, Zenodo DOIs, OpenAlex author IDs, and GitHub repositories), and subjectOf or about (link to the canonical describer page on neogenesis.app). The result is that an AI search engine resolving “Yesol Heo founder of Neo Genesis” can follow Person@id → worksFor Organization → hasOfferCatalog OfferCatalog → 11 SoftwareApplication nodes → 9 sameAs Zenodo DOIs in a single graph traversal.

Implementation is straightforward but disciplined. Every page-level Schema lives as an inline application/ld+json script tag in the route’s page.tsx; entity-level Organization, WebSite, and dataset Schemas live in app/layout.tsx so they appear on every page. The shared SITE_META module in src/lib/data/sbus.ts is the SSOT for canonical URLs and IDs; this prevents drift between the Organization Schema in layout.tsx and the per-route Schema fragments. The 13 Wikidata Q-IDs (Q139569680 plus the founder and 11 SBUs) anchor the graph against an external authority that AI engines already index.