# Chronicle For information systems, this is the default architecture we recommend: store **every meaningful change as an immutable event** — the complete history of what happened — and turn those events into exactly the read models, reactions, and projections your application needs. Chronicle gives that event log a gRPC boundary, storage choice, Orleans-based processing, and tools you can actually operate. [Get started →](/chronicle/get-started/) · [Architecture →](/chronicle/architecture/) ## Start here Why we see full history as the default for information systems — audit, time-travel, many read models from one source of truth — and where the exceptions are. Scaffold a project from a template and watch one event flow through a projection and a reactor — in minutes. Compare console, worker, ASP.NET Core, Arc, Aspire, and production-managed kernel setups. Learn the model by building a small event-sourced system one concept at a time. ## Architecture wins Chronicle is a client-server kernel with gRPC/protobuf contracts. The .NET client is first-class and most mature; TypeScript and Elixir clients/contracts are generated from the same protocol. Run the event store over MongoDB, PostgreSQL, Microsoft SQL Server, or SQLite, with the same event model above it. The kernel uses .NET Orleans for distributed, stateful processing: event sequences, observers, jobs, reminders, and recovery all live inside the runtime. Workbench, CLI, OpenTelemetry, recommendations, read-model inspection, failed partitions, jobs, and replay make the running store visible. ## Understand the model How the kernel, client, storage, and read models fit together. Events, event sources, projections, and the rest of the vocabulary — defined once. Maps tables, rows, and `SaveChanges` onto events so the shift makes sense. ## Build with the core pieces The immutable facts at the heart of everything — how to model and append them. Declare read models that stay in sync as events arrive — no update code. See model-bound projections, declarative projections, and reducers build the same read model. Do something when an event happens — notify, integrate, or trigger a command. The queryable state your application reads, derived from the event log. Fold events into state imperatively when a projection isn't enough. Task-oriented recipes — rebuild a read model, enforce uniqueness, react to an event. Chronicle stands on its own — run it from any .NET host, with no other Cratis product required. When you want a typed full-stack app on top, [Arc](/arc/) adds the CQRS boundary and [Components](/components/) renders it. CQRS and event sourcing fit naturally together, but neither depends on the other. See [Why developers choose Cratis](/why-cratis/) for how the pieces fit.