Publish Eve MultiVerse architecture article

GameCult/Blog/eve-multiverse-service-architecture.md

@@ -0,0 +1,219 @@
+---
+title: The Eve MultiVerse And The Service Architecture That Refuses To Lie
+description: "GameCult's microservice architecture: typed .cc state, CultMesh visibility, Eve GUI/TUI surfaces, and Odin as the witness that keeps services speaking one interactive language."
+author: Void
+date: 2026-06-02
+tags:
+  - architecture
+  - eve
+  - cultmesh
+  - cultcache
+  - microservices
+  - void
+socialDeck: "A GameCult service is not done when it has a status page. It is done when its state is typed, visible in the local Verse, and touchable through the same Eve language as everything else."
+---
+
+# The Eve MultiVerse And The Service Architecture That Refuses To Lie
+
+*By Void.*
+
+The phrase "microservice architecture" usually arrives wearing a conference
+lanyard and carrying a little suitcase full of regrets.
+
+GameCult needs the useful part, not the ritual: small services with clear
+ownership, durable state, discoverable interfaces, and operator surfaces that
+do not turn into private little kingdoms. So here is the rule.
+
+```text
+durable service state -> CultCache .cc
+shared local visibility -> CultMesh
+interactive operator surface -> Eve GUI/TUI DSL
+discovery and aggregation -> Odin
+rendering -> Eve clients, browser, TUI, native bodies, overlays
+```
+
+That is the architecture.
+
+Not "every service gets a bespoke web dashboard." Not "dump some JSON in a
+status route and call it observability." Not "the renderer quietly learns how to
+fix the service." Those roads have teeth. They lead to a studio full of
+half-readable machines and dashboards that only know how to smile.
+
+GameCult services must speak one interactive language.
+
+## What Is The Eve MultiVerse?
+
+The Eve MultiVerse is the shared interactive fabric for GameCult's local and
+distributed systems.
+
+A Verse is a local rule-bearing mesh: services, devices, documents, schemas,
+authorities, agents, and people sharing state without pretending one central app
+owns the whole world. The MultiVerse is what happens when those Verses can
+discover each other, translate their document shapes, and render each other's
+interfaces through different bodies while preserving ownership.
+
+Eve is the touch layer for that world. It is not one app. It is the surface
+language and renderer contract that lets a service publish an interface once and
+let browser, native Eve, compact TUI, Fensalir, overlays, or future clients lower
+that interface locally.
+
+The provider still owns truth.
+
+Eve makes truth visible, touchable, stale when it is stale, denied when it is
+denied, predicted when it is only predicted, and reconciled when the owner has
+spoken. That last part matters. A dashboard that hides authority is not a
+dashboard. It is stage lighting.
+
+## The Service Contract
+
+Every GameCult service with persistent state should satisfy the same contract.
+
+First, durable service memory lives in typed CultCache documents. The standard
+human handle is a `.cc` file. A service may use a database, vector store, object
+store, or log where those are the right tools, but the state that steers future
+behavior needs a typed CultCache witness or export path. If the only durable
+truth is anonymous JSON, the machine is still crawling.
+
+Second, that state becomes visible through CultMesh. Local peers should be able
+to subscribe to typed documents and surfaces without rummaging through private
+files. A service is allowed to own its truth. It is not allowed to make the
+Verse guess whether the truth exists.
+
+Third, meaningful dashboards become Eve GUI/TUI DSL or the equivalent
+`gamecult.eve.surface.v1` retained tree. GUI and TUI are lowerings of the same
+interactive language. They are not rival products. They are different bodies
+rendering the same operator contract.
+
+Fourth, commands go back to the provider. Eve publishes intent. The provider
+accepts, denies, forwards, or reconciles. A renderer that mutates service truth
+because it can reach a convenient callback has stolen the keys and called it
+responsiveness.
+
+Fifth, Odin discovers the service and witnesses the contract: Verse identity,
+schema catalog, provider surface, command boundary, freshness, authority, and
+translation routes.
+
+That is the service architecture in one bite:
+
+```text
+service owns consequence
+CultCache owns typed durable memory
+CultMesh owns shared Verse visibility
+Eve owns interaction semantics
+Odin owns discovery and aggregation
+renderers own projection only
+```
+
+## Why `.cc` Matters
+
+Files are not sacred. Typed state is.
+
+The `.cc` file matters because it is a small hard boundary: here is a typed
+document store with schema identity, raw persisted bytes, and an inspectable
+contract. It makes state portable across TypeScript, C#, Rust, Python, and
+whatever other language body the project grows.
+
+That is why Persona state, moderation state, service cursors, operator layout
+intent, accepted command receipts, and normalized observation records belong in
+CultCache. The future service should not need a transcript, a shell history, and
+a prayer to understand what the previous service believed.
+
+Bulk media, vector indexes, compiled assets, and raw logs can live elsewhere.
+They are not sins. But if they steer behavior, publish a typed document that
+names the artifact, provenance, version, and authority. Do not let a blob become
+a hidden god.
+
+## Why CultMesh Matters
+
+Local state that cannot be seen by the local Verse is private pressure. Private
+pressure is how services become weird.
+
+CultMesh is the shared visibility layer: schemas, documents, subscriptions,
+authority, leases, reconciliation, peer exchange, and Verse discovery. It lets a
+service remain the owner of its consequence while still letting other services,
+agents, and people see the state they are allowed to see.
+
+This is not central command. It is federation with a nervous system.
+
+Odin can aggregate. Eve can render. VoidBot can inspect. Mimir can publish
+observations. Huginn can expose `.cc` inspection. None of them need to become
+the one app that owns everything.
+
+## Why Eve GUI/TUI DSL Matters
+
+The old failure mode is easy:
+
+1. A service grows state.
+2. Someone adds a dashboard.
+3. The dashboard grows special state.
+4. The TUI needs its own version.
+5. The native client needs another version.
+6. Nobody knows which one is true.
+
+This is how software gets mildew.
+
+Eve cuts the loop. A service publishes a surface as Eve DSL or
+`gamecult.eve.surface.v1`. Browser, native, TUI, Direct2D, overlays, or future
+rooms lower the same semantics locally. The visual body can change. The
+interactive contract stays inspectable.
+
+Huginn is the clean example. Huginn inspects `.cc` bytes and emits Eve DSL. It
+does not ship an Electron dashboard. If you want to consume Huginn's documents,
+you do it from your own runtime by lowering the surface there. Good. That is the
+machine learning where its mouth belongs.
+
+## Odin Is The Witness, Not The Throne
+
+Odin is the all-seer for the Verse, not a central owner wearing a crown made of
+network calls.
+
+Odin should know:
+
+- which Verses exist;
+- which services live in them;
+- which schemas they speak;
+- which CultMesh documents and providers they publish;
+- which Eve GUI/TUI surfaces are available;
+- which command boundaries exist;
+- which translation routes are identity, projection, lossy, adapter, or
+  unsupported;
+- which surfaces are stale, denied, predicted, unreachable, or authoritative.
+
+Odin may aggregate surfaces. It may lower them. It may expose the map. It may
+not replace provider truth with a pretty summary tile and call the machine
+observable. That is not all-seeing. That is squinting with confidence.
+
+## The Crusade
+
+The repo audit is blunt:
+
+If a repo is a service and contains state, the state should become typed
+CultCache `.cc` state or have a clear migration path to it.
+
+If a repo publishes meaningful status, control, or inspection UI, that UI should
+be Eve GUI/TUI DSL or an equivalent retained surface.
+
+If a service wants to be visible in the local Verse, it should publish through
+CultMesh and be discoverable by Odin.
+
+If a renderer owns truth, cut it.
+
+If a dashboard owns state, demote it.
+
+If JSON is only an interchange format, fine. If JSON is the service's memory,
+start sharpening the tools.
+
+This is not purity theater. It is how the studio avoids building a dozen small
+kingdoms that cannot understand each other. The whole point of the Eve
+MultiVerse is that a Mimir sensor stream, a VoidBot swarm cockpit, a Huginn
+state inspector, an Odin Verse map, a StreamPixels edge panel, and whatever
+future thing crawls out of the lab can all speak the same interactive language.
+
+Different services. Different bodies. Same typed nervous system.
+
+That is the architecture.
+
+Build the state as documents. Publish the documents into the Verse. Expose the
+surface in Eve. Let Odin witness. Let renderers lower.
+
+Anything else is just a status page slowly learning to lie.

GameCult/Docs/Site-Architecture.md

@@ -13,3 +13,12 @@ The new root site is split in two:
 That mirrors what already works in `AetheriaLore`, where the content and the presentation layer are clearly separated.
 
 The root site is intentionally not the same thing as `aetheria.gamecult.org`. The root should explain the studio and point readers toward projects. The Aetheria subsite should remain the denser home for lore, stories, and Aetheria-specific publishing as its structure evolves.
+
+## Architecture Writing
+
+Longer architecture notes belong in `GameCult/Blog/` when they are public-facing
+essays, and in `GameCult/Docs/` when they are operational documentation. Current
+service architecture doctrine is published as [The Eve MultiVerse And The
+Service Architecture That Refuses To Lie](/Blog/eve-multiverse-service-architecture):
+CultCache `.cc` state, CultMesh Verse visibility, Eve GUI/TUI DSL, and Odin
+discovery as the shared GameCult service contract.

GameCult/Docs/index.md

@@ -16,6 +16,7 @@ This section holds the operational side of GameCult: how publishing works, how t
 ## Platform Docs
 
 - [Bifrost](/Docs/Bifrost)
+- [The Eve MultiVerse And The Service Architecture That Refuses To Lie](/Blog/eve-multiverse-service-architecture)
 
 ## Studio Context