Beacon · Phase II · Production Architecture

Versioning & Supersession

Versioning & Supersession defines how Beacon preserves canonical identity and historical discovery state when a Discovery Signal changes, a source changes, an authoritative status changes, or an earlier signal becomes obsolete. Discovery is temporal; Beacon must preserve what was known then without confusing it with what is known now.

Preserve the observation. Preserve the change. Preserve which representation is current.

Purpose

The model answers:

When does a Discovery Signal need a new version?
When should a signal be superseded?
When should a new BEAC object be created instead?
What happens when the source changes?
How is historical state preserved?

Temporal Principle

Beacon records discovery at a point in time. A later observation may change Beacon's current understanding without invalidating the historical fact that the earlier observation occurred.

What Beacon observed then
≠
What Beacon observes now

Identity and Version Are Separate

Canonical Identifier → BEAC-2026-0001
Version → governed revision of BEAC-2026-0001

The BEAC identifier remains stable across revisions of the same Discovery Signal. Version information must not be embedded into or replace the canonical identifier.

Same Object

New Version

A new version is appropriate when the canonical Discovery Signal remains the same institutional object but its representation changes materially.

  • Discovery Metadata materially corrected or expanded
  • Provenance materially corrected or expanded
  • A reference is corrected
  • A relationship representation changes
  • A later observation updates current context without creating a distinct discovery subject
New Object

New Discovery Signal

A new BEAC identifier is appropriate when the later discovery is institutionally distinct rather than merely a revision of the earlier signal.

  • New discovery subject
  • New independent occurrence
  • Materially different discovered relationship
  • Distinct observation that should stand as its own canonical record
  • Different institutional discovery requiring independent lifecycle

Versioning Decision

Same canonical discovery subject?
↓ yes
Does the change materially alter the Beacon representation?
↓ yes
New Version

Distinct discovery subject or independently meaningful discovery?
↓ yes
New Discovery Signal / New BEAC Identifier

The Beacon Discovery Methodology will later define the operational review used to make this determination.

Minor Change

Not every editorial change should create a new institutional version.

Examples may include:

  • Non-substantive formatting
  • Presentation-only changes
  • Accessibility improvements that do not alter meaning
  • Technical corrections outside canonical content
Exact materiality thresholds remain subject to Methodology and production proof.

Material Change

A material change affects the institutional meaning, evidence, interpretation, or reviewability of the Discovery Signal.

  • Changed discovery assertion
  • Changed provenance basis
  • Changed canonical reference
  • Changed relationship meaning
  • Changed current-source context

Conceptual Version Chain

BEAC-2026-0001 · Version 1
↓ revised by
BEAC-2026-0001 · Version 2
↓ revised by
BEAC-2026-0001 · Version 3

Earlier versions remain part of the institutional history. Version 3 becoming current does not erase Versions 1 or 2.

Current Version

Beacon should identify which version currently represents the canonical Discovery Signal.

Canonical Identity → stable
Current Version → may change

Historical Versions

Earlier versions should remain traceable with their prior content, timestamps, provenance, and relationships to later versions.

Current does not mean only.
Historical does not mean deleted.

Supersession

Supersession is used when an earlier signal or version should no longer be treated as the current representation and a later object or version replaces it for current use.

Earlier Signal / Version
↓ superseded by
Later Signal / Version

Supersession preserves the earlier institutional record while clearly directing current interpretation to the later representation.

Version Supersession

A later version may supersede an earlier version under the same BEAC identifier.

BEAC-2026-0001 v1
↓ superseded by
BEAC-2026-0001 v2

Signal Supersession

A distinct Discovery Signal may supersede an earlier signal when the later discovery is institutionally separate but replaces the earlier signal for current discovery use.

BEAC-2026-0001
↓ superseded by
BEAC-2026-0002

Lifecycle and Supersession

Superseded is already a canonical Beacon lifecycle state.

Draft → Active → Superseded

A signal entering Superseded should identify the governed replacement when one exists. The replacement remains a separate object or version according to the applicable versioning decision.

Resolved vs. Superseded

These lifecycle outcomes have different meanings.

Resolved → the discovery condition has reached a governed conclusion or no longer requires active discovery treatment.

Superseded → a later representation replaces the earlier one for current use.

Withdrawn vs. Superseded

Withdrawal does not necessarily imply a replacement.

Withdrawn → Beacon removes its own signal from active institutional standing for a governed reason.

Superseded → another representation replaces it.

When a Source Changes

A source change is a new observation. It does not rewrite what Beacon observed earlier.

Source State A
↓ observed at Time 1
Beacon historical observation preserved

Source State B
↓ observed at Time 2
Beacon records later observation / appropriate revision

Source Content Changes

If source content materially changes, Beacon should preserve the original observation and determine whether the later observation requires:

  • Re-observation metadata
  • A new version
  • A new Discovery Signal
  • Supersession
  • Resolution

Source Availability Changes

If a source moves or becomes unavailable, Beacon should not silently delete the original reference.

  • Preserve original source identity
  • Preserve original provenance
  • Record later availability condition
  • Update current representation when material

When Authoritative Status Changes

A referenced Suite institution may change the lifecycle, status, version, or standing of its own canonical object.

Source institution changes its object
↓
Beacon observes the changed source-owned status
↓
Beacon preserves attribution and determines what change is required to its own Discovery Signal

Beacon does not perform the source institution's status change. It records its own later observation of that change.

Authority Boundary

Versioning a Beacon signal never versions the referenced source object.

Beacon versions → Beacon Discovery Signal
Source institution versions → source canonical object

Reference Does Not Transfer Authority

If a source object's status changes, Beacon may update the attributed source status it observed.

Beacon reports the change.
Beacon does not own the change.

Obsolete Published Signals

Publication does not freeze a Discovery Signal forever. A published signal may later become obsolete.

Beacon should preserve:

  • The published historical representation
  • The reason it is no longer current
  • The later version or signal when applicable
  • The supersession, resolution, or withdrawal relationship
  • The relevant timestamps
Obsolete does not mean erased.

Published + Superseded

Publication State and Lifecycle State remain separate.

Publication State → Published
Lifecycle State → Superseded

A historically published signal may remain publicly reviewable while clearly marked as superseded.

Published + Resolved

A published signal may remain part of the public institutional record after resolution.

Publication does not require perpetual Active status.

No Silent Overwrite

Material institutional content should not be silently replaced in place.

Preserve prior representation
+ record the change
+ identify the current representation
= reviewable institutional history

Silent overwrite destroys the temporal evidence Beacon exists to preserve.

Correction

A correction addresses an error in Beacon's own representation.

Error discovered
↓
Correction documented
↓
New version when material

Update

An update reflects later information or observation rather than merely correcting an earlier error.

Earlier observation remains historically valid as an observation.
Later information changes current context.

Reason for Change

Material revisions and supersession should preserve why the change occurred.

Potential architectural reasons include:

  • Correction
  • Source Update
  • Source Status Change
  • New Observation
  • Relationship Change
  • Provenance Correction
  • Superseding Discovery
  • Resolution
  • Withdrawal
Final controlled change-reason vocabulary remains unfrozen.

Version Timestamps

Version history should preserve meaningful temporal distinctions.

  • Version created time
  • Observation time supporting the change
  • Effective/current time when needed
  • Publication time when published
  • Supersession time when applicable

Provenance Continuity

A new version should preserve the provenance supporting the earlier representation and separately identify provenance supporting the change.

Old basis remains reviewable.
New basis becomes reviewable.
The transition remains reviewable.

Relationship Continuity

When relationships change, Beacon should preserve both the earlier relationship representation and the later governed state.

Relationship at Time 1
↓ changed observation
Relationship at Time 2

Do not rewrite Time 1 as though Time 2 had always been true.

Version Validation

A material new version should pass applicable Beacon Validation before becoming the current Active representation.

Revised Draft
↓ Validation
Current Active Version

Supersession Validation

Supersession should identify the earlier object, the replacement, the reason, and the effective transition sufficiently for review.

Conceptual Version Structure

version:
  canonical_identifier
  version
  previous_version
  change_reason
  change_summary
  supporting_provenance
  created_at
  current

Architectural only. Exact machine-readable property names and version notation remain unfrozen.

Conceptual Supersession Structure

supersession:
  superseded_object
  superseding_object
  reason
  effective_at
  provenance

Supersession may operate between versions of one BEAC identity or between distinct BEAC objects, depending on the institutional nature of the change.

Relationship to Lifecycle

Versioning changes representation. Lifecycle describes institutional state.

Version → which governed representation?
Lifecycle → what institutional state?

Relationship to Publication

Publication determines which representation is publicly released and how historical versions or superseded signals remain visible.

Versioning preserves history.
Publication governs public exposure.

Relationship to Provenance

Provenance explains the basis for the original observation and for later changes.

Relationship to Authority

Beacon versions only its own canonical Discovery Signals. Source institutions retain authority over changes to their own objects.

What Is Now Established

  • Canonical BEAC identity and version are separate
  • The BEAC identifier remains stable across revisions of the same signal
  • Material changes require reviewable version treatment
  • Distinct discoveries require new BEAC objects rather than identity reuse
  • Earlier versions remain traceable
  • Beacon should identify the current version
  • Supersession preserves rather than erases earlier institutional state
  • Supersession may occur between versions or distinct signals
  • Source changes create later observations; they do not rewrite earlier observations
  • Source-owned status changes remain source-owned and attributed
  • Published signals may later become Superseded, Resolved, or Withdrawn
  • Publication State and Lifecycle State remain separate
  • Material institutional content must not be silently overwritten
  • Corrections and later updates are conceptually distinct
  • Material changes should preserve reason, timestamps, provenance, and continuity

What Remains Unfrozen

  • Exact version notation
  • Machine-readable version property names
  • Materiality threshold for mandatory new versions
  • Controlled change-reason vocabulary
  • Whether minor editorial revisions receive separate technical revision tracking
  • Formal current-version pointer mechanics
  • Version publication rules
  • Correction notice format
  • Supersession effective-time rules
  • Whether some changes mandate a new BEAC identifier by Signal Type
These should be resolved through Publication, Methodology, and first production operation rather than frozen prematurely.

Governing Rules

Preserve canonical identity.
Preserve every material representation.
Preserve what Beacon observed at each relevant time.
Preserve why the representation changed.
Preserve provenance supporting the change.
Identify what is current.
Never silently rewrite institutional history.

Discovery changes. History must not.

Current Status

Beacon Status → Continuing Development
Phase → Phase II — Production Architecture
Entry Model → Defined
Signal Types → Defined
Lifecycle → Defined
Identifier Standard → Defined
Schemas → Defined
Validation → Defined
Discovery Provenance → Defined
Authority & Reference Model → Defined
Relationship Model → Defined
Versioning & Supersession → Defined
Publication Model → Next
First Production Discovery Signal → Not yet created
Discovery changes. History must not.