Beacon · Phase II · Production Architecture

Discovery Signal Lifecycle

The Discovery Signal Lifecycle defines how a Beacon-owned Discovery Signal moves from an observed discovery condition into a governed institutional object, through review and publication, and eventually through later change or closure.

The lifecycle must distinguish the discovery of a potential signal from creation of the canonical Beacon object, and it must preserve later history without silently rewriting what Beacon previously published.

Purpose

The Entry Model established Status as a structural component of a Discovery Signal. The Lifecycle architecture determines what institutional states that status must represent and which transitions are meaningful.

Entry Model → establishes Status.

Lifecycle → defines the governed progression of the Discovery Signal.

Starting Candidate

Phase II began with a provisional sequence:

Identified → Created → Reviewed → Published → Updated / Superseded / Resolved

That sequence is useful as an inquiry starting point, but it should not be frozen merely because it was proposed.

Lifecycle Inquiry

Review of the candidate sequence reveals that it combines three different concepts:

Pre-object condition → Identified
Lifecycle state → Draft, Active, Superseded, Resolved, Withdrawn
Publication state → Unpublished, Published

Separating these concepts produces a cleaner institutional model and avoids treating every action as though it were the same kind of state.

Identified Is Pre-Object

Identified describes a potential discovery that Beacon has recognized as a candidate for institutional treatment.

  • No canonical Discovery Signal is required to exist yet
  • No Beacon identifier need be assigned yet
  • The observation may still be rejected or abandoned
  • Identification belongs to discovery intake rather than the canonical object's lifecycle
Identified → candidate discovery condition, not a frozen Discovery Signal lifecycle state.

Created Is an Event

Created is best understood as the event that brings the canonical Discovery Signal into existence.

  • The Beacon-owned object now exists
  • Its identity and initial content are established
  • Creation time can be preserved
  • The resulting lifecycle state becomes Draft
Created → event
Draft → resulting lifecycle state

Reviewed Is an Event

Reviewed describes an institutional action performed on a Draft Discovery Signal.

  • Review evaluates the candidate object
  • Review may return the object for revision
  • Review may support progression toward publication
  • Review does not itself need to become a durable lifecycle state
Reviewed → event or process outcome, not necessarily a persistent lifecycle state.

Published Is a Publication State

Published describes public availability rather than the entire institutional condition of the signal.

  • A signal may be active and published
  • A superseded signal may remain published for historical traceability
  • A resolved signal may remain publicly discoverable
  • Publication therefore should not replace Lifecycle State
Lifecycle State and Publication State should remain separate dimensions.

Proposed Canonical Lifecycle States

After separating candidate conditions, events, and publication state, the following lifecycle vocabulary is proposed as the Beacon architectural model:

Draft → Active → Superseded / Resolved / Withdrawn

These states describe the institutional condition of the Discovery Signal itself.

Draft

A Draft Discovery Signal exists as a Beacon-owned object but has not yet completed the institutional process required for active publication.

  • Canonical object exists
  • Identity may be assigned according to the later Identifier Standard
  • Content may still be revised
  • Review and Validation may still be pending
  • Publication should not be assumed
Draft begins the lifecycle of the canonical Beacon object.

Active

An Active Discovery Signal is the current institutionally accepted Beacon signal for the discovery it represents.

  • Required production conditions have been satisfied
  • The signal is institutionally current
  • Publication may be associated with Active status
  • Later observations may cause update, supersession, or resolution
Active describes current institutional standing, not source authority.

Superseded

A Superseded Discovery Signal has been replaced by a later Beacon signal or governed version that now carries the current discovery context.

  • Prior signal remains part of institutional history
  • Superseding reference should be preserved
  • Prior publication need not disappear
  • Supersession does not mean the original signal was invalid when issued
Supersession preserves history rather than silently rewriting it.

Resolved

A Resolved Discovery Signal no longer requires active discovery attention because the condition represented by the signal has reached a governed conclusion or closure.

  • Resolution reason should be attributable
  • Resolution may reference a later source state or object
  • The original signal remains historically traceable
  • Resolved does not mean deleted
Resolution closes active discovery significance while preserving the record.

Withdrawn

A Withdrawn Discovery Signal has been intentionally removed from active institutional standing by Beacon.

  • May reflect error, invalid basis, or institutional withdrawal
  • Withdrawal reason should be preserved
  • Withdrawal should not erase prior existence
  • Withdrawal differs from supersession and resolution
Withdrawn preserves accountability when Beacon itself determines the signal should no longer stand.

Why No Archived State Yet?

An Archived state is not currently necessary to describe the institutional meaning of a Discovery Signal.

  • Superseded signals can remain preserved
  • Resolved signals can remain preserved
  • Withdrawn signals can remain preserved
  • Storage or archival location is not automatically a lifecycle meaning
Archived remains unfrozen unless production demonstrates a distinct institutional need.

Publication State

Publication is modeled separately from Lifecycle State.

Publication State → Unpublished / Published

The dedicated Publication Model will determine exact publication requirements, authorization, timestamps, and public representation.

Update Is an Action

Updated should not be treated as a permanent lifecycle state.

An update is an action that changes the governed Beacon object or results in a later version or signal.

Update → action
Version / supersession → governed consequence

Lifecycle vs. Source Status

Beacon's lifecycle describes the Discovery Signal, not the lifecycle of the referenced source object.

Beacon Lifecycle State → condition of the Discovery Signal

Source Status → condition maintained by the source institution

A source may change state and cause Beacon to create, update, supersede, or resolve a signal, but Beacon does not own the source state.

Conceptual Lifecycle Flow

Candidate Discovery Identified
↓
Discovery Signal Created
↓
Draft
↓ Review / Validation / Publication Decision
Active
↓ Later Observation or Institutional Action
Superseded · Resolved · Withdrawn

Publication runs alongside this lifecycle as a separate state dimension rather than replacing it.

Transition Discipline

Lifecycle transitions should eventually require an attributable institutional basis.

  • Draft → Active only after required production conditions
  • Active → Superseded only when a governed replacement exists
  • Active → Resolved only when a supported resolution exists
  • Draft or Active → Withdrawn only with a preserved reason
  • Prior states should remain traceable
Exact transition gates belong to later Validation, Versioning, Publication, and Methodology architecture.

What Remains Unfrozen

This page establishes the lifecycle architecture without prematurely deciding every implementation rule.

  • Machine-readable lifecycle values
  • Exact transition validation rules
  • Who or what authorizes transitions
  • Whether Draft objects receive permanent identifiers immediately
  • Update/version mechanics
  • Supersession mechanics
  • Resolution evidence requirements
  • Publication Gate design

Authority Boundary

A Beacon lifecycle transition changes the institutional condition of the Discovery Signal only.

Beacon lifecycle change ≠ source lifecycle change
Beacon resolution ≠ source resolution
Beacon withdrawal ≠ source withdrawal

Reference does not transfer authority.

Relationship to the Entry Model

Lifecycle now gives architectural meaning to the Status component of the Discovery Signal Entry Model:

Lifecycle State → Draft / Active / Superseded / Resolved / Withdrawn
Publication State → Unpublished / Published

The later production schema will determine how these dimensions are represented machine-readably.

Current Status

Beacon Status → Continuing Development
Phase → Phase II — Production Architecture
Entry Model → Defined
Signal Types → Defined
Lifecycle Architecture → Defined
Lifecycle States → Draft · Active · Superseded · Resolved · Withdrawn
Publication Dimension → Unpublished · Published
Transition Enforcement → Pending
Production Proof → Pending
Preserve the state. Preserve the transition. Preserve the reason.