Choosing a ring

Start from what you want to do

Take the smallest ring that answers your question — you can always move outward later, and nothing you wrote against a lower ring changes when you do, because the lower ring is unchanged by the higher one (see rings for why that holds structurally).

If the table already answered you, jump to that ring's group in the sidebar — each ring's pages open with what the ring is and end with the packs it gives you. If you recognize yourself in one of the four readers below, follow the path — each is ordered, each stop earns the next, and each ends in something you can do.

The first-time evaluator

\"What is this, and is it for me?\" — answerable without meeting a single directive:

• intro — what CX is and what problem it refuses to have.
• rings — the shape of the system: four rings, one import direction.
• quickstart — the first five minutes; it runs inside Ring 0 before it shows you anything that executes.
• comparison — CX against JSON, YAML, XML, Protocol Buffers, and friends, in both directions.

You are done when you can say what CX would replace in your stack and which ring that replacement lives in. If the answer is \"nothing\", the comparison page will have told you that honestly.

The data-format adopter

You want the format — parse, validate, convert, hash, diff — and you never intend to run a program. Ring 0 is a complete product for you, and this path never asks you to understand the evaluator:

• data — the data language end to end: elements, scalars, collections, anchors.
• value-model — one value, one address: what identity buys you and what rides in the three lanes.
• surfaces — projections to and from JSON, XML, YAML, TOML, Markdown, and the binary forms.
• identity — canonical form and hashing, the mechanics under the promises.
• schema-evolution — validation, computable compatibility, and what happens when schemas change.
• tour-data — fifty worked data recipes; analytics for the columnar and bridge story.

You are done when cx fmt, cx validate, cx hash, and cx diff are in your build, and the Ring-0 pack index (on the ring's pages) tells you exactly which library surface you may lean on — and that http is not in it.

The application author

You want to build something that runs — programs first, then a feature on the platform:

• quickstart — the Ring-1 half: your first programs.
• code — the code language: directives, CXPath, patterns, errors as values.
• capabilities — deny-by-default and the grant flags; read this before your first --allow-*.
• computation-identity and commands-effects — what makes results cacheable and effects auditable.
• tour-programs — fifty worked program recipes.
• store and xap-distribution — when your program becomes a feature others install: authoring, hosting, and distribution.

The end-to-end worked story is the ORIEL reference surface — a storefront with departments, baskets, checkout, and three renderers, built entirely from declarations. Its developer guide is docs/dev/oriel-guide.md (\"build a surface the ORIEL way\"), and the task-oriented developer set under docs/dev/ walks authoring, consuming, and distributing features.

The platform operator

You run the thing: stores, journals, services, upgrades.

• store — the store platform: content addressing, refs, journals, folds.
• bitemporal, consistency, event-evolution — the three contracts you operate under: two time axes, declared guarantees, and reading old events under new vocabulary.
• operations — daemons, health, recovery, security posture; the operator reading order continues in docs/dev/ (store service, management, security).
• xap-distribution — the distribution machinery your developers will ask you to operate.

You are done when you can answer, without opening a runbook: where is history kept (one journal, append-only), what does a correction do to an invoice already sent (nothing — bitemporal), and what happens when a consumer asks for a guarantee a replica cannot give (a loud refusal naming the token — consistency).