RG2
Machine-Readable Register File
This page defines the machine-readable register file for Reality Audit. The JSON register makes published examples, protocols, register entries, and revision history traceable without turning the register into a new source of findings.
Function and limit
The machine-readable register file provides a stable public JSON layer for the site. It can support internal tools, archives, search, future visualisations, and external readers that need structured metadata.
The file contains only public metadata: code, title, link, type, lifecycle status, publication level, application domains, audit types, version, and correction status. It does not publish hidden material, raw sources, personal data, or non-public case matrices.
The JSON register is a tool for traceability. It does not decide findings, increase confidence, or replace the human-readable case presentation.
JSON endpoints
Nynorsk JSON
Canonical machine-readable register file for Nynorsk publication.
/royndsgransking/dome/register.jsonEnglish JSON
Canonical machine-readable register file for English publication.
/en/reality-audit/examples/register.jsonHuman-readable explanation
This page with field explanations, limits, and safeguards.
/en/reality-audit/examples/machine-readable-register/Schema and fields
The schema is deliberately small and stable. It should be easy to read, export, and check without locking future cases into a premature technical format.
All links in the JSON payload are absolute. Code values are language-neutral where methodologically important, while labels follow the selected language version.
| Field | Type | Description |
|---|---|---|
| schema | string | Stable identifier for the register family. |
| schemaVersion | string | Version of the JSON structure, not necessarily the version of each case. |
| language | nn | en | Language version for labels and summaries. |
| counts | object | Number of register entries, revision entries, and published actual cases. |
| register[] | array | Published examples, protocols, registers, and future actual cases. |
| revisions[] | array | Visible corrections, publications, reopenings, and revisions from RG3. |
| correctionStatus | object | Code and label for whether a correction is open, corrected, or closed. |
| domains / auditTypes | array | D1–D8 and A1–A7 as metadata, not as findings. |
Register contents
The register file gathers metadata from RG1 and RG3. It contains the same public objects that are published on the site, but in a machine-readable format.
There are still no published actual cases. This is also expressed in the JSON counter publishedActualCases.
Examples
Synthetic examples are marked as synthetic and must not be read as actual events.
Protocols
CP1 and CA1 are marked as protocol; they are method texts, not cases.
Registers
RG1, RG2, and RG3 are marked as register and show traceability and correction infrastructure.
Actual cases
Future actual cases can be entered only when the relevant protocol, status, and publication level are in place.
Version and revision
The JSON file includes the correction and revision log so that changes can be traced by both humans and machines.
A new version of the JSON file is not itself a material correction. Material correction requires its own log entry, reason, scope, and status.
Object link
Each revision points back to an object code and human-readable page.
Version before and after
The log distinguishes first publication, clarification, material correction, and method revision.
Downstream trace
Machine-readable status makes it possible to find entries that require further updating.
Language parallelism
NN and EN payloads share the same codes, with separate labels and canonical links.
Safeguards against misuse
A machine-readable register can increase traceability, but it can also be misused if read as a personal register or judgment register. The field set is therefore limited.
No raw material
The file must not contain sources, internal notes, private documents, or non-public matrices.
No personal-register effect
Future actual cases must not expose names or sensitive indirect identifiers through metadata fields.
Status is not finding
LS status, PL level, and correction status are methodological metadata, not conclusions about the case.
Correct correction channel
Machine-readable errors must be correctable through the same revision and correction log as human-readable documents.
Absolute links
The payload uses absolute URLs to prevent ambiguous linking during copying and archiving.
No hidden authority
The register file is not authoritative over the human-readable document; in case of conflict, the document and revision log must be checked.
Implementation and further programme
The first version is published as static JSON from Astro. Later, the same structure can support downloads, archiving, visualisation, internal validation, and public API-like access.
Static export
The file is built with the site and requires no database or user tracking.
Schema version
Changes to the field structure should require a schemaVersion change and an RG3 log entry.
Validation
Future validation can check that all published pages exist, have revision log entries, and have correct language pairs.
Further programme
Next steps may include downloadable CSV/JSON extracts, an internal validation report, or a visual register map.