Build a conformant server

You don’t implement “all of OpenRiC” - you pick a profile and meet its contract. The smallest meaningful claim is Core Discovery (read-only).

The shape of the work

1. Map your catalogue to RiC-O. Records → rico:Record/RecordSet/RecordPart, creators → rico:Agent, etc. See the mapping document and entities & relations.
2. Serve the endpoints for your chosen profile, returning application/ld+json. For Core Discovery: GET /api/ric/v1/{records,agents,repositories}, /{type}/{slug}, /vocabulary, /autocomplete.
3. Mint IRIs per the Governance profile two-layer policy - stable, environment-independent public IRIs (https://<host>/ric/<type>/<slug>).
4. Declare your profiles in the service description at GET /api/ric/v1/.
5. Validate - pass the conformance probe and the SHACL shapes.

Validate against the schemas + probe

# JSON Schemas + SHACL shapes (the spec ships both)
#   schemas/*.schema.json   shapes/*.shacl.ttl
# Probe your server end-to-end:
BASE=https://your-host/api/ric/v1 ./conformance/probe.sh
KEY=<write-key> BASE=https://your-host/api/ric/v1 ./conformance/probe.sh   # + write surface

There’s also a Python validator (validator/) that checks fixtures against the schemas, and an API Explorer / OpenAPI you can diff your server against.

Reference implementation

The OpenRiC reference service (Laravel) is open source (AGPL-3.0) - use it as the canonical behaviour to match. The point of the spec is that a second, independent implementation can pass the same probe; that’s a v1.0 freeze criterion.

Writing & AI

• Implementing writes? See the Round-Trip Editing profile (POST/PATCH/DELETE + audit) and Creating entities.
• Surfacing AI-suggested data? The draft Inferred-Provenance profile requires machine-asserted edges to be visibly distinguishable from documented fact.

Next

• Conformance & profiles
• The system map and profiles tree