Beacon · Discovery Signal Entry Model

Discovery Signal Entry Model

The Discovery Signal Entry Model defines the canonical structure of a Beacon-owned Discovery Signal. It establishes the minimum institutional components required to identify a signal, describe what was discovered, preserve its source and provenance, reference related canonical objects, record discovery metadata, track time and version, express status, and preserve relationships.

This page defines the object foundation established during Beacon Phase II. The later production architecture for signal types, lifecycle, identifiers, schemas, validation, provenance, authority, relationships, versioning, publication, records, methodology, and production now governs that object.

Purpose

Beacon cannot define production rules until it defines what a production Discovery Signal is. The Entry Model provides that canonical object boundary.

Phase I answered: What is Beacon?

Phase II begins by answering: What exactly does Beacon create?

Canonical Object

Beacon's canonical production object is the Discovery Signal. Discovery Metadata is a Beacon-owned supporting structure that supports and describes that canonical object.

Beacon → Discovery Signal

The Discovery Signal is institution-owned by Beacon. Referenced objects remain owned by their originating institutions or external sources.

Canonical Entry Structure

A production Discovery Signal should contain sufficient information to establish identity, subject, discovery context, source authority, provenance, relationships, and lifecycle context without assuming authority over the object or information it references.

Identity → Subject → Signal Type → Source → Provenance → Canonical References → Discovery Metadata → Timestamps → Version → Status → Relationships

1. Identity

Identity distinguishes one Beacon Discovery Signal from every other Beacon object.

  • Beacon Discovery Signal Identifier
  • Human-readable title or label
  • Beacon institutional ownership
  • Object type: Discovery Signal
The governed Beacon Identifier Standard now uses BEAC-YYYY-NNNN. The first production identifier is BEAC-2026-0001.

2. Subject

Subject identifies what the Discovery Signal is about.

  • Subject name or description
  • Subject type or classification
  • Relevant jurisdiction, system, entity, record, event, or artifact
  • Optional subject identifier when one exists
Subject identifies the focus of discovery. It does not establish authority over that subject.

3. Signal Type

Signal Type classifies the nature of the discovery being recorded.

  • General discovery category
  • Specialized signal profile when applicable
  • Controlled vocabulary value

The initial governed Signal Type vocabulary is Information, Jurisdiction, Certification, Registry, Historical, Integrity, Trust, and Relationship.

The first production Discovery Signal, BEAC-2026-0001, uses the primary Signal Type Certification.

Signal Type ≠ Source Object Type ≠ Source Status.

4. Source

Source identifies where the discovered information originated.

  • Source Institution or External Source
  • Source name
  • Source identifier when available
  • Canonical or public source location
  • Source object type when applicable
Source must remain visible because discovery does not transfer authority.

5. Provenance

Provenance preserves the traceable path between the Discovery Signal and the information that caused it to exist.

  • Observed source
  • Observation context
  • Observation method or mechanism
  • Relevant supporting reference
  • Discovery actor or process when appropriate
Provenance should make the signal reviewable rather than merely assertive.

6. Canonical-Object References

Discovery Signals may reference canonical objects maintained by other Suite institutions.

  • Atlas Authoritative Intelligence
  • Certifier Certification Package
  • Registry SREG
  • Chronicle Entry
  • Anchor Integrity Reference
  • Attestor Trust Statement
  • Navigator workflow reference when relevant
A reference establishes connection, not ownership.

Reference does not transfer authority.

7. Discovery Metadata

Discovery Metadata preserves the context needed to interpret, filter, trace, and rediscover the signal.

  • Discovery context
  • Classification
  • Relevant status observed at discovery
  • Jurisdiction or domain context
  • Search or workflow context
  • Keywords, tags, or controlled values where governed
  • Relationship metadata
Discovery Metadata is supporting structure for the Discovery Signal. It does not become a second canonical Beacon object and does not replace the canonical source object.

8. Timestamps

Time must distinguish when information was observed from when the Beacon object itself was created or changed.

  • Discovered At / Observed At
  • Created At
  • Updated At
  • Published At, if published
  • Last Observed, when applicable
Lifecycle and publication architecture now distinguish observation, creation, update, and publication time. Exact machine serialization remains subject to the eventual frozen schema.

9. Version

Version identifies the governed state of the Beacon Discovery Signal over time.

  • Signal Version
  • Previous Version reference when applicable
  • Supersession information when applicable
Versioning & Supersession architecture is now defined. The BEAC identifier remains stable across versions, and material changes require preserved version history rather than silent overwrite.

10. Status

Status records the current institutional state of the Discovery Signal.

  • Lifecycle state
  • Publication state
  • Resolution or supersession state when applicable
Canonical lifecycle is Draft → Active → Superseded / Resolved / Withdrawn. Publication is governed separately as Unpublished / Published.

11. Relationships

Relationships connect a Discovery Signal to sources, canonical objects, other signals, workflow context, or later institutional activity.

  • Source relationship
  • Canonical-object relationship
  • Related-signal relationship
  • Version / supersession relationship
  • Workflow relationship
  • Other governed relationship types
The Relationship Model now governs Source, Canonical Object, Related Signal, Version, Supersession, Workflow, and External relationship classes. Exact machine predicates remain intentionally unfrozen.

12. Institutional Ownership

Every Discovery Signal must preserve the distinction between Beacon ownership and source authority.

  • Beacon owns the Discovery Signal
  • Beacon owns the supporting discovery metadata associated with its Discovery Signals
  • The source institution owns its canonical object
  • External sources remain external
Discovery connects responsibilities without collapsing them.

Conceptual Discovery Signal Skeleton

The Entry Model can be represented conceptually as the following object. This remains an architectural skeleton rather than a frozen machine-serialization schema.

{
  "discovery_signal": {
    "identity": {},
    "subject": {},
    "signal_type": "",
    "source": {},
    "provenance": {},
    "canonical_references": [],
    "discovery_metadata": {},
    "timestamps": {},
    "version": {},
    "status": {},
    "relationships": []
  }
}
The conceptual production architecture is now defined. Exact machine field serialization, schema dialect, and frozen .schema.json constraints remain intentionally open.

Required vs. Conditional Components

The Entry Model establishes structural categories before finalizing which fields are mandatory in every production object.

Expected Core Components

  • Identity
  • Subject
  • Signal Type
  • Source
  • Provenance
  • Discovery Metadata
  • Timestamps
  • Version
  • Status

Potentially Conditional Components

  • Canonical-object references
  • External references
  • Relationships
  • Supersession data
  • Navigator workflow context

What Remains Intentionally Open

Phase II resolved the institutional rules surrounding the Entry Model. Only implementation details that were deliberately not frozen remain open.

  • Exact machine serialization
  • Final .schema.json dialect and constraints
  • Exact machine relationship predicates
  • Future Signal Type extensions beyond the initial governed vocabulary
  • Later software capabilities such as API, monitoring, analytics, automation, and federation
The canonical object and its institutional governance are defined. Remaining openness belongs to machine implementation and future capability expansion.

Authority Boundary

A Discovery Signal may describe or reference information with authority outside Beacon. Beacon's act of discovery does not alter that authority.

Beacon owns the signal.
The source owns the source object.
Discovery preserves the connection.

Reference does not transfer authority.

Relationship to Phase II

The Entry Model served as the dependency foundation for Beacon's completed Phase II production architecture.

Entry Model → Signal Types → Lifecycle → Identifiers → Schemas → Validation → Provenance → Authority → Relationships → Versioning → Publication → Beacon Records → Individual Beacon Record → Methodology → Production

Those later architecture pages now govern the downstream rules while preserving the Discovery Signal as Beacon's canonical object.

Production Exercise

The Entry Model has now been exercised through Beacon's first production Discovery Signal, BEAC-2026-0001.

Identifier → BEAC-2026-0001
Title → Active Operational Certification — Atlas Jurisdiction Record — El Salvador
Signal Type → Certification
Primary Source → Satoshium Certifier · SC-CERT-2026-0001
Lifecycle → Active
Publication → Published
Version → 1.0
Published → September 13, 2026

The production object demonstrates the Entry Model's identity, subject, signal type, source, provenance, canonical references, discovery metadata, timestamps, version, status, relationships, and authority boundary in governed institutional use.

Current Status

The Discovery Signal Entry Model is now part of Beacon's production-proven institutional architecture.

Beacon Status → Operational · September 2026
Phase I → Complete
Phase II → Complete
Canonical Object → Discovery Signal
Discovery Metadata → Supporting Structure
Entry Model → Defined and production-exercised
Production Schema Architecture → Defined conceptually
Frozen Machine Schema → Not yet adopted
First Production Discovery Signal → BEAC-2026-0001 · Active · Published

Define the object before defining the machinery around it.