Beacon · Phase II · Production 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 use a consistent machine-readable format

Exact timestamp syntax will be enforced in 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 should eventually 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 initial architectural 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 formal machine-readable outcome remains to be proven during production implementation.

Validation Record

Validation should eventually preserve 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 New Canonical Object Yet

Validation output should not automatically create another institution-owned object class.

Production need first.
Separate canonical identifier only if institutional necessity is proven.

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 Unfrozen

Exact machine-readable required-field list
Exact JSON field names
JSON Schema dialect
Timestamp serialization rules
Formal warning/error codes
Validation severity enum
Validation report format
Who or what authorizes final validation acceptance
Whether a validation result is persisted
Whether “Review Required” becomes a formal outcome
Automated vs. manual validation boundaries

These should be finalized through production implementation and later Methodology work.

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.

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
Validation Architecture → Defined
Machine Validation → Pending
Production Validation Run → Pending
First Production Discovery Signal → Not yet created