Event-Sourced Operations

For most of the past decade, event sourcing has been a specialist’s tool — used mainly in domains where regulatory or audit concerns overrode the extra engineering cost. The arrival of AI assistants that cite operational data has flipped that equation.

When an AI feature is asked "what happened to deal 184 last Tuesday?", the only architecture that answers without a forensic exercise is one where "what happened" is itself the storage primitive. Event sourcing is that shape.

At the core of Aixys is a single append-only event stream partitioned by entity. Events are typed envelopes carrying intent, a timestamp, an actor identity, and a payload. Everything else in the system — the UI, the reports, the AI — reads projections of this stream.

Projections are materialised views: small, fast, and disposable. When we change a UI, we may add a new projection; we rarely touch the stream itself. This is the decoupling that makes AI features cheap to ship and easy to trust.

Event-sourced architectures are slower to write than CRUD. We mitigate this with per-entity partitioning and by pushing derived reads onto projections. In practice, at our scale, write latency is indistinguishable from a well-tuned relational system.

Schema evolution is genuinely different. Renaming a field is not a rename; it is a new projection of an old stream. We have chosen to version every event type from day one, so "the schema" is always a stack of versions, not a single present-day truth.

Compliance frameworks that traditionally demanded a separate audit log can, under this architecture, simply subscribe to the stream. HIPAA-style access traces, SOC 2 change logs, and GDPR purpose-of-use records all derive from the same source.

The same substrate underpins grounded AI: a citation in an AI answer is a pointer to an event. An auditor can open that pointer. An AI feature can open it. An operator can open it. Three different consumers, one truth.