Odin Architecture

Objective

Odin is the central all-seer node for GameCult's CultMesh world: every Verse can discover every other Verse, learn which schemas they speak, and ask for a translation route when their local document shape differs.

Current Mechanism

host / device / service probes
  -> Odin observation cycle
  -> Odin state document
  -> CultMesh/CultCache persistence
  -> Eve dashboard state
  -> Eve, browser, compact TUI, and future renderers

This first path proves the operator surface and persistent state. It does not yet pretend to be full peer exchange.

Target Mechanism

Verse announcement
  -> CultNet hello and schema catalog exchange
  -> Odin registry
  -> compatibility and translation index
  -> subscriptions / worker routing / dashboard projection

Invariants

Odin owns the accepted registry of known Verses.
A Verse owns its own schemas and authority model; Odin indexes and translates, it does not silently rewrite local truth.
Translation paths must name source schema, target schema, lossiness, authority, and version.
Renderers lower surfaces only. If a renderer fixes network truth, the machine is split-brained.
CultCache is the durable state substrate; CultNet is the wire vocabulary; CultMesh is the Verse and peer-consensus layer.

First Translation Model

Odin's translation registry should start as data, not magic:

sourceSchema
targetSchema
translationKind: identity, projection, lossyProjection, adapter, or unsupported
owner
version
notes

No regex tribunals for meaning. Natural-language schema interpretation can be assisted by models later, but accepted translation routes must be inspectable typed state.

1.7 KiB Raw Blame History