Beacon · Phase II · Production Architecture

Discovery Provenance

Discovery Provenance defines how Beacon preserves the evidentiary path behind a Discovery Signal: where the information came from, what Beacon observed, when it was observed, how it was encountered, and what source or authoritative object supports the discovery.

Provenance makes a Beacon signal reviewable without claiming ownership of the source or inheriting its authority.

Purpose

Discovery Provenance answers four foundational questions:

Where did this signal come from?
What exactly was observed?
When was it observed?
What source or authoritative object supports it?

Institutional Principle

Beacon should never require a reviewer to trust an unexplained discovery assertion.

Signal → attributable observation
Observation → traceable source
Source → preserved identity
Supporting basis → reviewable

Provenance Chain

Source / Authoritative Object
↓
Observation
↓
Discovery Context
↓
Beacon Discovery Signal
↓
Preserved Provenance

The chain should allow a later reviewer to reconstruct the basis on which Beacon created the signal.

Required

1. Source Identity

Provenance begins with an attributable source.

  • Source name
  • Source kind
  • Source institution when applicable
  • Source-native identifier when available
  • Source object type when relevant
  • Reviewable source location when available
Beacon preserves source identity. It does not replace it.
Required

2. Observed Information

Provenance must preserve enough information to understand what Beacon actually observed.

  • Observed fact, state, change, relationship, record, or information
  • Relevant source context
  • Observed source status when material
  • Specific portion, object, event, or condition supporting the discovery when practical
Provenance should document the observation, not silently expand it into a broader conclusion.
Required

3. Observation Time

Beacon must preserve when the underlying information was observed.

  • observed_at records the observation time
  • Observation time is distinct from canonical signal creation time
  • Later re-observation may use last_observed_at
  • Source publication time should remain separately attributable when known
Source time ≠ Observation time ≠ Creation time ≠ Publication time.
Required

4. Observation Method

Provenance should preserve how Beacon encountered the information.

Potential architectural methods include:

  • Manual Review
  • Search
  • Index Lookup
  • Relationship Mapping
  • Cross-System Discovery
  • Navigator-Directed Workflow
  • Other attributable discovery process
Final controlled method vocabulary remains subject to Methodology and production proof.
Required

5. Observation Context

Context explains why and under what discovery circumstances the source was observed.

  • Discovery objective
  • Search or review context
  • Workflow context when material
  • Jurisdiction or domain context
  • Relevant query or investigation reference when retained
Context should explain the discovery without turning operational history into a new canonical object.
Required

6. Supporting Basis

Provenance must identify the reviewable basis supporting the Discovery Signal.

  • Canonical source identifier when available
  • Source reference
  • Public or repository location when available
  • Supporting canonical object
  • Other attributable reference necessary to review the observation
A supporting basis should make the signal independently reviewable to the extent the source permits.

Source vs. Provenance

Source and Provenance are related but not interchangeable.

Source
What information source or canonical object is being referenced?

Provenance
How did Beacon encounter, observe, attribute, and preserve the discovery from that source?

Canonical Suite Sources

Beacon may preserve provenance to objects owned by other Suite institutions:

  • Atlas → Authoritative Intelligence
  • Certifier → Certification Package
  • Registry → SREG
  • Chronicle → Chronicle Entry
  • Anchor → Integrity Reference
  • Attestor → Trust Statement
  • Navigator → Workflow Definition / Orchestration reference

External Sources

Beacon may also discover information from sources outside the Suite.

  • Government records
  • Research publications
  • Public datasets
  • Institutional publications
  • Other attributable public sources
External discovery does not convert an external source into a Suite institution or Suite-authoritative object.

Canonical Reference Preservation

When provenance depends on a Suite canonical object, Beacon should preserve the object's native institutional identity.

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

The Beacon identifier identifies the Discovery Signal. The Anchor identifier identifies the Integrity Reference. Neither identifier absorbs the other.

Direct Provenance

Direct provenance exists when Beacon observes the source or authoritative object itself.

Source Object
↓ directly observed by Beacon
Observation
↓
Discovery Signal

Direct provenance is preferable when the authoritative or original source is reasonably available.

Indirect Provenance

Beacon may sometimes encounter information through an intermediary source.

Original / Authoritative Source
↓ referenced by
Intermediary Source
↓ observed by Beacon
Discovery Signal

The intermediary must remain visible. Beacon should not represent indirect observation as direct observation.

Provenance Depth

Beacon should preserve enough provenance depth to support meaningful review without pretending that every information lineage can be reconstructed indefinitely.

Minimum goal → identify the source Beacon actually observed and, when materially available, the authoritative or original object that source relies upon.

Exact provenance-depth requirements may vary by Signal Type and will be refined through Methodology and production use.

Discovery Actor

When institutionally relevant, provenance may preserve the actor or process responsible for discovery.

  • Human reviewer
  • Beacon process
  • Navigator-directed workflow
  • Other governed process
Actor identity should be preserved only to the degree required for accountability, privacy, and reproducibility.

Workflow Provenance

When Navigator orchestrates the workflow, Beacon may preserve a Navigator workflow reference.

Navigator → workflow authority
Beacon → discovery observation and signal
Provenance → preserves the connection

Beacon does not duplicate Navigator's workflow definition.

Temporal Provenance

Provenance must preserve distinct temporal meanings.

source_published_at → when the source says the source was published
observed_at → when Beacon observed the information
created_at → when the canonical Discovery Signal was created
published_at → when the Beacon signal was publicly published
last_observed_at → most recent governed re-observation, when applicable

These timestamps must not be silently substituted for one another.

Re-Observation

A source may be observed again after the original Discovery Signal is created.

  • Re-observation may confirm the source remains available
  • It may reveal changed source information
  • It may support an update
  • It may support supersession or resolution
Re-observation does not automatically rewrite the original observation.

Preserve Historical Basis

Later source changes should not erase the provenance basis on which the original signal was created.

Preserve what Beacon observed then.
Preserve what Beacon observes later.
Preserve the relationship between them.

Provenance and Source Changes

If a source changes, disappears, is superseded, or becomes unavailable, Beacon should preserve the original provenance record to the extent possible.

  • Do not rewrite the original source state as though the later state existed earlier
  • Record later observations separately
  • Preserve source-native supersession when attributable
  • Preserve unavailable-source status without deleting historical provenance

Provenance Does Not Equal Verification

Provenance demonstrates lineage and attribution.

Provenance → where the assertion came from
Verification → whether a governed verification process establishes something about it

A well-provenanced false statement remains false. Provenance makes its origin reviewable; it does not make it true.

Provenance Does Not Equal Trust

Beacon does not convert traceability into a Trust Statement.

Beacon → preserves discovery lineage
Attestor → owns Trust Statements

Minimum Provenance Gate

A Draft Discovery Signal should not pass Validation without a sufficient provenance basis.

Source identified
+ Observation described
+ Observation time preserved
+ Observation method preserved
+ Observation context sufficient
+ Supporting basis reviewable
= Minimum Provenance Conformance

Conceptual Provenance Structure

provenance:
  observed_source
  observed_information
  observed_at
  observation_method
  observation_context
  supporting_reference
  discovery_actor
  workflow_reference

This is an architectural structure, not yet a frozen JSON property model.

Validation Relationship

Provenance is a required Validation concern.

Provenance Architecture → defines what lineage means
Validation → confirms required provenance is present and conformant

Schema Relationship

The Discovery Signal Schema contains the provenance component.

Schema → represents provenance
Provenance Architecture → defines provenance meaning

What Is Now Established

  • Every production Discovery Signal requires a reviewable provenance basis
  • Source identity must remain attributable
  • Beacon must preserve what was actually observed
  • Observation time is distinct from creation and publication time
  • Observation method and context are provenance concerns
  • Supporting source or authoritative-object references must remain reviewable
  • Direct and indirect provenance must be distinguishable
  • Later source changes must not erase historical provenance
  • Provenance supports Validation but does not equal verification, trust, or truth

What Remains Unfrozen

  • Exact machine-readable provenance property names
  • Controlled observation-method vocabulary
  • Minimum provenance depth by Signal Type
  • Required citation/location formats
  • Discovery-actor privacy rules
  • Workflow-reference syntax
  • Re-observation schema mechanics
  • Unavailable-source preservation mechanics
  • Whether cryptographic evidence becomes part of any provenance profile
  • Automated provenance-capture requirements
These should be resolved only where later architecture or production evidence demonstrates the need.

Authority Boundary

Beacon proves where its signal came from.
Beacon does not become the source.
Beacon preserves an authoritative object's identity.
Beacon does not inherit that object's authority.

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
Schemas → Defined
Validation → Defined
Discovery Provenance → Defined
Production Provenance Capture → Pending
First Production Discovery Signal → Not yet created
A discovery becomes reviewable when its path back to the source remains visible.