Beacon · Phase II · Production Architecture

Relationship Model

The Relationship Model defines how Beacon represents governed connections between Discovery Signals, canonical Suite objects, sources, versions, workflows, and other relevant endpoints without collapsing independently owned objects into a single record.

Relationship connects objects. It does not merge them.

Purpose

The Relationship Model answers:

What objects may a Discovery Signal relate to?
What does the relationship mean?
Which direction does it run?
What evidence supports it?
Who owns each endpoint?

Governing Boundary

Every relationship operates under the Authority & Reference Model.

Endpoint identity remains separate.
Institutional ownership remains separate.
Canonical authority remains separate.

Reference does not transfer authority.

Canonical Example

Certification Package
SC-CERT-2026-0001
↓ referenced by / related to

Beacon Discovery Signal
BEAC-2026-0001
↓ also references / relates to

Registry Record
SREG-2026-0001

These remain three distinct canonical objects owned by three institutions. The Beacon signal preserves their governed connection; it does not turn them into one object.

Core

Relationship Endpoints

Every governed relationship must identify its endpoints.

Beacon Discovery Signal
Another Beacon Discovery Signal
Suite canonical object
External source or external object
Navigator workflow reference
Version or supersession target

An endpoint should preserve its native identifier and institutional owner when available.

Core

Relationship Meaning

A relationship must state why the endpoints are connected.

Meaning should be explicit
Meaning should be reviewable
Meaning should not imply unsupported authority
Meaning should be supported by provenance

A link without governed meaning is not yet an institutional relationship.

Initial Relationship Classes

Class	Purpose	Typical Endpoint
Source	Connects a Discovery Signal to the source actually observed.	Suite or external source
Canonical Object	Connects a Discovery Signal to an institution-owned canonical object relevant to the discovery.	Atlas, Certifier, Registry, Chronicle, Anchor, Attestor
Related Signal	Connects one Beacon Discovery Signal to another.	BEAC object
Version	Connects governed versions of the same Beacon signal identity.	Beacon version reference
Supersession	Connects a signal to a later signal or governed replacement.	BEAC object or version
Workflow	Connects Beacon discovery activity to Navigator orchestration context.	Navigator workflow reference
External	Connects a signal to a non-Suite object or source.	External source/object

These are architectural relationship classes. Final machine-readable relationship values remain subject to production proof.

Source

Source Relationship

Connects the Discovery Signal to the source Beacon actually observed.

Discovery Signal → observed from → Source

This relationship is foundational to Discovery Provenance.

Canonical

Canonical-Object Relationship

Connects a Discovery Signal to a Suite-owned canonical object relevant to the discovery.

BEAC-2026-0001 → references → ANCH-2026-0001

The Anchor object remains owned by Anchor.

Beacon

Related-Signal Relationship

Connects independently valid Beacon Discovery Signals when their discovery contexts are materially related.

BEAC-2026-0001 ↔ related to ↔ BEAC-2026-0002

Related signals remain independent objects unless Versioning or Supersession rules explicitly establish a stronger relationship.

Workflow

Workflow Relationship

Connects a Discovery Signal to the Navigator workflow under which the discovery occurred when that context is material.

Navigator → owns workflow
Beacon → owns Discovery Signal
Relationship → preserves participation

Relationship Direction

Relationship direction matters when the meaning is asymmetric.

Discovery Signal → observed from → Source
Discovery Signal → references → Canonical Object
Discovery Signal → superseded by → Later Signal

A reverse relationship may be derivable for navigation, but it should not silently change the governed meaning of the original relationship.

Directional Relationships

Some relationships have a meaningful source and target.

observed from
references
supersedes
superseded by
derived through workflow

Symmetric Relationships

Some relationships may be conceptually mutual.

related to

Whether a relationship is formally symmetric must be defined by its governed relationship type rather than assumed by presentation.

Relationship Basis

Every production relationship must have a reviewable basis.

Endpoint A identified
+ Endpoint B identified
+ Relationship meaning stated
+ Provenance or supporting basis present
+ Authority boundary preserved
= Relationship eligible for validation

Observed Relationship

Beacon may preserve a relationship explicitly represented by a source.

Source states A is related to B
↓
Beacon records the observed relationship with attribution

Beacon-Determined Relationship

Beacon may represent a relationship it determines within its own discovery function when the basis is reviewable and the relationship does not claim authority belonging elsewhere.

Beacon determination must remain identifiable as a Beacon determination.

Relationship Attribution

The model must distinguish between a relationship asserted by a source and one established by Beacon's own discovery process.

Source-attributed relationship → “Registry represents this connection.”

Beacon relationship → “Beacon discovered and represents this connection based on the preserved supporting basis.”

Multiple References

One Discovery Signal may reference multiple independently owned objects when the discovery legitimately connects them.

BEAC-2026-0001
↙ ↘
SC-CERT-2026-0001 SREG-2026-0001

No Object Collapse

Multiple references do not create a composite canonical object unless Beacon later defines such an object explicitly.

Certification Package
+ SREG
+ Discovery Signal
≠ one canonical record

Cross-Suite Relationship Example

Certifier
SC-CERT-2026-0001
↓ certification represented by

Registry
SREG-2026-0001

Beacon observes both
↓
BEAC-2026-0001

Beacon preserves the relevant discovery relationship without changing either source object.

The precise Certifier-to-Registry relationship remains governed by those institutions. Beacon records only the relationship it can support and attribute.

Signal Type vs. Relationship Type

These are separate classifications.

Signal Type → what kind of discovery the Beacon object represents

Relationship Type → how two identified endpoints are connected

A Certification Signal may contain several different relationship types.

Relationship Signal

A Relationship Signal is appropriate when the discovered relationship itself is the primary subject of the Beacon object.

Relationship Signal ≠ every Discovery Signal containing a relationship

Relationship Signal Example

If Beacon's principal discovery is that two previously separate objects are materially connected, the Discovery Signal may use the Relationship Signal Type.

Subject → the discovered connection
Signal Type → Relationship
Endpoints → Object A + Object B
Provenance → basis for representing the connection

Version Relationship

Version relationships describe governed revisions under the same canonical Beacon identity.

BEAC-2026-0001 · Version 1
↓ followed by
BEAC-2026-0001 · Version 2

Exact version semantics will be defined by the next Versioning & Supersession architecture.

Supersession Relationship

Supersession identifies which later object or version carries the current discovery context when an earlier signal is replaced.

Earlier Signal → superseded by → Later Signal / Version

Supersession preserves history rather than deleting the earlier object.

Relationship Persistence

A relationship should not silently disappear because a source changes, a signal is superseded, or a referenced object becomes unavailable.

Preserve the historical relationship where it was validly represented
Record later changes separately
Use versioning or supersession when the Beacon representation changes materially
Preserve provenance supporting the earlier relationship

External Relationships

Beacon may relate a Discovery Signal to an external source or object.

External endpoint remains external.
Beacon owns only its Discovery Signal and relationship representation.

Restricted Relationships

A relationship should not be published or represented beyond what its evidence, access rules, privacy requirements, or institutional authority support.

Discovery capability does not eliminate publication or access boundaries.

Relationship Validation

A production relationship should be rejected or require review when:

An endpoint cannot be identified
The relationship meaning is ambiguous
The supporting basis is absent
The relationship exceeds Beacon's authority
A source-attributed relationship is presented as Beacon-owned
The relationship collapses separate canonical objects
The direction contradicts the represented meaning
The relationship conflicts with known source identity

Conceptual Relationship Structure

relationship:
  relationship_type
  source_endpoint
  target_endpoint
  direction
  attribution
  supporting_reference
  provenance
  status

This is an architectural representation, not a frozen machine-readable property model.

Relationship to Authority

The Authority Model determines who owns each endpoint and determination.

Authority → ownership boundary
Relationship → governed connection

Relationship to Provenance

Provenance supplies the reviewable basis for why Beacon represents the relationship.

Relationship says → how objects connect
Provenance says → why Beacon can support that connection

Relationship to Validation

Validation checks that relationship endpoints, meanings, attribution, authority boundaries, and supporting basis conform to Beacon rules.

Relationship to Publication

A valid relationship is not automatically publishable. Publication rules may impose additional access, privacy, security, or institutional constraints.

What Is Now Established

Relationships connect independently owned objects without merging them
Every governed relationship requires identifiable endpoints
Every relationship requires explicit meaning
Direction must be preserved when semantically meaningful
Relationships require a reviewable supporting basis
Source-attributed and Beacon-determined relationships must remain distinguishable
A Discovery Signal may reference multiple canonical objects
Multiple references do not create a composite canonical object
Signal Type and Relationship Type are separate concepts
A Relationship Signal is used when the relationship itself is the primary discovery subject
Historical relationships should remain traceable through later changes

What Remains Unfrozen

Exact machine-readable relationship property names
Final controlled relationship-type vocabulary
Formal inverse-relationship rules
Cardinality constraints
Relationship identifiers, if ever needed
Relationship lifecycle/status vocabulary
Rules for relationship correction
Version-specific relationship mechanics
Specialized relationship requirements by Signal Type
Publication restrictions for sensitive relationships

These should be frozen only where Versioning, Publication, Methodology, or production evidence requires them.

Governing Rules

Preserve each endpoint.
Preserve each owner.
State the relationship.
Preserve its direction.
Preserve its supporting basis.
Preserve attribution.
Never collapse the objects merely because they are connected.

Relationship connects objects. It does not merge them.
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
Authority & Reference Model → Defined
Relationship Model → Defined
Versioning & Supersession → Next
First Production Discovery Signal → Not yet created