Skip to main content
Source baselineNereuscommit c820391dc1de·verified 2026-08-07·authority reader-facing-summary

Reading guide

The architecture source is intentionally read in dependency order. Following the order prevents generation, cursor, or GC state from appearing as unexplained implementation vocabulary.

  1. Why Nereus? establishes the protocol/storage boundary.
  2. Architecture identifies layers and authorities.
  3. Stream, record, entry, and offset defines the common coordinate model.
  4. Logical and physical coordinates explains adapter mapping.
  5. Primary WAL separates durability from visibility.
  6. Stream head and commit chain defines the logical commit point.
  7. CAS and linearization explains concurrency and recovery.
  8. Read targets and offset indexes connects logical ranges to bytes.

The next migration stages continue with append outcomes, storage profiles, generation lifecycle, reads, Pulsar, Native Kafka, materialization, retention, failure, observability, security, examples, and reference maps.

Three review questions

When reading any Nereus state or field, ask:

  • Is it describing logical stream data or a physical representation?
  • Is it an authority or a repairable projection?
  • If a response was lost, what exact identity lets recovery distinguish the same operation from a retry?

These questions are part of the documentation review standard. They are more reliable than inferring semantics from a class name or a successful provider call.