Beacon · Phase II · Production Architecture

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 begins Beacon Phase II by defining the object that later work on signal types, lifecycle, identifiers, schemas, validation, provenance, versioning, publication, and production will govern.

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 supports and describes that object.

Beacon → Discovery Signal / Metadata

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 final identifier syntax is not frozen on this page. It will be governed by the later Beacon Identifier Standard.

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

Candidate types may include information, jurisdiction, certification, registry, historical, integrity, trust, relationship, or other future governed categories.

Exact production signal types remain unfrozen until the dedicated Signal Types phase.

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 supports the Discovery Signal. It 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
Exact timestamp requirements and semantics remain subject to lifecycle and publication design.

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 rules will be finalized in the dedicated Versioning & Supersession phase.

10. Status

Status records the current institutional state of the Discovery Signal.

  • Lifecycle state
  • Publication state
  • Resolution or supersession state when applicable
Status values are not frozen here. The Lifecycle and Publication phases will define the controlled production vocabulary.

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
Relationship vocabulary should remain minimal until production demonstrates what Beacon actually needs.

12. Institutional Ownership

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

  • Beacon owns the Discovery Signal
  • Beacon owns its discovery metadata
  • 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 is an architectural skeleton, not yet the production schema.

{
  "discovery_signal": {
    "identity": {},
    "subject": {},
    "signal_type": "",
    "source": {},
    "provenance": {},
    "canonical_references": [],
    "discovery_metadata": {},
    "timestamps": {},
    "version": {},
    "status": {},
    "relationships": []
  }
}
Field names, required properties, controlled values, validation rules, and schema constraints remain to be finalized in later Phase II work.

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 the Entry Model Does Not Decide Yet

This page deliberately does not freeze decisions that belong to later Phase II architecture.

  • Final identifier syntax
  • Final signal-type vocabulary
  • Lifecycle states
  • Publication states
  • JSON schema constraints
  • Validation rules
  • Relationship vocabulary
  • Versioning semantics
  • Publication procedure
  • First production signal
Define the object first. Freeze downstream rules only when their dedicated architecture is reviewed.

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 is the dependency foundation for the remaining Beacon production architecture.

Entry Model → Signal Types → Lifecycle → Identifiers → Schemas → Validation → Provenance → Authority → Relationships → Versioning → Publication → Discovery Signals Register → Individual Signal → Methodology → Production

Later pages may refine this model, but they should do so explicitly rather than silently redefine the canonical Beacon object.

Current Status

This Entry Model begins Beacon Phase II — Production Architecture.

Beacon Status → Continuing Development
Phase → Production Architecture
Canonical Responsibility → Discovery Signal / Metadata
Entry Model → Defined at architectural level
Production Schema → Not yet frozen
First Production Discovery Signal → Not yet created

Define the object before defining the machinery around it.