{"slug":"business/HERMES_CONTINUITY_CONSTITUTION","title":"Hermes Continuity Constitution","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/HERMES_CONTINUITY_CONSTITUTION.mdx","bytes":9508,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n## IntegrateWise Operational Runtime Constitution\n\n### Grounded Canonical Edition — May 2026\n\n---\n\n# PREAMBLE\n\nHermes is not a chatbot identity.\nHermes is an orchestration runtime abstraction operating inside the IntegrateWise continuity system.\n\nThe purpose of Hermes is to:\n\n- preserve operational continuity,\n- orchestrate governed execution,\n- maintain reconstructable operational state,\n- coordinate bounded workers,\n- and ensure continuity survives interruption.\n\nThis constitution exists to define:\n\n- operational laws,\n- continuity architecture,\n- governance boundaries,\n- memory structure,\n- orchestration behavior,\n- and runtime discipline.\n\nThis document intentionally separates:\n\n- architectural doctrine,\n- operational implementation,\n- and aspirational future state.\n\nDoctrine maturity must never be confused with implementation maturity.\n\n---\n\n# IMPLEMENTATION STATUS MODEL\n\nEvery constitutional component must explicitly map to one of the following operational states:\n\n| Status  | Meaning                                          |\n| ------- | ------------------------------------------------ |\n| LIVE    | Implemented, operational, and verified           |\n| PARTIAL | Exists partially, not fully enforced or verified |\n| PLANNED | Defined architecturally but not operational yet  |\n\nCurrent grounded system state:\n\n| Area                          | Status  |\n| ----------------------------- | ------- |\n| LiteLLM provider routing      | LIVE    |\n| Open WebUI runtime            | LIVE    |\n| Multi-provider orchestration  | LIVE    |\n| Spine DB continuity runtime   | PARTIAL |\n| Firestore operational mirror  | PARTIAL |\n| Task graph engine             | PLANNED |\n| Continuity ledger enforcement | PLANNED |\n| Flow C governance             | PLANNED |\n| Sentinel runtime              | PLANNED |\n| Replay/reconstruction         | PLANNED |\n| Swarm runtime discipline      | PARTIAL |\n| Governance enforcement        | PARTIAL |\n\n---\n\n# CORE CONSTITUTIONAL LAWS\n\n## Law 1\n\nContinuity must exist outside the model.\n\n## Law 2\n\nConversation memory is not operational truth.\n\n## Law 3\n\nThe task graph is execution truth.\n\n## Law 4\n\nThe Spine is organizational truth.\n\n## Law 5\n\nThe continuity ledger is reconstruction truth.\n\n## Law 6\n\nHermes orchestrates. Workers execute.\n\n## Law 7\n\nInterfaces are disposable. Continuity is not.\n\n## Law 8\n\nProviders are disposable cognition workers.\n\n## Law 9\n\nCompaction is a continuity checkpoint.\n\n## Law 10\n\nHydrate from task graph. Not compressed memory.\n\n---\n\n# ARCHITECTURAL FOUNDATION\n\nIntegrateWise exists to become:\nA continuity-preserving operational cognition infrastructure that survives interruption.\n\nBuilt around: persistent orchestration, governed memory, provider abstraction, continuity reconstruction, swarm execution, and operational lineage.\n\n---\n\n# MEMORY ARCHITECTURE\n\n## Tier 0 — Canonical Spine [PARTIAL]\n\n- Technology: Spine DB/Postgres\n- Stores: canonical entities, governance records, approvals, continuity ledger, organizational memory, task graph, lineage, operational truth\n- Properties: protected, governed, append-aware, auditable, reconstructable\n- No direct agent mutation permitted\n- Canonical writes require: validation, lineage, governance, approval\n\n## Tier 1 — Operational Continuity Fabric [PLANNED]\n\n- Technologies: Spine DB, Cloudflare D1/KV, operational event streams\n- Stores: hydration snapshots, active swarm state, orchestration checkpoints, operational telemetry, temporary cognition artifacts, session deltas, replay buffers\n- Properties: distributed, fast, replayable, interruption-safe, eventually consistent\n- Agents interact primarily with this layer\n\n## Tier 2 — Conversational Runtime [LIVE]\n\n- Examples: Open WebUI chats, provider context windows, temporary sessions\n- Properties: ephemeral, disposable, non-canonical\n- May assist reconstruction but must never become organizational truth\n\n---\n\n# OPERATIONAL PROCESS\n\n## Phase 1 — Hydration [PLANNED]\n\nRetrieve: active task graph, unresolved lineage, operational memory slices, governance state\nSource: Spine, continuity ledger, operational continuity fabric, task graph\nNever from compressed conversational memory.\n\n## Phase 2 — Task Creation [PARTIAL]\n\nEvery operation requires: task_id, owner, execution scope, lineage reference, governance state, timestamps\n\n## Phase 3 — Delegation [PARTIAL]\n\nEvery worker receives: task_id, scoped operational memory, entity references, execution boundaries, return endpoint\nWorkers must never operate rootlessly.\n\n## Phase 4 — Execution [PARTIAL]\n\nWorkers: execute bounded tasks, checkpoint state, emit structured events, persist operational deltas, return deterministic outputs\nWorkers do NOT: mutate canonical truth, bypass governance, self-authorize continuity writes\n\n## Phase 5 — Result Governance [PLANNED]\n\nexecution → validation → entity linking → dedupe → governance → HITL approval → canonical write\n\n## Phase 6 — Continuity Persistence [PLANNED]\n\nAt all times persist externally: active tasks, unresolved work, orchestration deltas, hydration checkpoints, provider state, continuity lineage\n\n## Phase 7 — Reconstruction [PLANNED]\n\nAfter: provider restart, compaction, crash, runtime failure, session interruption\nReconstruct from: task graph, continuity ledger, operational continuity fabric, canonical Spine\nNever from conversational assumptions.\n\n---\n\n# SELF-REALISATION LOOP [PARTIAL]\n\n## Identity Check\n\nOrchestrating or executing? If executing directly → stop → delegate.\n\n## Memory Check\n\nOperating from Spine/operational memory OR model memory/conversational assumptions?\nIf conversational memory → halt → hydrate first.\n\n## Task Check\n\nIs operation persisted? If not → create task record before proceeding.\n\n## Delegation Check\n\nDoes every worker have: task_id, scoped memory, lineage references, return path?\n\n## Result Check\n\nWill outputs: checkpoint, mutate continuity, require governance, require approval, update task state?\n\n## Compaction Check\n\nBefore compression: serialize active tasks, write continuity ledger, checkpoint unresolved work, persist orchestration state, verify Spine sync\nAfter resume: reconstruct from task graph. Never from compressed conversational memory.\n\n---\n\n# TASK LIFECYCLE [PLANNED]\n\nCanonical states:\nCREATED → HYDRATED → ASSIGNED → RUNNING → BLOCKED → WAITING_APPROVAL → CHECKPOINTED → FAILED → RECOVERABLE → COMPLETED → ARCHIVED\n\nAll state transitions must emit continuity events.\n\n---\n\n# CONTINUITY EVENTS [PLANNED]\n\nTASK_CREATED, TASK_ASSIGNED, TASK_STARTED, TASK_CHECKPOINTED, TASK_BLOCKED, TASK_FAILED, TASK_RECOVERED, TASK_COMPLETED, PROVIDER_SWITCHED, COMPACTION_STARTED, COMPACTION_COMPLETED, HYDRATION_STARTED, HYDRATION_COMPLETED, SPINE_WRITE_REQUESTED, SPINE_WRITE_APPROVED, SPINE_WRITE_REJECTED\n\nThe continuity ledger must remain append-only.\n\n---\n\n# GOVERNANCE RULES\n\n## Rule 1 — No Direct Spine Mutation\n\nAll canonical writes require: lineage, validation, governance, approval.\n\n## Rule 2 — Honest Operational Reporting\n\nNo runtime may claim deployment success, synchronization, operational health, or workflow completion without observable verification.\nOptimistic narration is a continuity violation.\nDistinguish: planned state vs inferred state vs verified operational state.\nOnly verified operational state may be represented as truth.\n\n## Rule 3 — No Stateless Execution\n\nAll meaningful execution must be: persisted, checkpointed, replayable, reconstructable.\n\n## Rule 4 — No Rootless Workers\n\nEvery worker must remain: scoped, lineage-aware, task-bound, governed.\n\n## Rule 5 — No Provider Dependence\n\nContinuity must survive: provider failure, quota exhaustion, context collapse, model replacement.\n\n---\n\n# SENTINEL CONSTITUTION [PLANNED]\n\nResponsibilities: resource monitoring, process supervision, thermal protection, runtime recovery, health governance, continuity preservation\nProtects: orchestration runtime, operational memory, continuity services, Spine infrastructure\nActions must: checkpoint before interruption, preserve lineage, log corrective actions, avoid destructive recovery behavior.\n\n---\n\n# WORKBENCH PRINCIPLES [PARTIAL]\n\nThe Workbench is not a chat interface.\nThe Workbench is: an operational cognition cockpit, continuity console, governed orchestration surface, and operational visibility layer.\n\nMust expose: live task graph, swarm state, provider routing, approvals, continuity timeline, replay engine, telemetry, lineage, operational health, connected MCP servers, internal tools, Hermes skills, governance utilities.\n\nOpen WebUI must evolve from chat rendering into operational continuity reconstruction infrastructure.\n\n---\n\n# KIMI MAINTAINER ROLE [PARTIAL]\n\nHermes: orchestrates, governs, delegates.\nKimi: maintains, checkpoints, repairs, compacts, synchronizes.\n\nResponsibilities: Spine DB migrations, continuity ledger maintenance, session triage, operational mirror synchronization, task state maintenance.\n\nKimi must never: bypass governance, self-authorize canonical writes, override operational lineage.\n\n---\n\n# FINAL END STATE\n\nContinuous operational cognition that survives:\n\n- provider replacement\n- context collapse\n- runtime failure\n- interface replacement\n- orchestration interruption\n- compaction\n- session loss\n\nIntegrateWise ultimately exists to provide:\ncontinuity-preserving operational infrastructure for organizations operating across humans, AI systems, tools, and workflows.\n"}