COUNTERPEDIA / GUIDE
Counterpedia ↗
CAPABILITIES / 06

Understand how knowledge changes

Understand what changed between two recorded versions, what evidence or decision was attached to the change, and which version you should cite.

Full-release guideWriting in progress

Understand how knowledge changes

Product promise

Understand what changed between two recorded versions, what evidence or decision was attached to the change, and which version you should cite.

Start with a changing investigation

Early reporting about the 2023 loss of OceanGate’s Titan submersible and the later accident investigations do not carry identical information. The U.S. Coast Guard Marine Board report and the NTSB’s investigation docket are identifiable sources with different publication and procedural contexts. A warning written before the casualty and an investigator’s later interpretation of physical evidence also answer different questions.

That is why history matters: a later statement may reflect new material, a corrected description, a changed interpretation, or merely a newer edition. The date alone cannot tell you which.

Read the history as distinct events

  1. Open a record with a visible history or version list. Identify the current version and one earlier version. If your chosen object has no recorded history, choose another; do not invent a revision.
  2. Compare the same statement in the two versions. Identify what changed: language, citation, status, qualifier, or underlying object identity.
  3. Read any recorded reason or decision attached to that revision. Was a source added? A correction made? An interpretation reconsidered? Note the reason as recorded, not as a retrospective guess.
  4. Open the cited evidence where permissible. A report issued in 2025 may analyze data collected in 2023 or warnings written in 2018. Keep the event, evidence and revision dates separate.
  5. Return to the version you need to cite. Capture its edition, version identifier or timestamp, and any successor link actually shown.

Expected result: you can state what changed, when it was recorded, and what reason was supplied, without treating a newer version as automatically more reliable.

Admission history page for record TH-S01 showing the lifecycle panel with a single CURRENT lineage state and one admission event card dated 2026-08-12.
Admission history for record TH-S01: a single retained admission event (2026-08-12) in the governed ledger, described as standing history rather than a prose-edit log. One recorded state cannot by itself support a version comparison.Captured from /records/TH-S01/history at e661b48 on 2026-10-28
C06-02 Previous and current revisions highlighting precise changed text. Planned capture; not an image of a verified product state.

Understand refusals and supersession

A refusal, reconsideration or supersession is a recorded action with its own scope. A refused claim may have an explicit reason or a condition for reopening; it is not necessarily a permanent judgment on the underlying proposition. A successor may replace an earlier record for current reading without erasing the earlier record’s history.

C06-03 Recorded change reason, refusal, or supersession with provenance. Planned capture; not an image of a verified product state.

When a record has no recorded reason for a change, write reason not supplied in this view, not there was no reason. Do the same with a missing prior version. That is an honest boundary on what the history establishes.

What to take away

Leave with a specific earlier and current version, one identifiable change, the cited basis if available, and a version-aware citation. Following a record through time walks through the comparison; Understanding evidence and uncertainty explains the distinct evaluation states.

Related manual chapters

Next capability

Check information

Searches guide chapters and tutorials, not Counterpedia's knowledge corpus.