RiC baseline and conformance
Records in Contexts is four documents, not one, and OpenRiC targets a specific version of each. This page names them. If you need to know in one minute what OpenRiC conforms to, this is the page.
The stack OpenRiC targets
| Standard | Version | What it is | How OpenRiC uses it |
|---|---|---|---|
| RiC-FAD | 1.0 | Foundational principles for archival description | Assumed. OpenRiC does not restate it. |
| RiC-CM | 1.0 | The conceptual model - entities, attributes, relations | The model OpenRiC’s RiC-CM navigator presents, and the vocabulary its user-facing labels map back to. |
| RiC-O | 1.1 | The OWL ontology - the normative RDF implementation target | The normative target. Every IRI OpenRiC emits is a RiC-O 1.1 term, or an openricx: term where RiC-O 1.1 has no equivalent. |
| RiC-AG | 0.1 | Application guidelines, including crosswalks from the four legacy ICA standards | The upstream authority for the ISAD(G) / ISAAR(CPF) / ISDF / ISDIAH crosswalk. spec/mapping.md §1.2 defers to it where the two agree. |
OpenRiC itself is at v0.46.0 (2026-10-15). That version line describes the OpenRiC contract - the HTTP API, the profiles, the schemas and shapes - and moves independently of the RiC versions above.
OpenRiC and the ICA
OpenRiC is an independent project. It is not issued, reviewed or endorsed by the International Council on Archives or its Expert Group on Archival Description (EGAD), and it does not replace or amend any part of Records in Contexts. It is one way of implementing RiC over HTTP. Where this site and an ICA text disagree, the ICA text is authoritative and the disagreement is a defect in OpenRiC, to be reported on the specification repository.
The rule about namespaces
OpenRiC never mints a term in the RiC-O namespace. Where an implementation needs a concept RiC-O 1.1 does not define, the term goes in the OpenRiC extension namespace https://openric.org/ns/ext/v1#, prefix openricx, published as an ontology page and Turtle file.
That namespace holds the terms listed on its vocabulary page, in three groups: response-envelope classes that are protocol concerns rather than archival semantics; pragmatic API shortcuts that have a clean canonical expansion in RiC-O 1.1; and a small set of genuine archival concepts that RiC-O 1.1 does not yet model. Only the third group is a candidate for going upstream, and those are drafted as proposals to ICA-EGAD.
The per-term disposition, with confidence flags, is in the RiC-O 1.1 conformance audit.
What conformance means here
Conformance is claimed per profile, not as a single overall level. OpenRiC defines 12 profiles - 7 normative, 5 draft - and an implementation declares each one it supports, with its own version and conformance degree. See the profile index and the conformance specification.
The older L1-L4 level vocabulary is legacy. It survives as a level field in responses for compatibility, but it no longer frames conformance and should not be used in new material.
Tracking upstream
RiC is still moving, and OpenRiC does not guess ahead of it. Changes to the normative core wait for an official ICA-EGAD release; open proposals in the RiC-O repository are watched, not adopted. What OpenRiC is tracking, and where the reference implementation currently lags the specification, is recorded in the drift log.
Where OpenRiC has contributed upstream - on agent roles in relations, language on relations, SHACL, and a PROF profile - those threads are linked from related implementations.
What OpenRiC does not replace
OpenRiC is an access contract over RiC data. It is not a replacement for IIIF (presentation and delivery of digital representations), Linked Art or CIDOC CRM (museum and cultural-object semantics), Wikidata (shared external identity), or the operational source standards an institution already runs. Where those overlap with RiC, the right answer is a documented mapping, not forcing foreign semantics into RiC-O.