Reading guide
The specifications are separate by design — one learnable whole per audience.
Each path below is a route through the same four languages, not a different set
of them. Pick the path for your role; each links to the full reference. The
family overview
(docs/specification/ridl-family-overview.md)
is the map that ties them together.
typl, ridl and rsdl have a toolchain. A path below that ends in rxdl or rmdl ends in a specification you can design against but cannot compile — see what is built.
- Data architect — typl, end to end. It stands alone.
- Service / bus SSOT engineer — typl §1–§10, then ridl end to end.
- UX / frontend engineer — typl §1–§10, ridl's core semantics and the presentation and intent families, then rxdl (specified, not built).
- Sensor / actuator engineer — typl §1–§10, ridl's acquisition and control families and their correspondence obligations, then rxdl §5 (specified, not built).
- Control / algorithm engineer — typl §1–§10, ridl §3/§9, then rmdl (specified, not built).
- Integrator / architect — everything above at survey depth, then rsdl, with Describing a system.
- Auditor / safety assessor — the family overview's shared doctrines, then typl's keyword registry and evolution model, ridl's error strata and services, and the diagnostics table of each reference.
Writing your first .ridl file rather than reading a specification? Start with
First steps, then Getting started.
For the motivation and the big picture, read the concept note
(docs/wip/ridl-family-concept.md);
for the shared surface rules across every profile, the general form
(docs/specification/family-general-form.md).
Building the toolchain? Start with
the roadmap and
the decision records.