RG4

Downloadable Register Exports

This page makes the public case register and correction log available as documented CSV and JSON extracts. The exports support checking, archiving, and reuse without detaching metadata from the human-readable documents to which it refers.

Document code: RG4
Document version: 1.0
Last substantively revised: 18 June 2026
Document type: Register export and validation
Responsible publisher: Vikesland Press
Source language: Nynorsk; English translation
Relation: Built on RG1, RG2, and RG3 and checks correspondence between Nynorsk and English register data.

Function and boundary

The register exports are derived public metadata files. They collect what is already published in the case register and correction log, but do not publish raw material, private sources, internal notes, or personal data.

CSV is intended for spreadsheets, simple analysis, and archival workflows. JSON preserves field structure, code/label distinctions, and machine-readable relations. Neither format replaces the canonical human-readable page.

Every export carries a schema version, export date, and language. Language-pair control tests that stable codes and methodological status fields correspond between Nynorsk and English.

Downloads

CSV

Case register — CSV

Flat table with one public object per row.

/en/reality-audit/examples/exports/case-register.csv

JSON

Case register — JSON

Structured export with code/label pairs and field metadata.

/en/reality-audit/examples/exports/case-register.json

CSV

Correction log — CSV

Flat table with one revision or correction entry per row.

/en/reality-audit/examples/exports/correction-revision-log.csv

JSON

Correction log — JSON

Structured export of revision trace, object link, version, and status.

/en/reality-audit/examples/exports/correction-revision-log.json

JSON

Validation report — JSON

Machine-readable report for code uniqueness, language pairing, and structural correspondence.

/en/reality-audit/examples/exports/validation.json

Field documentation

Fields are separated into stable codes and localized labels. Codes support comparison and validation; labels support reading in the selected language.

CSV extracts use a vertical bar inside fields containing multiple values, for example D1|D2 or A1|A4.

Case register

Field	Type	Description
code	string	Stable language-neutral identifier for the public object.
kind / lifecycle / publicationLevel	object	Machine code and localized label for object type and publication state.
domains / auditTypes	string[]	D1–D8 and A1–A7 code arrays, with separate localized label arrays.
version	string	Version of the human-readable object.
revisionStatus / correctionStatus	object	Machine code and localized label for revision and correction state.
updated / summary / note	string	Localized public metadata, not raw case material.

Correction and revision log

Field	Type	Description
code	string	Stable revision-log identifier.
objectCode / objectUrl	string	Stable object link and canonical human-readable URL.
versionFrom / versionTo	string	Version transition recorded by the revision entry.
changeType / status	object	Machine code and localized label for change type and workflow status.
reason / scope	string	Public reason for the change and the boundary of what it affects.
publicNote	string	Public clarification about remaining correction, reopening, or limitation.

Export date and schema version

The schema version identifies the field structure used by the export. It must not be confused with the version of a case, protocol, or register object.

The export date identifies the public register state from which the extract was built. Later changes require a new export date and relevant revision trace.

Schema version

All Stage 34 extracts use register-export schema 0.1.

Export date

All extracts in this version are dated 2026-06-17.

Language

Each file is marked nn or en; stable codes must correspond while labels and summaries may be translated.

Canonical address

JSON extracts identify their canonical file, language pair, and human-readable explanation.

Language-pair control

Language pairs are not checked by demanding identical text. They are checked by demanding the same stable codes and the same methodological status values.

Titles, summaries, notes, and labels may differ linguistically. Object type, lifecycle code, publication level, domains, audit types, version, and correction status must not change merely because the language changes.

LP1

Same object codes

NN and EN must contain the same set of register codes.

LP2

Same revision codes

NN and EN must contain the same set of revision-log codes.

LP3

Same methodological structure

Code fields, domains, audit types, version, and status must correspond.

LP4

Localized human text

Labels and explanations may be translated without changing codes or function.

Validation report

The report below is generated from the same data sources as the exports. It is a simple structural control, not confirmation that every summary is complete or that a future case finding is true.

A failed check should stop publication of new extracts until the code or structural difference has been explained and corrected.

Overall status: Passed
Generated: 2026-06-17
Checks: 8/8
JSON: /en/reality-audit/examples/exports/validation.json

Unique case-register codes

Each language version must contain one entry per stable case or register code.

Passed

Unique revision codes

Each language version must contain one entry per stable revision code.

Passed

Case-register language pair

NN 8 entries; EN 8 entries; stable code sets must match.

Passed

Revision-log language pair

NN 8 entries; EN 8 entries; stable revision-code sets must match.

Passed

Case-register structural parity

Kind, lifecycle, publication level, domains, audit types, version, revision status, and correction status must correspond across languages.

Passed

Revision-log structural parity

Object, object type, versions, change type, and status must correspond across languages.

Passed

RG4 export object present

The downloadable register-exports object must be present in both public case registers.

Passed

RG4 publication revision present

REV-2026-008 must record the initial publication of RG4 in both languages.

Passed

Safeguards and use

Export makes metadata easier to copy and combine. The same boundary governing RG1–RG3 must therefore travel with the files.

EV1

Not a personal register

The extracts must not be expanded with personal data or used as a guilt, reputation, or authority register.

EV2

Canonical source

Users must be able to move from each entry to its human-readable page and check status, boundary, and correction trace.

EV3

No finding strength from format

The ability to sort, count, or import data does not make an entry more true or binding.

EV4

Downstream correction

Copies and analyses should retain export date and schema version so later corrections can be traced.