data-systemslisted

# Data Systems Turn a data requirement into explicit ownership, invariants, access paths, consistency guarantees, failure behavior, and an operable evolution path. Choose the smallest data system that satisfies the evidence; named technologies and patterns are candidates, not conclusions. ## Workflow 1. Establish the decision and evidence boundary: - business facts and invariants that must remain true - commands, reads, queries, scans, and retention needs - observed or forecast load, growth, latency, and availability needs - failure consequences, recovery objectives, privacy, and compliance limits - current systems, team skills, operational ownership, and migration limits 2. Mark every input as observed, required, forecast, or unknown. Do not invent traffic, cardinality, growth, correctness, locality, or durability needs. When a missing fact can change the design, identify the measurement or decision needed before commitment. 3. Model the authoritative facts, identities, relationships, lifecycle, and ownership before selecting storage. Read [Storage and models](references/storage-and-models.md) for model and datastore choices driven by access patterns and invariants. 4. Define correctness per user or system flow. Read [Transactions and consistency](references/transactions-and-consistency.md) when work involves atomicity, isolation, concurrent updates, idempotency, read-your-writes, stale reads, or coordination across boundaries. 5. Read