---
name: "Adr 0000 Invariants"
description: "Foundational architectural invariants of the Correx system"
depth: 2
links: ["../index.md", "../architecture/overview.md", "../decisions/adr-0001-event-sourcing.md"]
---

# ADR 0000: architectural invariants of the correx system

**status:** accepted
**date:** 08.05.2026
**deciders:** Kami

---

## context

Correx is an event-sourced orchestration system with deterministic replay requirements, LLM-driven inference, and multi-layered execution (validation, approvals, tools, context synthesis, and transitions).

Without explicit invariants, the system risks:

* implicit coupling between modules
* nondeterministic behavior creeping into core logic
* inconsistent interpretation of event streams across bounded contexts
* broken replay guarantees under evolution of modules

This ADR defines the **hard architectural rules** that all other ADRs and implementation decisions must obey.

These invariants are not suggestions. They are constraints on system evolution.

---

## invariants

### 1. event log is the single source of truth

All system state MUST be derivable from the event stream.

* no hidden mutable state is allowed to influence execution outcomes
* all decisions, approvals, transitions, and tool executions MUST emit events
* projections are disposable and rebuildable at any time

implication:

* caching is allowed only if it is derivable from events
* any system behavior not reproducible from events is a bug

---

### 2. projections are bounded-context owned

Each bounded context owns its own projection(s).

* `sessions` owns session state projection
* `artifacts` owns artifact state projection
* `context` owns context assembly projection
* `validation` owns validation state projection

projections:

* MAY NOT mutate each other
* MAY NOT be shared as a global mutable model
* MAY be reconstructed independently from the event stream

implication:

* there is no “global system state object”
* cross-domain reasoning must go through events or read-only queries

---

### 3. deterministic core vs nondeterministic inputs separation

The system is split into two layers:

**deterministic core:**

* event handling
* state transitions
* approval logic
* validation routing decisions
* scheduling

**nondeterministic layer:**

* LLM inference
* tool output
* user input
* external system responses

rule:

* nondeterministic outputs MAY influence events
* but ONLY deterministic core may commit events

implication:

* LLMs propose; core decides
* tools suggest; core validates and records

---

### 4. no cross-module implementation dependencies inside core (outdated)

Inside `:core`, modules MAY depend only on:

* `:core:contracts` (or equivalent shared model module)
* or strictly lower-level primitives

forbidden:

* `context → validation`
* `validation → approvals`
* `router → kernel internals`

allowed:

* interaction only via:

    * events
    * interfaces
    * explicit orchestration entrypoints

implication:

* core is a DAG, not a mesh

---

### 5. event causality is strictly linear per session

Within a single session:

* every event MUST have exactly one causation parent (except root)
* sequence ordering is total and monotonic
* correlation IDs define logical grouping but do not define ordering

implication:

* no ambiguous causality graphs
* replay is deterministic and linear

---

### 6. policy layer is absolute and non-overridable

Policy evaluation is the highest authority layer.

* approvals cannot override policy denial
* validation cannot bypass policy constraints
* tool execution cannot ignore policy results

policy failure is terminal for the operation path.

implication:

* approval system is not a security boundary; policy is

---

### 7. tool execution is sandbox-first by default

All tools:

* MUST declare execution tier
* MUST be assumed unsafe until validated
* MUST produce structured receipts

side effects:

* are only valid if captured in events

implication:

* “silent execution” is not allowed in system design

---

### 8. compression and summarization are non-authoritative

Any compressed, summarized, or derived representation:

* MUST NOT replace original events or artifacts
* MUST be reproducible from source data
* MUST be explicitly marked as derived

implication:

* no lossy compression in the source-of-truth layer
* only in read models

---

### 9. LLM outputs are untrusted until validated

Any output from inference:

* is considered a proposal
* cannot affect state unless validated and approved
* cannot bypass schema validation

implication:

* prompt injection is structurally contained, not just filtered

---

### 10. replay must be environment-independent

Replaying a session:

* MUST NOT depend on current system state
* MUST NOT depend on external services
* MUST NOT require live LLM calls (unless explicitly in “live replay mode”)

implication:

* full determinism is a first-class requirement, not a debug feature

---

## consequences

**positive:**

* system behavior remains consistent under evolution
* replay and debugging are guaranteed properties, not best-effort
* module boundaries become enforceable in code and architecture
* future distributed execution becomes feasible without redesign

**negative:**

* requires discipline in module design (especially core dependencies)
* increases upfront design overhead for new components
* forces strict separation between “thinking” and “executing” layers

---

## status

This ADR is foundational. All future ADRs are subordinate to these invariants. Any contradiction requires revision of this document before implementation proceeds.
