Beacon · Phase II · Production Architecture

Beacon Identifier Standard

The Beacon Identifier Standard establishes the canonical identifier convention for Beacon-owned Discovery Signals. It gives every production signal a stable, unique, human-readable institutional identity.

This standard defines Beacon's equivalent of SC-CERT-2026-0001, SREG-2026-0001, CHR-2026-0001, and ANCH-2026-0001.

Purpose

A production Discovery Signal must be independently identifiable across public pages, schemas, indexes, references, relationships, version history, and future machine-readable interfaces.

Stable identity allows Beacon to preserve continuity even as metadata, status, publication state, or related source information changes.

Canonical Decision

The canonical Beacon Discovery Signal identifier prefix is:

BEAC

The first production Discovery Signal will therefore use the pattern:

BEAC-2026-0001

Canonical Identifier Format

BEAC-YYYY-NNNN

The identifier consists of three governed components:

  • BEAC → Satoshium Beacon institutional prefix
  • YYYY → four-digit year of canonical signal creation
  • NNNN → zero-padded sequential number within that year

1. Institutional Prefix

BEAC identifies the object as institutionally owned by Satoshium Beacon.

  • Short enough for human use
  • Distinct from other Suite identifiers
  • Clearly recognizable as Beacon
  • Does not encode Signal Type
  • Remains stable even if Beacon classifications evolve
Identifier → institutional identity.
Signal Type → discovery classification.

These concerns remain separate.

2. Year Component

YYYY records the calendar year in which the canonical Discovery Signal is created.

  • Four digits
  • Based on canonical creation year
  • Does not change if the signal is later updated
  • Does not change if the signal is superseded or resolved
The year is part of identity, not a statement of current status.

3. Sequence Component

NNNN is a four-digit, zero-padded sequence assigned within the creation year.

  • 0001 is the first canonical Discovery Signal of the year
  • 0002 is the second
  • Sequence increases monotonically
  • Assigned numbers are not reused
Example → BEAC-2026-0001

Why BEAC?

The prefix was selected to preserve institutional clarity rather than abbreviate the object as though the object type alone were the institution.

  • Beacon owns Discovery Signals
  • Beacon may later own additional governed discovery structures
  • Signal Type remains a separate field
  • The prefix aligns with Suite precedent for institution-recognizable identifiers
The identifier says who owns the object.
The Entry Model says what the object is.

Suite Identifier Context

Beacon's identifier joins the existing production-proven Suite object conventions:

Certifier → SC-CERT-2026-0001
Registry → SREG-2026-0001
Chronicle → CHR-2026-0001
Anchor → ANCH-2026-0001
Beacon → BEAC-2026-0001

These identifiers remain institution-specific. They do not imply that a single object moves through the Suite.

Assignment Point

The Entry Model and Lifecycle distinguish Identified from the creation of the canonical Beacon object.

The identifier should be assigned when the canonical Discovery Signal is Created and enters Draft.

Identified → no permanent Beacon identifier required
Created → identifier assigned
Draft → canonical object exists

Identifier Permanence

Once assigned, a Beacon identifier is permanent.

  • It is not changed by publication
  • It is not changed by lifecycle transition
  • It is not changed by resolution
  • It is not reused after withdrawal
  • It remains attached to the historical object after supersession
Identity persists even when institutional standing changes.

Versioning

Version information must not be embedded into the canonical Beacon identifier.

Canonical Identifier → BEAC-2026-0001
Version → separate governed field

This keeps the stable object identity distinct from later version mechanics.

Signal Type

Signal Type must not be encoded into the identifier.

BEAC-2026-0001
Signal Type → Certification

A signal's classification belongs in the Entry Model and controlled vocabulary, not in its permanent identity.

Status

Lifecycle and publication status must not be encoded into the identifier.

Identifier → BEAC-2026-0001
Lifecycle State → Active
Publication State → Published

Status may change. Identity must not.

Source Identity

Referenced source identifiers remain separate from the Beacon identifier.

Beacon Signal → BEAC-2026-0001
Referenced Anchor Object → ANCH-2026-0001

Beacon preserves the relationship between the identifiers without collapsing them into one object.

Identifier Grammar

BEAC-[four-digit year]-[four-digit sequence]

Conceptual pattern:

^BEAC-[0-9]{4}-[0-9]{4}$

Formal machine validation will be established later through Beacon Schemas and Validation.

Examples

  • BEAC-2026-0001 → first Beacon Discovery Signal created in 2026
  • BEAC-2026-0002 → second Beacon Discovery Signal created in 2026
  • BEAC-2027-0001 → first Beacon Discovery Signal created in 2027

Invalid Examples

  • BEAC-26-0001 → year too short
  • BEAC-2026-1 → sequence not zero-padded
  • BEAC-CERT-2026-0001 → Signal Type improperly embedded
  • BEAC-2026-0001-v2 → version improperly embedded
  • BEAC-ACTIVE-2026-0001 → status improperly embedded

Sequence Governance

Sequence assignment must preserve uniqueness and non-reuse.

  • Each created canonical Discovery Signal receives one sequence number
  • A withdrawn identifier remains consumed
  • A superseded identifier remains consumed
  • A resolved identifier remains consumed
  • Numbers should not be reassigned to repair gaps
Gaps are preferable to identity reuse.

Human-Readable Identity

The Beacon identifier is intended to be stable enough for:

  • public citation
  • cross-Suite references
  • URLs
  • indexes
  • schemas
  • relationship mappings
  • version history
  • future APIs and machine discovery

Canonical Public Path

The eventual public representation of a production Discovery Signal should be addressable by its identifier.

/beacon/records/BEAC-2026-0001/

The Records and Individual Discovery Signal phases will determine the final public representation.

Authority Boundary

A Beacon identifier establishes the identity of the Beacon-owned Discovery Signal only.

BEAC-2026-0001 identifies a Beacon Discovery Signal.
It does not rename, replace, or absorb the identity of any referenced canonical object.

Reference does not transfer authority.

What Remains Unfrozen

The canonical identifier convention is established, while downstream implementation details remain pending.

  • Machine-readable schema enforcement
  • Sequence-assignment mechanism
  • Collision prevention implementation
  • Registry or ledger mechanism for issued Beacon identifiers
  • Public routing implementation
  • API behavior
  • Version-reference syntax outside the canonical identifier
Identifier meaning is now frozen. Identifier implementation will be governed by later architecture.

Current Status

Beacon Status → Continuing Development
Phase → Phase II — Production Architecture
Entry Model → Defined
Signal Types → Defined
Lifecycle → Defined
Identifier Standard → Defined
Canonical Prefix → BEAC
Canonical Pattern → BEAC-YYYY-NNNN
First Reserved Production Pattern → BEAC-2026-0001
Schema Enforcement → Pending
First Production Discovery Signal → Not yet created
Identity should remain stable even when everything around it changes.