Before any compression is possible you need a precise event log — not conversation history, not text blobs. Typed events with schema. Every ticket created, revised, or abandoned. Every inference accepted or rejected. Every time block allocated or displaced. Every sales attempt and outcome. Every code change and revert.

The schema is the hardest design decision in the whole system. Vague events produce vague latent factors. The more precisely you define what counts as an event and what its attributes are, the more useful the compression becomes.

Storage: SQLite — append-only, fixed schema, modest data volume, handles concurrent reads. A handful of tables: events, inferences, model_scores, feedback.

A standard autoencoder compresses input to a bottleneck and reconstructs it. A sparse autoencoder adds a constraint: most hidden neurons must be inactive at any given time. That sparsity pressure forces interpretable latent features rather than distributed encodings that work mathematically but mean nothing to a human.

The diagram shows it: many input nodes → small bottleneck → sparse hidden layer where only a few neurons activate per event. Those active neurons are the latent factors GEDS tracks — the underlying variables that explain why your operational stack behaves the way it does.

Trained in: PyTorch. Once trained, the decoder is discarded. Only the encoder is used to embed new events as they arrive.

Embeddings stored in: ChromaDB or LanceDB — both embeddable, no separate server. SQLite blobs work fine at V1 scale.

Theoretical grounding: The objective function the autoencoder serves — rewarding compression progress rather than compression achieved — is formalized in Schmidhuber's 2009 paper Driven by Compression Progress. The core argument is that interestingness is not raw novelty but the rate of improvement in a system's ability to compress its observations. That is the reward signal GEDS is built around. arxiv.org/pdf/0812.4360

This is what makes GEDS different from a dashboard. A dashboard tells you what happened. The detector tells you when a new explanation suddenly accounts for a lot of previously scattered behavior.

The chart above shows it: two competing models improving slowly over time, then one suddenly jumps — a new latent factor collapses a lot of previously uncompressed variance. That jump is the signal. GEDS fires.

The metric: delta compression per unit of model complexity. Did this new explanation make a lot of scattered stuff simpler without adding too much machinery? Stated technically: did reconstruction error drop significantly relative to the increase in model parameters?

In V1 this is not classical RL. It's a Bayesian scoring function. Each competing model has a score. New events raise or lower that score based on whether the model predicted them. A significant score jump triggers a surface event.

Compression engines can go wrong. Conspiracy theories are compression engines. Delusions are compression engines. "Everything is about X" is often a high-compression, low-truth model. Before any inference reaches you it must pass five gates.

The last component to touch an inference, and the narrowest. Its job is strictly translation: take what the compression engine surfaced and the validator approved, and render it as a human-readable unprompted ticket with evidence attached.

The LLM does not evaluate whether the inference is true. It does not add interpretation. It does not generate its own structural analysis. It renders. This is the division that keeps the "what's the point" organ outside the language model, where it belongs.

The LLM also handles the second-pass jobs: explaining the evidence in plain language, generating the GOMS ticket from an accepted inference, writing the sales draft, producing the code review. All of that is articulation work. None of it is compression work.

API cost stays low because the LLM only fires when a compression passes the validator threshold — not on every event, not on every cycle of the scoring loop.