The problem is not that infrastructure forgets. It is that infrastructure remembers in fragments. A workflow ran, a token was exchanged, a role was assumed, a Kubernetes object changed, a controller reacted, an agent called a tool — every one of those was recorded, and every one was recorded somewhere else.
Logs have one piece. Audit trails have another. CI has another. Cloud APIs have another. Kubernetes has another. The warehouse can maybe reconstruct it later, if you already know what to ask. That is not a datastore. That is a scavenger hunt.
This got worse the moment the operator stopped being a person standing near the action. The operator is now often a chain: an agent, a tool, a workflow, a credential, a role, a controller, another system reacting later. Each step produces evidence. No single step owns the story. When the actor was a human at a terminal, scattered evidence was an inconvenience. When the actor is a delegation chain, it is the problem.
Why we pulled the meaning out
Ahti did not start as a datastore. It started as a product, with its own observability business logic and its own opinions about what the evidence meant. The opinions were the problem. Every consumer inherited them, and an opinion baked into storage is one you cannot take back. So we pulled the meaning out and kept what was underneath: a place to store operational claims before deciding what they mean — not logs, not metrics, not traces, not app state. Claims. This producer observed this thing, at this time, under this schema, in this namespace, with this retention class, this redaction state, and these references to other records or artifacts.
Why everything else almost works
That sounds small until you try to build it on top of something else. Postgres almost works. ClickHouse almost works. Kafka almost works. Parquet in object storage almost works. The observability stack almost works. Almost is the problem. Start with Postgres and the write path buckles under analytical reads it was never shaped for. Start with ClickHouse and you bend a columnar warehouse into an append API it does not want to be. Start with Kafka and you rebuild query, retention, replay, and recovery. Start with Parquet and you still need append, schema validation, manifests, auth, SQL, backup, and restore. Start with the observability stack and you depend on fields nobody promised.
What Ahti is
At some point the missing layer has a shape. So we built it. Ahti is our append-first operational evidence database. It stores authenticated, schema-validated records and gives them envelopes. It writes accepted records through a WAL, keeps recent records in Arrow, and rolls older records into Parquet/ZSTD. It queries through DataFusion and Flight SQL. It uses MVCC for safe visibility and reclamation. It has backup and restore, because a datastore without restore is a story someone tells before the incident.
Why each piece
The stack follows the problem. Rust because this is a database process. WAL because accepted writes need a durability boundary. Arrow because the hot path is analytical. Parquet because cold evidence should be cheap, portable, and still queryable. DataFusion because we do not need a private query language. Flight SQL because Arrow-native clients should not pretend everything is JSON. Structured logs, Prometheus metrics, and OpenTelemetry traces because Ahti itself has to be operated.
The objection, answered
This is also the answer to the obvious objection. Parquet in a bucket gets you the file format; it does not get you the guarantees. If a record is accepted, it should survive — that is a durability boundary, not a file. If a record is queried, it should be clear which version of storage it came from. If a cold file is retired, it should not disappear under an active reader. If a record is redacted, the system should not pretend the old bytes vanished before the storage lifecycle actually made that true. If the datastore fails, an operator should have logs, metrics, traces, readiness, backup, and restore instead of a shrug. None of these are properties of a format. They are properties of a process. That is why Ahti is one.
What Ahti will not do
The interesting part is still the boundary. Ahti stores claims. It does not decide what they mean. A relationship claim is not a causal chain. An actor observation is not a risk score. A stored decision is not automatically correct. A redacted record is not physically erased until the storage lifecycle says it is.
That refusal is the product. Once the datastore starts interpreting the evidence it stores, every consumer inherits its assumptions. That is convenient for a demo and dangerous for a system. The system above may care about actor behavior, deployment history, execution records, low-level observations, or something else entirely — and it should. Ahti should not. Ahti stores structure. Products understand meaning.
The borders are plain. Append is durability, not workflow. Query is read access, not product analytics. Subscribe is tailing, not a broker. Auth is protocol authorization, not product policy. Schema validation is shape, not truth. Relationships are records, not graph intelligence. Retention and redaction are lifecycle mechanics, not compliance slogans. Observability describes Ahti itself, not the evidence inside it.
The bet
We do not want Ahti to be a giant platform. We want it to be small enough to understand and strong enough to trust — a place that preserves what the infrastructure claimed, before explanation begins.
Ahti is part of False Systems, the operations layer for a world where agents are the operators. It is the datastore beneath everything else we build — early, and in active development.