07 · Technical repository

The technical record behind Broadcast Infrastructure

The repository contains the frozen specification family, the Broadcast Supersession Protocol Internet-Draft, machine-readable schemas, test vectors, governance records, audit materials, and the reference implementations. Nothing on this page should be interpreted as a live download until the versioned repository has been publicly deployed and verified.

Specifications
5 frozen at v1.0-FC1
Protocol draft
1 prepared, not yet filed
Governance records
5 mixed publication status
Public downloads
Pending deployment phase

Review the repository map Request technical materials

Contents
  1. 01  Current publication state
  2. 02  Repository map
  3. 03  Specifications
  4. 04  Machine-readable materials
  5. 05  Governance records
  6. 06  Audit and release record
  7. 07  Reference implementations
  8. 08  Public deployment plan

01

Current publication state

The public documentation portal is live. The underlying static artifact repository is not yet live.

What is available now

The Overview, Specification Family, Conformance, Reference Implementation, Security Review, Governance, and Technical Repository pages are available as public documentation.

Together they describe the architecture, frozen specification family, current implementation state, known limitations, governance gaps, and the materials prepared for independent review.

What is not available yet

The permanent versioned file tree, individual Markdown and JSON artifacts, verification checksum file, and packaged ZIP archive have not yet been installed at public repository URLs.

Until that deployment is complete, this page must not claim that visitors can download, independently hash, or verify files directly from the site.

Return to the overview

02

Repository map

The prepared repository separates normative specifications, implementation materials, governance records, tests, and audit history so each class of evidence can be reviewed independently.

Prepared repository structure
Area Contents Public state
spec/ The five FC1 specification documents and the prepared Broadcast Supersession Protocol Internet-Draft. Described publicly; file deployment pending.
spec/schema/ JSON Schema for validating Broadcast Objects. Prepared; public file URL pending.
spec/context/ Versioned JSON-LD context and vocabulary terms. Prepared; public file URL pending.
spec/examples/ Worked examples for a television commercial, interview, and livestream replay. Prepared; public file URL pending.
spec/tests/ Golden vectors, negative cases, Merkle proofs, and cross-document validation materials. Prepared; public file URL pending.
governance/ Stewardship, continuity, context-serving, operator onboarding, and conflict-of-interest records. Summarized publicly; artifact deployment pending.
audit/ Technical audit, known issues, release manifest, conformance report, changelog, and errata. Summarized publicly; artifact deployment pending.
implementations/ Reference Publisher, Log, and Consumer implementations, including their test suites. Documented publicly; source deployment pending.

Versioned publication is deliberate

When publicly deployed, FC1 artifacts should live beneath a versioned, permanent repository path. A later release should receive a new path rather than silently replacing FC1.

That preserves citations, auditability, and the ability to compare one published version against another.

03

Specifications

Five documents are frozen at v1.0-FC1. Change control is limited to documented errata arising from independent review.

  1. BI-001 Architecture Overview Explains the integration profile, its boundaries, and what is genuinely new. Informative
  2. BI-002 Broadcast Object Model Defines identity, versioning, description, relationships, provenance, and lifecycle. Normative
  3. BI-004 Publisher Authority Defines who may correct a record and how a consumer verifies that authority. Normative
  4. BI-008 Supersession Protocol Defines the append-only correction and withdrawal protocol. Normative
  5. BI-009 Conformance Defines 112 testable assertions across five implementation roles. Normative

Prepared Internet-Draft

draft-alexander-bsp-00 presents the Broadcast Supersession Protocol in Internet-Draft form.

It is written and prepared for submission, but not yet filed. Filing is the event that would make the donation effort independently dated and publicly checkable.

Read the specification-family summary

04

Machine-readable materials

The package includes structured files intended to be validated, tested, and processed without manual interpretation.

  • MANIFEST.json Deployment pending Machine-readable release record containing the version, verdict, open gates, resolved findings, deferred findings, and amendment history.
  • broadcast-object-1.0.schema.json Deployment pending JSON Schema used to validate a Broadcast Object against the BI-002 data model.
  • broadcast-object-1.0.jsonld Deployment pending Versioned JSON-LD context containing the vocabulary terms used by the Broadcast Object Model.
  • Worked examples Deployment pending Prepared examples for a television commercial, interview, and livestream replay.
  • Test vectors and suites Deployment pending Merkle roots, inclusion and consistency proofs, canonicalization vectors, negative cases, and attack cases a conforming implementation must reject.
  • SHA256SUMS.txt Deployment pending Prepared checksum record intended to allow reviewers to verify that downloaded bytes match the published package.

Verification begins only after deployment

A checksum statement is meaningful only when the referenced files are publicly available and the visitor can independently retrieve the exact bytes being checked.

Until then, this page describes the verification architecture without claiming that public verification is already possible.

05

Governance records

Five governance records have been prepared. Their individual statuses are not the same and must not be presented as though they are.

Governance document register
ID Document Status
BI-GOV-001 Namespace Stewardship Memo — documents three stewardship options, the recommendation, and the associated risks. Published record — no decision made
BI-GOV-002 Continuity and Succession Commitment — registration term, registrar controls, DNSSEC, successor acceptance, wind-down, and transfer planning. Draft — unsigned
BI-GOV-003 Context Serving Commitment — availability, history, relocation, and long-term context-serving obligations. Draft — unsigned
BI-GOV-004 Independent Log Operator Onboarding — operator-neutral requirements for a second log operator. Published record — open call
BI-GOV-005 Conflict-of-Interest Disclosure — identifies the roles currently held by 360WiSE and the limitations created by that concentration. Adopted

Prepared does not mean adopted

BI-GOV-002 and BI-GOV-003 contain binding promises that have not been executed. They remain unsigned drafts and must continue to be identified that way.

Publishing a draft commitment as though it were signed would create the exact documentation failure this work is intended to prevent: a record asserting something the world does not support.

The governance gates remain open

M-7 remains unmet: no namespace steward and no IANA submitter have been formally named.

E-1 remains unmet: no second, independently controlled log operator currently exists.

Writing governance documents records the gaps. It does not, by itself, close them.

Review governance in detail

06

Audit and release record

The prepared repository includes the technical audit, known issues, release status, changelog, and errata.

  • RC1 Technical Audit Deployment pending The dated technical audit includes the Critical, Major, Minor, and Editorial findings raised against the work. The audit remains a historical record rather than being rewritten after fixes are made.
  • Known issues Deployment pending Records unresolved, partially resolved, and residual issues, including governance, interoperability, domain, and independent-operator limitations.
  • Changelog and errata Deployment pending Records post-freeze amendments, what changed, what did not change, and why the amendment was permitted.
  • Conformance report Deployment pending Records the testable assertions, automated results, human-attested requirements, and implementation roles currently exercised.

Findings are not erased after correction

A finding may be resolved, narrowed, or superseded by later evidence. The original dated record remains part of the review history.

That separation preserves the difference between what was found and what was later done about it.

Review the security record

07

Reference implementations

MassMediaHub™ is Reference Implementation #001. Any organization may build an independent implementation from the published specifications. It is not the specification.

Current implementation coverage
Role Current state Limit
Publisher Reference implementation exists. Self-reported; not independently replicated.
Supersession Log Reference implementation exists. Operated within the same organizational concentration.
Consumer Reference Consumer #001 exists and exercises the defined consumer assertions. Independent interoperability has not been demonstrated.
Monitor Not built. No independent monitoring implementation exists.
Auditor Not built. No independent auditing implementation exists.
Prepared implementation suites 
test_canonical.py
# RFC 8785 canonicalization vectors

test_authority.py
# Publisher-authority verification cases

tests/test_consumer.py
# Consumer acceptance and refusal paths

These suite names describe prepared repository materials. They are not publicly runnable from this website until the underlying implementation files have been deployed.

Implementable is not interoperable

One implementation passing a suite written by its own authors can demonstrate that a protocol is buildable.

It does not prove that independently developed systems interpret the specification identically.

Review Reference Implementation #001

08

Public repository deployment

The next repository milestone is deployment, not the creation of additional documentation claims.

Required before downloads are activated

The static repository should be installed beneath a permanent, versioned path that does not conflict with WordPress routing.

The prepared artifacts must be staged from one source of truth, verified against the package checksum record, and tested for working public responses before any download button is activated.

Repository deployment sequence
Step Requirement Current state
1 Confirm the permanent, versioned repository path. Planned.
2 Stage the prepared artifact tree from the package source. Pending.
3 Verify the staged files against the checksum record. Pending public deployment.
4 Generate and verify the downloadable review archive. Pending public deployment.
5 Test all public artifact URLs and content types. Pending.
6 Replace repository-status labels with working links. Final activation step.

Do not activate downloads early

A button that leads to a missing file, an unverified copy, or a temporary path would weaken the record rather than strengthen it.

Until the deployment is complete, the honest state is: repository documented, artifacts prepared, public downloads pending.

Request Technical Materials or Submit a Review

Email

Engineering questions, specification comments, security findings, implementation feedback, interoperability reports, and requests concerning the prepared technical materials are welcome.

Prospective independent reviewers, log operators, and standards organizations are encouraged to write.

Frozen Broadcast Infrastructure™ v1.0-FC1 · Final Candidate 1 · Not Final

The technical repository is documented and its artifacts are prepared, but the permanent public artifact deployment is pending. This specification family is not to be operationally relied upon. The correction protocol is intended for donation to a standards body.