RG3
Correction and Revision Log
The correction and revision log shows when a published case object, example, protocol, or register is changed, why the change was made, what scope it has, and what status it remains in.
Function and boundary
Reality Audit cannot be corrigible if changes disappear into silent rewrites, unclear versions, or scattered corrections without a common trace. This page makes correction and revision a visible register object.
The log does not increase the strength of a finding. It only shows what changed, why it changed, which document it concerns, and what effect or limitation remains.
A published error should not be protected in order to protect the original presentation. At the same time, not every submission automatically becomes a material correction. The change request must be bounded, examined, logged, and answered proportionately.
Correction and revision log
The register below is filterable. In later actual cases it should show initial publication, material correction, reopening, unpublication, stricter anonymisation, and closure.
A log entry must always point back to the concrete case object. The change should not live as a loose comment without a link to version, date, reason, and scope.
8 visible log entries
No log entries match the filters.
REV-2026-001
Initial publication of the training claim
Published the first synthetic example through S1–S10 with source register, claim matrix, findings, and proportionate correction.
No correction or reopening is open.REV-2026-002
Initial publication of the risk dashboard
Published a synthetic cross-audit where all A1–A7 tracks are used without invalid transfer of findings.
No correction or reopening is open.Published the protocol for open sources, public records, quotation, version, party status, correction trace, and publication grounds.
No correction or reopening is open.Published the protocol for reidentification testing, source protection, safe contradiction, harm assessment, correction channel, and controlled closure.
No correction or reopening is open.REV-2026-005
Initial publication of the public case register
Published the filterable register for synthetic examples, protocols, actual cases, status, publication level, domain, and correction status.
No correction or reopening is open.Published CSV and JSON extracts from the case register and correction log with field documentation, export date, schema version, language-pair control, and validation report.
The validation report tests structure and language pairing, not the truth of future case findings.Published a public JSON register for examples, protocols, register entries, versions, links, domains, audit types, and correction status.
This is the first schema version of the JSON register.Published a combined log for changes, corrections, reopenings, unpublications, and version changes in the case and protocol system.
This is the current first version of the log.Fields and minimum requirements
A change log is useful only if it has stable fields. Otherwise correction itself becomes a new source of uncertainty.
The minimum requirements apply both to small clarifications and larger material corrections. The entry may be brief, but the code, date, and link to the object must remain stable.
Stable log code
Each change receives its own REV code that is not reused.
Object link
The log entry must point to a case, example, protocol, or register entry with stable code and link.
Version before and after
Previous and new version must be recorded; initial publication uses a dash or null version as starting point.
Change type
Initial publication, clarification, material correction, reopening, unpublication, and method revision must be separated.
Reason for change
The log must show whether the change arises from error, new material, anonymisation risk, method improvement, or another reason.
Scope
It must be visible whether the change concerns language, source, finding, status, publication level, correction, or actual consequence.
Status
Open, under review, corrected, closed, unpublished, or logged must not be collapsed.
Downstream trace
Where the change affects other pages, register entries, downloads, or copies, this must be recorded.
| Log | Object | Version | Type | Reason | Status |
|---|---|---|---|---|---|
| REV-2026-001 | RA-E-2026-001 | — → v1.0 | Initial publication | Pedagogical example | Closed |
| REV-2026-008 | RG4 | — → v1.0 | Initial publication | Publish register exports | Logged |
| REV-2026-007 | RG2 | — → v1.0 | Initial publication | Publish machine-readable register | Logged |
| REV-2026-006 | RG3 | — → v1.0 | Initial publication | Establish shared correction trace | Logged |
| REV-2026-0XX | RA-C-2026-001 | v1.0 → v1.1 | Material correction | New source changes P003 | Under review |
Change types
The change type must be neither exaggerated nor minimized. A linguistic clarification is not automatically a material correction, but a material correction must not be hidden as a style edit.
Unpublication is not the same as deletion of methodological responsibility. Where a text is removed, the log should, as far as safe and appropriate, show that it happened and why.
| Code | Type | Function | Not equivalent to |
|---|---|---|---|
| T1 | Initial publication | Records the first public version of an object. | That the content is final or unchangeable. |
| T2 | Clarification | Clarifies language, boundary, or status without changing the main finding. | A material admission of error. |
| T3 | Material correction | Changes source use, claim, finding, status, correction, or consequence. | Only style or layout. |
| T4 | Reopening | Opens a closed or published object for renewed examination. | That previous findings automatically fall away. |
| T5 | Unpublication | Removes or limits public access for safeguard, error, or process reasons. | Hidden deletion of responsibility. |
| T6 | Method revision | Changes protocol, register fields, or publication requirements. | Automatic correction of old cases without renewed examination. |
From notice to new version
Correction needs process. It does not begin with rewriting and it does not end with new text alone.
The workflow preserves that the reporter, affected party, source, auditor, and public reader may have different rights and needs.
Receipt
New material, correction request, or internally identified error receives date, sender status, and safe storage.
Relevance test
Determine which object, sources, claims, findings, or register fields may be affected.
Interim safeguard
Where harm, reidentification, or serious error is possible, publication may be limited while review is ongoing.
Renewed examination
The affected element is examined again against source, counter-material, contradiction, and publication safeguards.
Change decision
Determine whether the matter requires no change, clarification, material correction, reopening, or unpublication.
New version
A new public version receives version number, date, and visible note where relevant.
Downstream correction
Registers, sitemap, links, downloads, translations, and other copies are considered.
Closure
The log entry receives status and reopening conditions where further material may change the outcome.
Safeguards and misuse controls
The correction log should make change visible without creating new privacy, safety, or harm problems.
It must also not become a rhetorical weapon where every wording adjustment is presented as collapse of the entire case.
No hidden rewriting
Material changes must not be hidden in silent edits without a log entry.
No exaggerated admission
Clarifications must not be presented as larger errors than they are.
Privacy and source protection
Correction trace must not reveal more raw material, sources, or identity than necessary.
Safe correction channel
Reports of error or reidentification must be possible without public exposure.
Parties and contradiction
Material corrections affecting parties must be assessed for renewed contradiction and safe notification.
Transfer safeguard
Correction in one claim or case is not automatic correction of all other findings.
Unpublication with trace
Where appropriate, the log should show that something was unpublished even if the content is no longer public.
Audit the log
The log is itself an auditable document with version, limitation, and correction channel.
Further programme
Correction and revision log
Combined display of changed entries, new version, correction type, reopening, unpublication, reason, and status.
Machine-readable register file
Public JSON register for examples, protocols, registers, revision log, statuses, versions, and links.
Downloadable register exports
CSV and JSON extracts of the case register and correction log with validation report.
Correction form
Standard channel for factual errors, reidentification risk, party response, and new documentation.