Beacon · Phase II · Production Architecture

Beacon Schemas

Beacon Schemas define the public machine-readable structures Beacon recognizes and publishes. They translate the institutional architecture of Discovery Signals into predictable, interoperable, validation-ready 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 primary production schema for Beacon must represent the canonical Beacon-owned object:

Discovery Signal → BEAC-YYYY-NNNN

It should implement the Discovery Signal Entry Model already established during Phase II:

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 should support:

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

Current Phase II architecture already establishes:

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

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

Publication States → Unpublished · Published

Exact machine-readable enum spelling will be formalized in the schema files and tested through Validation.

Public Schema Directory

Beacon's schema directory should distinguish canonical production structures from supporting or legacy conceptual structures.

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

Revise → Canonical

signal-record-schema.md

The existing Signal Record Schema is the closest predecessor to the canonical Discovery Signal schema, but it predates the Phase II Entry Model, Signal Types, Lifecycle, and Identifier Standard.

Replace legacy SIG-YYYY-NNNNNN with BEAC-YYYY-NNNN
Replace legacy signal-type examples with the eight governed types
Replace legacy status vocabulary with the canonical lifecycle model
Add provenance and canonical references
Separate Lifecycle State from Publication State
Remove confidence as implied canonical signal semantics unless later architecture explicitly restores it

Recommended role → canonical human-readable Discovery Signal production schema.

Retire or Reframe

beacon-record-schema.md

The existing Beacon Record Schema introduces a second generic Beacon record object using BEC-YYYY-NNNNNN. Phase II has now established the Discovery Signal as Beacon's canonical production object.

A parallel generic “Beacon Record” risks duplicating the canonical object
The legacy identifier conflicts with the new Identifier Standard
Discovery activity may belong in methodology, provenance, query, or audit structures rather than a second canonical object

Recommended disposition → retire as canonical schema or explicitly reframe as a noncanonical supporting activity record only if production proves the need.

Supporting · Review

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

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

Supporting · Review

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

Recommended role → noncanonical discovery-output structure, if retained.

Supporting · Review

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

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

Directory Governance

README.md

The existing schema README should be revised to reflect the Phase II production architecture.

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

Production Beacon records should ultimately support a machine-readable representation that can be validated independently of the human-readable page.

The exact file format, JSON Schema implementation, version URI, and public schema location should be determined without changing the institutional meaning established here.

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 Unfrozen

Exact JSON property names
Required vs. optional property rules
Machine-readable enum spelling
JSON Schema version and dialect
Schema version identifiers
Reusable sub-schema boundaries
Discovery-result retention
Query-log retention and privacy rules
Whether legacy Beacon Record Schema is retired or retained as noncanonical
Formal validation behavior

These should be finalized through the schema-file revision and the next Phase II step: Validation.

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.

Current Status

Beacon Status → Continuing Development
Phase → Phase II — Production Architecture
Entry Model → Defined
Signal Types → Defined
Lifecycle → Defined
Identifier Standard → Defined
Schema Architecture → Defined
Canonical Production Object → Discovery Signal
Canonical Identifier → BEAC-YYYY-NNNN
Existing Schema Documents → Require alignment review
Machine-Readable Enforcement → Pending
Validation Architecture → Next