The Beacon Discovery Methodology defines the repeatable institutional process by which an observed candidate may become a governed Discovery Signal, progress through review and publication, and remain maintained over time.
The preliminary sequence proposed for Beacon was:
Phase II does not adopt that wording automatically. The methodology must instead be derived from the architecture already established for Beacon's canonical object, provenance, authority, lifecycle, validation, publication, versioning, relationships, and Records.
The proposed sequence captures the broad direction of Beacon's work, but it compresses several institutionally distinct acts. In particular, a Discovery Signal must be canonically created and assigned its BEAC identifier before it can undergo object-level Validation.
Beacon cannot discover something institutionally before some information, condition, object, or relationship has first been encountered.
Earlier Beacon architecture established that the canonical object comes into existence at Creation and receives its BEAC identifier at that point.
This sequence preserves the useful intent of the preliminary proposal while aligning each step with the institutional architecture established during Phase II.
| Stage | Institutional Purpose | Result |
|---|---|---|
| 1. Observe | Encounter potentially relevant information, an object, condition, event, or relationship. | Candidate observation |
| 2. Identify | Determine whether the observation presents a distinct candidate discovery worth further consideration. | Identified candidate |
| 3. Establish Source & Provenance | Identify what was observed and preserve how, when, where, and through what context it was encountered. | Reviewable evidentiary path |
| 4. Assess Relevance | Determine whether the candidate falls within Beacon's Discovery & Signals institutional role. | Proceed or stop |
| 5. Construct | Assemble the Discovery Signal components required by the Entry Model, including classification, metadata, references, and relationships as applicable. | Candidate canonical representation |
| 6. Create | Create the canonical Discovery Signal, assign its permanent BEAC identifier, and enter Draft. | Beacon-owned canonical object |
| 7. Validate & Review | Evaluate structural conformance, provenance sufficiency, authority boundaries, references, relationships, and other applicable rules. | Validation/review outcome |
| 8. Determine State | Apply the appropriate governed lifecycle state based on the review outcome and institutional action. | Governed lifecycle state |
| 9. Decide Publication | Determine whether the signal is eligible and approved for public representation. | Published or remains Unpublished |
| 10. Represent | When Published, expose the Discovery Signal through Beacon Records and its permanent individual Record page. | Public Beacon representation |
| 11. Maintain | Preserve history, re-observe when appropriate, correct presentation defects, version material changes, and govern supersession, resolution, or withdrawal. | Continuing institutional integrity |
Beacon encounters potentially relevant information through a human review, Beacon process, Navigator-directed workflow, governed system interaction, or other permitted discovery context.
Beacon recognizes that an observation may represent a distinct discovery candidate.
Beacon identifies the source, source institution or publisher, native identifier, object type, and location when applicable.
Beacon preserves the observation time, method, context, supporting basis, and discovery actor or process needed for meaningful review.
Beacon determines whether the candidate belongs within Beacon's institutional responsibility for Discovery & Signals.
A candidate that does not satisfy Beacon's relevance threshold should stop here rather than being forced into a Discovery Signal.
Relevance assessment determines whether something is appropriate for Beacon to represent as discovery. It does not establish that the underlying assertion is true, certified, registered, historically significant, integrity-verified, or trustworthy.
Beacon assembles the candidate representation according to the Discovery Signal Entry Model.
Construction prepares the institutional representation. It does not itself establish publication or source authority.
Creation is the point at which Beacon's canonical institutional object comes into existence.
The BEAC identifier is permanent and is assigned before object-level Validation.
The created Draft Discovery Signal is evaluated against Beacon's established conformance requirements and institutional boundaries.
Existing Phase II architecture recognizes initial outcomes such as Valid, Invalid, and Review Required.
Institutional review considers questions that schema conformance alone cannot resolve, including relevance, provenance sufficiency, authority boundaries, and publication suitability.
A passing Validation result does not itself perform a lifecycle transition. Beacon must apply the appropriate governed institutional state.
Later maintenance may result in Superseded, Resolved, or Withdrawn according to the Lifecycle and Versioning architecture.
Publication is a separate governed decision after the Discovery Signal exists and has undergone applicable Validation and review.
A valid Active Discovery Signal may remain Unpublished when publication is restricted or not yet approved.
Eligibility does not itself publish the signal.
When publication is approved, Beacon exposes its Discovery Signal through its established Records architecture.
The public HTML Record represents the Discovery Signal. It does not create a second canonical object.
Beacon's responsibility continues after publication.
A later observation does not erase the earlier one.
A presentation defect may be corrected without changing the canonical Discovery Signal when the underlying object remains correct.
A material change to the representation of the same canonical Discovery Signal may require a governed new version.
A distinct discovery subject, occurrence, relationship, or independently meaningful discovery should receive a new BEAC identifier rather than being forced into an existing object.
Methodology must permit a candidate to stop without becoming a Discovery Signal.
Not every observation deserves canonicalization.
Beacon's methodology must preserve authority boundaries from first observation through long-term maintenance.
Reference does not transfer authority.
Some methodological decisions may require institutional judgment, especially relevance, provenance sufficiency, relationship meaning, restrictions, and publication suitability.
Future automation may assist observation, construction, schema validation, comparison, or monitoring without replacing Beacon's governed institutional rules.
Beacon may participate in workflows defined or orchestrated by Navigator.
Workflow participation does not transfer ownership of Beacon's Discovery Signal to Navigator, nor does Beacon assume Navigator's orchestration responsibility.
The core methodology should remain common across Beacon Signal Types while allowing specialized requirements where the discovery category demands them.
Certification Signals, for example, may require specialized reference expectations without becoming Certification Packages themselves.
Schemas express structural requirements. Methodology determines how those structures are produced, reviewed, governed, published, and maintained.
A production operation should preserve enough process evidence to reconstruct the major institutional decisions that led to publication.
Exact machine fields or a separate decision-record artifact are not frozen here.