Beacon · Discovery Signal Architecture

Validation

Beacon Validation defines what must be true before a Discovery Signal can be accepted as a valid Beacon production object. It applies the institutional rules established by the Entry Model, Signal Types, Lifecycle, Identifier Standard, and Schemas.

Validation determines conformance. It does not create truth, certification, trust, source authority, or publication entitlement.

Purpose

Validation answers:

Does this candidate Discovery Signal satisfy the minimum structural and institutional requirements required to stand as a valid Beacon object?

Validation Principle

Schema → defines structure
Validation → tests conformance
Methodology → governs process
Publication → governs public release

Passing validation means the object conforms to Beacon requirements. It does not imply that the referenced source is correct or trustworthy.

Validation Gate

A Discovery Signal begins canonical life when it is Created and enters Draft. Validation is one of the institutional gates required before that Draft can become Active.

Created → Draft → Review / Validation → Active

Validation is therefore a production-conformance gate, not the object-creation event itself.

Required

1. Canonical Identity

A valid Discovery Signal must have:

A Beacon identifier
Identifier conforming to BEAC-YYYY-NNNN
Object Type = Discovery Signal
Institution = Beacon
A human-readable title or equivalent identifying label

Identity must be stable, unique, and institutionally attributable.

Required

2. Identifier Conformance

The identifier must satisfy the Beacon Identifier Standard.

Prefix = BEAC
Four-digit creation year
Four-digit zero-padded sequence
Issued sequence not reused
Identifier assigned at canonical creation
No Signal Type embedded
No lifecycle or publication status embedded
No version suffix embedded

Conceptual pattern → ^BEAC-[0-9]{4}-[0-9]{4}$

Required

3. Subject

The Discovery Signal must identify what it concerns.

Subject name or equivalent identifier
Subject type or classification where applicable
Sufficient context to distinguish the subject
Jurisdiction, domain, entity, record, event, artifact, or other relevant context when needed

A vague signal without an identifiable subject cannot be meaningfully reviewed.

Required

4. Permitted Signal Type

The primary Signal Type must come from the governed architectural vocabulary:

Information · Jurisdiction · Certification · Registry · Historical · Integrity · Trust · Relationship

Ad hoc new types do not pass production validation unless formally governed.

Required

5. Source Reference

A valid Discovery Signal must preserve an attributable source.

Source name
Source kind or institution
Source identifier when available
Source object type when relevant
Source location or reviewable reference when available

Beacon should preserve the source's own identity rather than invent a replacement source identity.

Required

6. Provenance

Validation must confirm that the discovery has a reviewable provenance basis.

How Beacon encountered the information
What source was observed
Observation or discovery method
Supporting reference when applicable
Discovery actor or process when appropriate

Provenance explains how the discovery became known to Beacon.

Conditional

7. Canonical References

When a Discovery Signal claims a relationship to a Suite-owned canonical object, the reference must be structurally valid and institutionally accurate.

Correct source institution
Correct canonical identifier format
Correct object type when known
No substitution of Beacon identity for source identity

Reference does not transfer authority.

Required

8. Discovery Metadata

The signal must contain enough Discovery Metadata to make the discovery understandable and reviewable.

Discovery context
Relevant topic or domain when applicable
Jurisdiction or classification when applicable
Observed source status when relevant and clearly attributed
Workflow or search context when material

Required

9. Timestamps

At minimum, a valid production object must preserve canonical creation time.

created_at required
Creation year must match the identifier year
observed_at required when distinct from creation
updated_at, published_at, and last_observed_at used when applicable
Timestamps must preserve consistent, unambiguous temporal meaning

Exact frozen timestamp serialization remains intentionally open for the machine-readable implementation.

Required

10. Status

Lifecycle and publication status must remain separate.

Lifecycle → Draft · Active · Superseded · Resolved · Withdrawn

Publication → Unpublished · Published

A signal must not pass validation if these concepts are collapsed into a single ambiguous status field.

Required

11. Version

A production object must preserve explicit version information.

Initial version present
Version separate from canonical identifier
Previous-version or supersession reference when required
No silent overwriting that destroys institutional history

Exact version semantics remain governed by the later Versioning phase.

Conditional

12. Relationships

Any represented relationship must have a valid basis and identifiable endpoints.

Both endpoints identifiable
Relationship meaning understandable
Relationship supported by source or provenance
No unsupported or inferred relationship represented as fact

Schema Conformity

A production Discovery Signal must conform to the canonical Discovery Signal schema.

Canonical schema → /beacon/schemas/discovery-signal-schema.md

Structural conformity includes correct field presence, permitted values, expected data shapes, and governed relationships between fields.

Required vs. Conditional

Validation distinguishes core requirements from context-dependent requirements.

Required → every production Discovery Signal must satisfy

Conditional → required when the represented condition exists

Example: every signal requires a source, but not every signal necessarily requires a cross-Suite canonical-object reference.

Validation Severity

Validation findings distinguish between:

Error → prevents production conformance
Warning → requires review but may not invalidate the object
Informational → useful observation without conformance effect

Exact machine-readable severity values remain unfrozen.

Minimum Production Gate

A Draft should not become Active unless all required conditions are satisfied.

Identifier valid
+ Subject identifiable
+ Signal Type permitted
+ Source attributable
+ Provenance reviewable
+ Discovery Metadata sufficient
+ Timestamps valid
+ Status valid
+ Version present
+ Schema conformant
+ Conditional references/relationships valid when used
= Eligible for Active consideration

Passing Validation makes the signal eligible for lifecycle progression. It does not itself perform the lifecycle transition.

What Validation Does Not Prove

Passing Beacon Validation does not establish:

Truth of the underlying information
Correctness of an external source
Certification
Registration
Historical significance
Integrity verification
Trustworthiness
Publication approval

Authority Separation

Validation evaluates the Beacon Discovery Signal against Beacon's production rules.

Beacon Validation → conformance of Beacon object
Certifier → certification authority
Registry → registration authority
Chronicle → historical preservation
Anchor → integrity reference / verification process
Attestor → Trust Statements

Source-State Validation

If a Discovery Signal records a source-owned status, Validation must confirm that the status is clearly attributed to the source rather than represented as Beacon's own determination.

Correct → Observed source status: Active, attributed to Registry

Incorrect → Beacon declares Registry record Active without source attribution

Validation Outcomes

The governed conceptual validation outcomes are:

Valid → required Beacon production requirements satisfied

Invalid → one or more required requirements failed

Review Required → structurally acceptable but unresolved warning or institutional issue remains

Whether “Review Required” becomes a frozen machine-readable outcome remains intentionally open.

Validation Record

Validation preserves enough information to reconstruct what was checked and what the result was.

Object identifier
Schema/version evaluated
Validation timestamp
Rules evaluated
Errors and warnings
Outcome

Whether this becomes a separate canonical record is not established.

No Separate Validation Object

Beacon's first production operation did not establish a separate canonical validation object. Validation remains a governed determination applied to the Discovery Signal.

Validation result → preserved production evidence
Separate canonical object → not established

Conceptual Validation Sequence

1. Parse Discovery Signal
2. Confirm canonical identity
3. Confirm schema structure
4. Confirm required fields
5. Confirm permitted Signal Type
6. Confirm source attribution
7. Confirm provenance basis
8. Confirm timestamps
9. Confirm lifecycle/publication values
10. Confirm version structure
11. Confirm references and relationships
12. Produce validation outcome

What Is Now Established

Validation is a production-conformance gate
Validation occurs after canonical object creation and before Active standing
Canonical identity must conform to BEAC-YYYY-NNNN
Subject, permitted Signal Type, source, provenance, metadata, timestamps, version, and status are core validation concerns
Canonical references and relationships are conditionally validated
Lifecycle and publication state remain separate
Source-owned authority must remain attributed
Schema conformity is required
Passing Validation does not equal truth, trust, certification, or publication approval

What Remains Intentionally Open

Exact machine-readable required-field serialization
Exact JSON field names
JSON Schema dialect
Frozen timestamp serialization rules
Formal machine warning/error codes
Frozen validation severity enum
Machine validation report format
Whether “Review Required” becomes a frozen machine-readable outcome
Future automated vs. manual validation boundaries

These are implementation questions. The institutional Validation architecture and first governed production review are complete.

Authority Boundary

Validation confirms Beacon conformance.
It does not inherit the authority of the referenced source.
It does not certify the source.
It does not create a Trust Statement.

Reference does not transfer authority.

First Production Validation

Beacon Validation has now been exercised through BEAC-2026-0001.

Canonical Identity → PASS
Identifier Conformance → PASS
Subject → PASS
Signal Type → PASS
Source Reference → PASS
Provenance → PASS
Discovery Metadata → PASS
Timestamps → PASS
Status → PASS
Version → PASS
Authority Boundary → PASS
Canonical References → PASS
Relationships → PASS with implementation note
Schema Conformity → PASS at governed conceptual level

Final Validation Outcome → VALID
Review Outcome → APPROVED TO PROCEED

Exact machine relationship predicates and frozen .schema.json serialization were intentionally unfrozen, so machine-serialization validation was not applicable to the first production operation.

Current Status

Beacon Status → Operational · September 2026
Validation Architecture → Defined and production-exercised
First Production Validation → BEAC-2026-0001 · VALID
Review Outcome → APPROVED TO PROCEED
Lifecycle Result → Eligible for Draft → Active transition
Frozen Machine Validation → Not yet adopted
First Production Discovery Signal → BEAC-2026-0001 · Active · Published