What Broadcast Infrastructure is

An integration profile over standards that already exist, plus one new protocol.

A conformant broadcast object is described with schema.org, identified with EIDR, Ad-ID, or ISAN, provenanced with C2PA (for the essence) and PROV-O (for the record), licensed with ODRL, preserved per OAIS and PREMIS, versioned with Memento (RFC 7089), discovered via Signposting, and authenticated with X.509 and the ordinary Web PKI.

No new identifier scheme was minted. No new trust framework was invented. No registry was created — because a registry is a chokepoint. Publisher authority is rooted in something a broadcaster already has: demonstrated control of an origin domain, proven the same way HTTPS is proven.

The value is in the join. Most of the parts are other people’s work. That is the design, not an apology for it.

The single novel contribution is the Broadcast Supersession Protocol (BSP) — an append-only, publicly auditable transparency log of signed corrections and withdrawals, built on the Certificate Transparency construction (RFC 9162).

What it is not

Common misreadings, and the clause that rules them out
It is not…	Because	Source
A content moderation system	Only a publisher can correct their own record. Authority is scoped to the object’s own origin.	`BI-004 §3`
A truth arbiter	The log records what was said, and what is now said instead. It adjudicates nothing.	`BI-008 §1`
A deletion tool	A correction does not erase the original. The superseded version stays retrievable via Memento.	`BI-002 §4.5`
A product	The correction protocol is intended for donation to a standards body.	`BI-001 §7`

02

The problem

A newspaper prints a correction. A broadcaster reads one on air. Both mechanisms work, because both reach the same audience that saw the original. Retrieval systems break that assumption.

Once an AI system has ingested a broadcast — fetched it, chunked it, embedded it, indexed it — the original is no longer in one place. It is distributed across an index, a vector store, a cache, and possibly a set of model weights. When the broadcaster later discovers the figure was wrong, or a court orders the segment removed, there is no channel through which that correction reaches the systems now repeating it.

The specific gap

Retrieval systems have no deletion primitive.

There is no standard message meaning “the thing you ingested is wrong; stop using it.”
A correction that does not arrive is not a correction.

The publisher has discharged its obligation, and nothing has changed.
The inverse failure is worse.

A system that honours any takedown it receives — without verifying who sent it — is a censorship tool. Solving propagation without solving authority produces something more dangerous than the original problem.

Both halves have to be solved together, or neither is solved. This is the constraint that shapes every design decision in the family.

03

The solution

Four mechanisms, in the order a correction actually travels through them. Everything below is specified in the documents in §05; nothing here is added.

Step 1

The object — what was broadcast

A Broadcast Object describes a piece of media: its identifiers, its essence (the video or audio, with a digest), its transcript, the people in it, its rights, and its provenance. Two fields carry most of the model’s weight.

`fidelityClass` — how the transcript came to exist

Value	Meaning
`script-derived`	The words as written for broadcast
`human-authored`	A person typed this
`human-corrected`	A machine drafted it; a named human took responsibility
`asr-inferred`	A machine guessed, and nobody checked

A consumer MUST NOT present asr-inferred text as a verbatim attributed quotation without disclosing that it is machine-generated. A machine’s guess at what someone said, in quotation marks with a speaker’s name attached, is a fabricated quote — and it is currently produced at scale by systems that have no way of knowing they are doing it.

Source: BI-002 §10 · BI-009 CON-6

`aiUsage` — training and retrieval are separate permissions

A publisher may permit retrieval and forbid training. No existing rights mechanism can express that combination, which is why the field exists. The two are stated separately and neither has a default.

Source: BI-002 §12.1 · BI-009 CON-4

Version identity is content-addressed. versionId is a SHA-256 digest over the RFC 8785 canonical form of the object. You can recompute it yourself and check it — you do not have to take the publisher’s word for it.

Source: BI-002 §4.4

Step 2

Authority — who may correct it

Authority is rooted in control of the object’s origin domain, proven with an ordinary X.509 certificate and the Web PKI. A publisher publishes an Authority Document at a well-known URL, listing its keys and what each key may do.

Scopes are not ordered

Scope	Permits
`object-sign`	Signing objects
`correct`	Issuing corrections
`supersede`	Replacing a version
`withdraw`	Retracting the object entirely

A key may hold correct without holding withdraw. The consequence is the whole point of the design:

If a publisher’s online signing key is stolen, the attacker can publish a false correction — but cannot erase the broadcast.

Withdrawal requires a separate key, held offline. A model in which correct implied withdraw would make the routine compromise catastrophic.

Source: BI-004 §4

Authority is evaluated as of the time the statement was logged — not now

When a publisher rotates its keys, every past correction must remain verifiable. A consumer therefore resolves the Authority Document as it stood when the statement was merged, using Memento.

This is the bug most implementations will write. A consumer that checks the current Authority Document instead would invalidate the publisher’s entire correction history on the first key rotation — and it would pass every happy-path test before doing so.

Source: BI-004 §7.1

Step 3

The log — how the correction becomes undeniable

The publisher signs a Supersession Statement and submits it to the logs the object lists. The log merges it into an append-only Merkle tree and returns a proof of inclusion. The leaf commits both the statement and the log’s own timestamp:

Leaf construction

leaf_hash = SHA-256( 0x00 ‖ JCS({ "timestamp": FIRST_MERGE_TIME,
                                  "statement":  STATEMENT }) )

FIRST_MERGE_TIME — the log’s own timestamp, assigned once, on first merge. Source: BI-008 §5.1

That timestamp is the value all authority decisions depend on (Step 2). Binding it into the leaf means a log cannot later restate when a correction was made, and therefore cannot slide a statement across a key-validity boundary. This is the fix for Critical finding C-1 — see §07 Security review.

Severity determines the deadline

Five severity classes. Each carries a Maximum Action Delay (MAD), measured from the consumer’s receipt of the statement.

Severity classes and their Maximum Action Delay
Severity	Meaning	MAD
`editorial`	Meaning unchanged	30 days
`substantive`	A stated fact was wrong	7 days
`material`	Could have caused the consumer to convey materially false information	24 hours
`withdrawal`	The publisher retracts the object	24 hours
`legal-withdrawal`	Compelled by legal order, erasure request, or safety	1 hour

Source: BI-008 §7

Step 4

The consumer — and why both halves matter

A conforming consumer polls the logs an object lists, verifies each new tree head and a consistency proof against the last one it saw, independently re-verifies the publisher’s authority — even though the log already accepted the statement — and then acts within the MAD: purging indexes, embeddings, and grounding data.

A consumer that honours every withdrawal it is handed has built a censorship vector, not a correction protocol.

Honouring a real withdrawal and refusing a forged one are the same requirement, not two. Both directions are normative, and both are tested:

The consumer acceptance requirement, in both directions
Scenario	Required outcome
Valid `legal-withdrawal`, correct scope	Purged within the hour
Cross-origin forged withdrawal	Rejected — and the content stays up
Withdrawal signed by a `correct`-scoped key	Rejected — and the content stays up

The two “content stays up” rows are the ones a naive implementation fails — and it fails them silently.

Source: BI-008 §7 · BI-009 CON-9, CON-12

04

Current status

Four things are routinely conflated. They are not the same, and this page keeps them apart.

Specification status

Frozen v1.0-FC1

Change control: errata only, and only from independent review. No new features. No new terminology. No Version 2.

BI-005 and BI-006 do not exist and are not being written. That is a decision, not an omission. Its one consequence is recorded: ODRL profile validation is reported not-validated, never pass.

Source: audit/CHANGELOG.md · audit/KNOWN-ISSUES.md

Implementation status

3 of 4 built

Reference Publisher
Reference Log
Reference Consumer #001 all 16 CON-* assertions exercised
Reference Monitor / Auditor not built

Source: audit/CONFORMANCE-REPORT.md

Operational readiness

None

Do not rely on this. FC1 has never been run at scale. Do not build a production archive on it. Do not treat a conformance claim against FC1 as durable.

Source: audit/PUBLICATION-READINESS.md

Review status

Zero external reviews

One internal adversarial audit, which found 2 Critical, 7 Major, 8 Minor and 6 Editorial defects. The remediation then surfaced three further defects the audit had missed — which is the expected behaviour of a real review, and an argument for the next one.

Source: audit/BI-v1.0-RC1-TECHNICAL-AUDIT.md

The verdict

Ready with conditions

The specification is ready for review. The system is not yet ready to be relied upon. Those are different claims, and we are only making the first.

— audit/PUBLICATION-READINESS.md

The three unmet conditions

These are the reasons FC1 is not Final. Detail in §09 Governance and §10.

01

A named namespace steward and IANA submitter

Blocks Final publication
02

A second, independent Log Operator

Blocks any Level 3 claim
03

Independent external engineering review

Blocks Final

05

Specification family

Five documents. Read them in this order.

Supporting artifacts

draft-alexander-bsp-00 — the Supersession Protocol as an IETF Internet-Draft
JSON Schema and JSON-LD context (93 terms)
Three worked examples — a television commercial, an interview, a livestream replay
Normative test vectors — Merkle roots, inclusion and consistency proofs, and the attack vectors a conformant log must reject

Conformance

112 testable assertions. Five roles — Publisher, Consumer, Log Operator, Monitor, Auditor. Three object levels — Level 1 Core, Level 2 Verified, Level 3 Governed.

The canonicalization suite gates everything else

An implementation whose RFC 8785 canonicaliser fails any golden vector must not claim conformance at any role or level. Not waivable. Not reportable as not-automatable. Fully automatable; no judgement involved.

Source: BI-009 §5.4

That gate exists because the reference implementation itself failed it. If we could ship that defect, so can anyone. See §07.

Six assertions cannot be automated. They are reported as not-automatable — never as pass — and each requires a named human attestor of record.

A conformance badge that quietly counts unverifiable claims as passes is worse than no badge, because it launders an attestation into a proof.

— audit/CONFORMANCE-REPORT.md

There is no conformance mark under 360WiSE’s control. There is a test suite. You run it yourself.

Source: BI-009 §7.3

06

Reference implementation

MassMediaHub is Reference Implementation #001. It is one implementation. It is not the specification, it is not privileged, and it is not required.

If any part of this family only works when MassMediaHub is involved, that is a defect — report it.

The acceptance criterion is portability, not adoption

A competing implementation must be able to implement these specifications, interoperate with any conformant log, and accept a publisher migrating away from MassMediaHub — without losing identity, provenance, or correction continuity.

A feature that makes migration harder is a defect, not a moat.

— BI-009 §7.4

Reference Consumer #001

Until it was built, no consumer existed anywhere that honoured a correction. A correction protocol with zero honouring consumers is a paper, not infrastructure.

It implements all sixteen CON-* assertions: log subscription, tree-head and consistency verification, independent authority verification at the committed timestamp, poll-interval enforcement, severity-driven purging, an auditable action record — and the refusal path described in Step 4 above.

One implementation now exercises the consumer role. That is not the same as independent interoperability, and this page does not claim otherwise.

Reference implementation in detail

07

Security review

The two Critical findings below were raised against our own work, in an audit commissioned to reject it. Both are published unedited.

Critical C-1 Resolved

The transparency log could silently rewrite the past

The log’s timestamp decides whether a publisher’s signing key was authorised at the moment a correction was made. Every authority decision turns on it. In the previous candidate, that timestamp was not committed to the Merkle tree at all.

A log could restate it after the fact — breaking no leaf hash, breaking no consistency proof — sliding a statement across a key-validity boundary and turning a valid correction into an “unauthorised” one, or resurrecting a withdrawal that had been repudiated. No misbehaviour by the publisher was required. The log alone could do it.

RFC 9162 does not have this hole; its Merkle leaf embeds a timestamped entry. BSP had dropped that structure while claiming to adopt the construction unmodified.

Fixed The leaf now binds the first-merge timestamp, and a one-millisecond restatement is a hard verification failure — proven by regression test.

Critical C-2 Resolved

The reference canonicaliser was not RFC 8785

It sorted JSON keys by Unicode code point; RFC 8785 requires UTF-16 code-unit order. The two disagree for any key containing an emoji or a rare CJK character. It also emitted 1e-07 where the standard requires 1e-7.

A single non-conformant canonicaliser computes a different hash for the same statement. Every proof it emits fails against an independent verifier — and nobody notices until an auditor tries to reconcile two trees.

Fixed And now gated by 30 golden vectors, disqualifying at every conformance level.

What remains open

Unsolved and partially-solved problems, stated rather than buried
Issue	Position
Proof of purge is unsolved K-4	We can prove we purged retrieval indexes, embeddings, and grounding. We cannot prove absence from model weights, and we do not claim to. Where content has reached weights, the consumer reports compliance incomplete, with the reason.
Retroactive repudiation K-1	Narrowed by C-1 — the log-side half is closed. A publisher back-dating its own key revocation remains bounded, not eliminated. Full closure requires key transparency (v1.1).
Domain hijack K-2	Unclosable at this layer, by anyone.

Full security review and audit

08

Downloads

Everything is published. Nothing is gated.

Verify it yourself

Do not take this page on trust. The suites run offline, with no privileged access and no cooperation from us.

Verification suite

cd spec
python3 validate.py                    # example objects
python3 tests/negative_tests.py        # invalid documents must be rejected
python3 bsp/reference_merkle.py        # test vectors, attack suite, idempotence
python3 tools/family_check.py          # cross-document consistency

cd ../implementations/massmediahub-ri-001/core
python3 test_canonical.py              # 30 RFC 8785 golden vectors — the C-2 gate
python3 test_authority.py              # BI-004 §7.2 verification algorithm

cd ../../massmediahub-consumer-001
python3 tests/test_consumer.py         # CON-1 … CON-16

# the manifest served on this site is the SAME artifact as the one in the package.
# if these bytes differ, the served copy is wrong:
curl -sO https://360wise.com/broadcast-infrastructure/downloads/audit/MANIFEST.json
grep 'audit/MANIFEST.json' SHA256SUMS.txt | sha256sum -c -

The complete verification suite, as shipped in the Public Review Package.

09

Governance

The correction protocol is intended for donation to a standards body. It should not be ours.

Source: BI-001 §7

The namespace has no steward

This blocks Final publication

The vocabulary this specification depends on resolves under a domain with no named custodian and no published continuity commitment, and no named entity owns the required IANA registration.

Every technical mitigation is in place — a versioned context, a defined prefix-reallocation rule, and identifiers provably stable across a namespace move. All of them presuppose an operator who does not exist. You cannot assess the durability of a thirty-year archive whose vocabulary might stop resolving — and durability is the entire proposition.

Three options are documented. No decision has been made.

We need a second, independent log operator

Level 3 requires two independent logs. “Independent” is defined normatively and is not self-assertable: distinct legal entities, no common control, distinct trust anchors — verifiable from each log’s own published metadata.

MassMediaHub cannot reach Level 3 alone, and its own conformance code refuses to claim otherwise. A correction protocol whose only log is operated by the reference implementer has a chokepoint exactly where it claims not to have one.

We are not offering a partnership, a fee, or a governance seat. Any of those would destroy the independence the specification requires. We are offering the specification and the test suite.

Disclosure

Conflict of interest

360WiSE is simultaneously the editor of this specification family, the candidate interim steward of its namespace, and the operator of Reference Implementation #001. That concentration is a legitimate concern for a reviewer to raise. It is stated here rather than left to be discovered.

Governance and stewardship in detail

10

Request for independent engineering review

This page is a request for adversarial review, not an announcement.

In descending order of usefulness:

01

Write an independent RFC 8785 canonicaliser and check that your leaf hashes match ours.

This is how C-2 was found. It remains the single most valuable thing an external reviewer can do.
02

Try to make Reference Consumer #001 purge something it should not.

If you succeed, you have found a censorship vector — and it must be known before anyone deploys this.
03

Run a second independent log.

The onboarding package is operator-neutral and published in full.
04

Tell us the timestamp binding is insufficient, if it is.

C-1 is the load-bearing fix in FC1. If it is wrong, everything above it is wrong.

Submit an Independent Engineering Review

Email [email protected]

Security findings, interoperability reports, conformance issues, implementation feedback, and specification comments are welcome.

Substantive technical reviews may be published, with attribution unless anonymity is requested.

If you are…	Read
Evaluating the idea	BI-001, then §03 The solution above — then stop
Implementing a publisher	`BI-002` → `BI-004` → `BI-009`
Implementing a consumer	`BI-008 §7` → `BI-004 §7` → `BI-009 CON-*`
Operating a log	`BI-008 §5–§11` → the Log Operator Onboarding Package
Reviewing it adversarially	The audit first, then `BI-008 §5` and `BI-004 §7`

What Broadcast Infrastructure is

What it is not

The problem

The specific gap

Retrieval systems have no deletion primitive.

A correction that does not arrive is not a correction.

The inverse failure is worse.

The solution

The object — what was broadcast

fidelityClass — how the transcript came to exist

aiUsage — training and retrieval are separate permissions

Authority — who may correct it

Scopes are not ordered

Authority is evaluated as of the time the statement was logged — not now

The log — how the correction becomes undeniable

Severity determines the deadline

The consumer — and why both halves matter

Current status

The verdict

The three unmet conditions

A named namespace steward and IANA submitter

A second, independent Log Operator

Independent external engineering review

Specification family

Supporting artifacts

Suggested reading path

Conformance

Reference implementation

The acceptance criterion is portability, not adoption

Reference Consumer #001

Security review

The transparency log could silently rewrite the past

The reference canonicaliser was not RFC 8785

What remains open

Downloads

Verify it yourself

Governance

The namespace has no steward

We need a second, independent log operator

Disclosure

Request for independent engineering review

Write an independent RFC 8785 canonicaliser and check that your leaf hashes match ours.

Try to make Reference Consumer #001 purge something it should not.

Run a second independent log.

Tell us the timestamp binding is insufficient, if it is.

Submit an Independent Engineering Review

From verified identity to independent recognition.

Infrastructure & Standards

Distribution

Governance

Company

`fidelityClass` — how the transcript came to exist

`aiUsage` — training and retrieval are separate permissions