Beacon · Discovery Signal Architecture

Beacon Schemas

Beacon Schemas define the governed structural architecture Beacon uses for Discovery Signals and supporting discovery structures. They translate Beacon's institutional model into predictable, interoperable representations without collapsing Beacon into the systems it references.

The schema layer must preserve Beacon ownership, source attribution, provenance, canonical references, lifecycle, publication state, versioning, and relationships while keeping referenced institutional authority intact.

Purpose

The Schema architecture answers:

How is Beacon's institutional model represented in structured, machine-readable form?

Schemas define structure. They do not create truth, authority, certification, trust, or source ownership.

Schema Principle

Beacon should publish the minimum stable structures required to represent its own canonical objects and governed supporting data.

Institutional architecture first.
Machine-readable structure second.
Validation after the structure is defined.

Canonical Production Schema

Discovery Signal Schema

The canonical Beacon schema architecture represents the Beacon-owned production object:

Discovery Signal → BEAC-YYYY-NNNN

It implements the Discovery Signal Entry Model established for Beacon:

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

This schema supersedes older conceptual assumptions that treated a generic “Signal Record” or “Beacon Record” as the primary production object.

Required Core Structure

The canonical Discovery Signal schema architecture supports:

Beacon identifier using BEAC-YYYY-NNNN
Object type: Discovery Signal
Subject
Governed Signal Type
Source attribution
Discovery provenance
Canonical-object references
Discovery Metadata
Creation and observation timestamps
Lifecycle State
Publication State
Version information
Governed relationships

Established Controlled Values

Beacon's governed architecture establishes:

Signal Types → Information · Jurisdiction · Certification · Registry · Historical · Integrity · Trust · Relationship

Lifecycle States → Draft · Active · Superseded · Resolved · Withdrawn

Publication States → Unpublished · Published

Exact frozen machine-readable enum serialization remains intentionally open. Institutional conformance is governed through Beacon Validation.

Public Schema Directory

Beacon's schema architecture distinguishes the canonical Discovery Signal structure from supporting and optional operational structures.

Canonical Object Schema
↓
Supporting Structures
↓
Validation Rules
↓
Published Production Records

Canonical

discovery-signal-schema.md

discovery-signal-schema.md is the canonical human-readable schema document for Beacon's Discovery Signal architecture.

Uses BEAC-YYYY-NNNN
Uses the eight governed Signal Types
Preserves canonical lifecycle and separate publication state
Includes source, provenance, canonical references, metadata, timestamps, version, status, and relationships
Represents Beacon's canonical object without creating a competing record type

Canonical role → human-readable Discovery Signal schema architecture.

Deprecated

Legacy Generic Record Schemas

Earlier signal-record-schema.md and beacon-record-schema.md concepts are deprecated as canonical schemas. Beacon's canonical object is the Discovery Signal.

Legacy SIG-YYYY-NNNNNN and BEC-YYYY-NNNNNN identifier assumptions are obsolete
A Beacon Record is a public representation of a Discovery Signal, not a second canonical object type
Supporting discovery activity belongs in provenance, methodology, query, or other explicitly noncanonical structures when needed

Canonical object → Discovery Signal.
Public representation → Beacon Record.

Supporting

source-reference-schema.md

Source references remain important because every Discovery Signal should preserve attribution and traceability.

Keep source identity distinct from Beacon identity
Preserve source institution or external source
Preserve canonical source identifier when one exists
Avoid assigning a new Beacon-owned source identity merely because Beacon references it
Do not imply Beacon verification or endorsement

Governed role → embedded or reusable supporting source-reference structure.

Optional · Noncanonical

discovery-result-schema.md

Discovery results may remain useful as query or presentation outputs, but they must not compete with Discovery Signals as Beacon's canonical production object.

Distinguish transient result from canonical Discovery Signal
A result may point to a BEAC signal, source object, or external source
Do not assign permanent institutional meaning automatically
Retain relevance only as discovery context, not authority

Governed role → optional noncanonical discovery-output structure.

Optional · Operational

query-log-schema.md

Query logging may support transparency and reproducibility, but it belongs to operational discovery history rather than Beacon's canonical object model.

Navigator may originate or orchestrate workflows
Beacon may process discovery activity
Query logs should not redefine Navigator's workflow authority
Retention and privacy rules require explicit treatment
A permanent query identifier should not be frozen until operational need is proven

Governed role → optional supporting operational schema, not a canonical Discovery Signal schema.

Directory Governance

README.md

The schema README should document the current Discovery Signal architecture and distinguish canonical, supporting, optional, and deprecated structures.

Discovery Signal becomes the canonical Beacon object
Identify canonical vs supporting schemas
Remove obsolete generic-record assumptions
Document authority boundaries
Document schema status and version posture
Point to Validation as the enforcement layer

Recommended Schema Architecture

Canonical
discovery-signal-schema.md

Reusable Supporting Structures
source-reference-schema.md
provenance structure
canonical-reference structure
relationship structure
status structure

Optional Operational / Discovery Structures
discovery-result-schema.md
query-log-schema.md

Separate files should exist only where they represent a meaningful reusable structure or governed operational record. File proliferation should not create new institutional object classes accidentally.

Schema Ownership

Beacon schemas define Beacon-owned structures and Beacon's representation of references.

Beacon may describe a referenced object.
Beacon may not redefine the referenced object's canonical schema or authority.

Canonical References

Schema fields may reference institution-owned objects such as:

Atlas Authoritative Intelligence
Certifier Certification Package
Registry SREG
Chronicle Entry
Anchor Integrity Reference
Attestor Trust Statement
Navigator workflow reference when relevant

References preserve identity and provenance without transferring ownership.

Schema vs. Validation

Schema defines what a structured object may contain.

Validation determines whether a particular object satisfies the required structural and institutional rules.

Schema → structure
Validation → conformance

Schema vs. Methodology

Schema does not determine how Beacon discovers information or decides whether a signal should be created.

Schema → representation
Methodology → process

Machine-Readable Publication

Beacon's institutional schema architecture is machine-readable-ready, but no frozen .schema.json implementation has yet been adopted.

A future machine-readable representation should remain independently validatable and must preserve the same institutional meaning as the human-readable architecture. Exact file format, JSON Schema dialect, version URI, and public machine-schema location remain intentionally open.

Human-readable architecture and machine-readable enforcement should describe the same object.

What Is Now Established

The Discovery Signal is Beacon's canonical production object
Its canonical identifier follows BEAC-YYYY-NNNN
The Entry Model defines the structural architecture
Signal Types define the initial classification vocabulary
Lifecycle State and Publication State remain separate dimensions
Source attribution and provenance are required architectural concerns
Canonical references do not transfer authority
Supporting schemas must not silently create competing canonical objects

What Remains Intentionally Open

Exact machine property serialization
Frozen required vs. optional machine-property constraints
Machine-readable enum serialization
JSON Schema version and dialect
Machine-schema version identifiers
Reusable machine sub-schema boundaries
Discovery-result retention rules
Query-log retention and privacy rules

These are implementation questions, not unresolved institutional architecture. Validation is already defined at the governed conceptual level.

Authority Boundary

Beacon schema → defines Beacon's object and Beacon's references.
Source schema → remains owned by the source institution.
Cross-Suite reference → preserves connection, not authority transfer.

Reference does not transfer authority.

Production Exercise

Beacon's schema architecture has been exercised at the governed conceptual level through BEAC-2026-0001.

Canonical Object → Discovery Signal
Identifier → BEAC-2026-0001
Signal Type → Certification
Source → Satoshium Certifier · SC-CERT-2026-0001
Provenance → Direct
Lifecycle → Active
Publication → Published
Version → 1.0
Validation → Schema Conformity PASS at governed conceptual level

No frozen .schema.json existed for the first operation, so machine-serialization validation was not applicable.

Current Status

Beacon Status → Operational · September 2026
Schema Architecture → Defined and production-exercised
Canonical Production Object → Discovery Signal
Canonical Human-Readable Schema → discovery-signal-schema.md
Supporting Schema → source-reference-schema.md
Optional Noncanonical Schema → discovery-result-schema.md
Optional Operational Schema → query-log-schema.md
Legacy Generic Record Schemas → Deprecated
Validation Architecture → Defined
Frozen Machine Schema → Not yet adopted