ChronoLog

The question

Beyond storing data, computing systems increasingly need to store activity: things that happen rather than things that are. Instruments, workflows, schedulers, and now agents all produce streams of events that someone later needs to replay in order. Every distributed log I could find at the time paid for that order with a sequencer or a consensus protocol, and the sequencer became the bottleneck.

ChronoLog asked a blunt question: what if the clock did the ordering?

Where it came from

I designed ChronoLog in 2019 and 2020, while Hermes was maturing and I was watching how much of the metadata traffic in a storage system was really activity data. The MSST 2020 paper with Hariharan Devarajan, Keith Bateman, Jaime Cernuda, Neeraj Rajesh, and Xian-He Sun laid out the design and measured a prototype at more than one million tail operations per second, an order of magnitude past the distributed logs we compared against.

In May 2021, NSF funded ChronoLog as a CSSI Frameworks award, collaborative with Kyle Chard at the University of Chicago. Xian-He Sun is the PI; I am a co-PI and the architect.

The architectural bet

Use synchronized physical clocks to establish total order, and remove the sequencer from the append path entirely. New entries become visible the moment they land. Many writers and many readers can work at once. The cost is that ordering is bounded by clock skew rather than exact, which is a fair trade for activity data: a log ordered within microseconds is enough for provenance, monitoring, and replay.

The second bet is that a log should scale in three dimensions at once. Horizontally across nodes for throughput, vertically across storage tiers for capacity, and temporally by timestamp so a range query knows where to look. Records enter close to compute, get assembled into time-ordered stories, and migrate from memory to NVMe to the parallel file system to the archive without the application noticing.

The system

ChronoLog is five services with deliberately narrow jobs. ChronoVisor coordinates clients, metadata, and time. ChronoKeeper ingests events over RDMA into a distributed journal and serves tail reads. ChronoGrapher collects events into stories and writes them down through an elastic pipeline. ChronoStore manages the intermediate and archival tiers. ChronoPlayer merges parallel reads across tiers into one ordered stream for replay().

The releases tell the maturity story better than I can. 1.0.0 in June 2024 deployed the service pipeline. 2.0.0 in February 2025 added ChronoPlayer and historical replay, the first end-to-end bidirectional release. v3.0.0 in May 2026 cleaned up the client API, added ChronoSQL and a ChronoPubSub plugin, and moved the MCP server into the main repository so an agent can create chronicles, record, replay, and run time-range queries through CLIO Kit. The team ran a half-day ChronoLog workshop at PEARC25 in July 2025.

The people who built it

Kun Feng and Eneko Gonzalez wrote most of the current code and shipped the 2.x and 3.0 releases. Inna Brodkin at the University of Chicago engineered the UChicago side. Keith, Jaime, and Neeraj carried the design from the paper into the first services, and Luke Logan connected it to the runtime lineage that became CLIO Core. The commit history on the repository is the honest record of who did what.

What carried forward

ChronoLog’s physical-time ordering and tiered retrieval are now the model for how IOWarp thinks about provenance, and the reason the receipt in Clio Coder is a time-ordered ledger rather than a summary. The team is designing AgentLog on top of it: typed event records, causal views, and policy-controlled sharing for multi-agent science, intended for the National Data Platform’s federated environment with the University of Utah. That is design-stage work, and I will call it software when it is.

What I am still asking

• How much of an agent’s activity needs to be sealed at write time, and how much can be reconstructed from a replayable log?
• What is the smallest query surface an agent needs over a log: time range, causal chain, or both?
• Can the same log serve an instrument at a million events per second and a coding agent at ten?