03 · Conformance
Proving it — or disproving it
112 testable assertions across five roles and three object levels. Every requirement in the normative specifications appears here as something a machine can check, or as something a named human must attest to — never as something we simply assert.
- Assertions
- 112all testable
- Roles
- 5independently conformable
- Object levels
- 3Core, Verified, Governed
- Not automatable
- 6never reported as pass
Contents
01
The gate
Before any other assertion means anything, your canonicaliser must be correct. If it is not, every hash you compute is a different hash from everyone else's, and every proof you emit is worthless — including the ones that pass.
JCS-1 … JCS-8 — gating, not waivable
An implementation whose RFC 8785 canonicaliser fails any golden vector MUST NOT claim conformance at any role or at any level.
Not waivable. Not reportable as not-automatable. Fully automatable;
no judgement is involved. 30 golden vectors ship with the suite.
Source: BI-009 §5.4
Why this gate exists
The gate exists because the reference implementation itself failed it. If we could ship that defect, so can anyone.
The RC1 canonicaliser sorted JSON object keys by Unicode code point. RFC 8785 requires
UTF-16 code-unit order. The two agree on ASCII and disagree the moment a key contains an
emoji or a rare CJK character. It also emitted 1e-07 where the standard requires
1e-7.
Neither defect produces an error. It produces a different hash for the same statement — and nobody notices until an auditor tries to reconcile two trees and finds they disagree about history.
This is the single most valuable thing an external reviewer can do: write an independent RFC 8785 canonicaliser and check that your leaf hashes match ours. That is how C-2 was found. It can find the next one.
02
Five roles
Conformance is claimed per role, not per product. A system may be a conformant Publisher and a non-conformant Consumer. Say which.
| Role | Governed by | Prefix |
|---|---|---|
| Publisher | BI-002 (Levels 1–3), BI-008 §4, §8.1 | OBJ-*, PUB-* |
| Consumer | BI-002 §20.5, BI-008 §7, §13 | CON-* |
| Log Operator | BI-008 §5, §6, §8, §11 | LOG-* |
| Monitor | BI-008 §9 | MON-* |
| Auditor | BI-008 §10 | AUD-* |
The Consumer role is bidirectional
This is the requirement implementers most often half-implement, because the half they skip still passes their tests.
A consumer that honours every withdrawal it is handed has built a censorship vector, not a correction protocol.
| 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 |
| Log restates a committed timestamp by 1 ms | Rejected |
Source: BI-009 §4 · CON-9, CON-12
03
Three object levels
Levels describe the object, not the organisation. They are cumulative: Level 3 includes everything in Levels 1 and 2.
-
Level 1
Core
Identity, versioning, and description. The record exists and is addressable.
-
Level 2
Verified
Signed, with provenance. The record is attributable.
-
Level 3
Governed
Corrections propagate through independent logs. The record is correctable.
Nobody can claim Level 3 today — including us
Level 3 requires two independent supersession logs. "Independent" is defined normatively and is not self-assertable: distinct legal entities, no common control, distinct trust anchors — derived from each log's own published metadata, not from a flag the operator sets.
Only one log exists, and we operate it. MassMediaHub cannot reach Level 3 alone, and
its own conformance code refuses to claim otherwise — the self-asserted
is_self_operated boolean was deleted precisely because a commonly-owned second log
would simply set it to false.
Source: BI-008 §11.4.1 · erratum E-1 · M-2
Level 3 also has an unvalidatable corner
OBJ-3.3 and OBJ-3.4 validate an ODRL profile. BI-005 — the
document that would define that profile — does not exist and is not being written.
Those two assertions are therefore reported not-validated,
never pass. We could have quietly marked them green. We did not.
Source: audit/KNOWN-ISSUES.md
04
The four result values
Most conformance suites have two outcomes. This one has four, because "we could not check this" and "this is correct" are different facts, and collapsing them is how a badge becomes a lie.
| Value | Means | May it be reported as a pass? |
|---|---|---|
pass |
The suite checked it, mechanically, and it holds. | Yes |
fail |
The suite checked it and it does not hold. | No |
not-automatable |
No machine can decide this. A named human attestor of record must take responsibility for it, with a resolvable identity. | Never |
not-validated |
There is nothing to validate against — the artifact the assertion depends on does not exist (see BI-005). | Never |
A conformance badge that quietly counts unverifiable claims as passes is worse than no badge, because it launders an attestation into a proof.
05
The six that cannot be automated
Six assertions cannot be decided by a machine. They are the six that matter most, which is inconvenient and true.
Each requires a named human attestor of record with a resolvable identity. A conformance
claim covering any of them is invalid without one. not-automatable
is not a free pass — it is a signature line.
| Assertion | Why no machine can decide it |
|---|---|
OBJ-1.12Transcript fidelity |
Whether a transcript is truly human-corrected or was merely glanced at is a
fact about what a person actually did. No parser can see it.
|
PUB-5Severity accuracy |
Whether a correction is editorial or material is a judgement
about meaning. The incentive is always to under-classify — a lower
severity buys a longer deadline.
|
CON-16Proof of purge |
We can prove a purge from retrieval indexes, embeddings, and grounding. Absence from model weights cannot be proven, by us or anyone (K-4). |
| …and three others | Enumerated in BI-009, each with the same requirement. |
Where the purge cannot be completed, the consumer says so
If content has reached model weights, a conformant consumer reports compliance incomplete, with the reason. It does not quietly mark itself compliant and move on.
This is an admission, published deliberately. A correction protocol that claimed to un-train a model would be lying, and the lie would be discovered by the first person who looked.
Source: audit/KNOWN-ISSUES.md · K-4, K-6, erratum m-8
06
Current results
These are our own results, self-reported. Read them as a starting point for scrutiny, not as evidence.
| Role | Level | Assertions | Status |
|---|---|---|---|
| Canonicalizer | gate | 8 | 8 pass |
| Publisher | 1 | 14 | 14 pass |
| Publisher | 2 | 10 | 10 pass |
| Publisher | 3 | 10 | 10 pass · 2 not-validated (ODRL — BI-005 does not exist) |
| Authority | — | 24 | 24 pass |
| Log Operator | — | 15 | 15 pass |
| Consumer | — | 16 | 16 exercised by Reference Consumer #001 (43/43 acceptance). Self-reported. |
| Monitor / Auditor | — | 16 | 0 — not built |
Read the Consumer row carefully
The Consumer that exercises this protocol is ours. One implementation passing its own authors' test suite demonstrates that the protocol is implementable. It does not demonstrate that it is interoperable.
Every CON-* result on this page is a self-report until a Consumer is
written by someone with no stake in this succeeding. That remains the highest-value contribution
an external reviewer can make.
Source: audit/KNOWN-ISSUES.md · K-7 residual
No Monitor and no Auditor exist
Sixteen assertions are unexercised by anyone. Gossip is a MUST, and without
an auditor that gossips there is no defence against a log equivocating — presenting one
history to one consumer and a different history to another.
The protocol specifies the defence. Nothing implements it yet. That is stated, not hidden.
07
Certification, and why there is none
There is no conformance mark under 360WiSE's control. No badge, no logo, no approved-vendor list, no certification fee.
A mark we controlled would be a registry by another name — and this family's central architectural claim is that it has no registry, because a registry is a chokepoint.
We would also be certifying our own competitors, using a test suite we wrote, against a specification we edit. That is three conflicts of interest in one sentence.
Source: BI-009 §7.3
What replaces it
- You run the suite. It runs offline, with no privileged access and no cooperation from us.
-
You publish the result in the claim format of
BI-009 §8— including the failures. - Anyone can re-run it against you. That is the only check that means anything.
If a conformance mark is ever issued for this family, it should be issued by the standards body the protocol is donated to — not by us. See Governance.
08
The portability test
The acceptance criterion for this entire family is not adoption. It is portability.
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.
If any part of this family only works when MassMediaHub is involved, that is a defect — report it to [email protected].
We will treat it as a conformance bug in the specification, not as a feature of the product.
09
Run it yourself
Do not take this page on trust. Everything below runs offline, against the published package, with no cooperation from us.
cd spec
python3 validate.py # example objects validate against the schema
python3 tests/negative_tests.py # invalid documents MUST be rejected
python3 bsp/reference_merkle.py # RFC 9162 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 GATE (§01)
python3 test_authority.py # BI-004 §7.2 verification algorithm
cd ../../massmediahub-consumer-001
python3 tests/test_consumer.py # CON-1 … CON-16, both directions
Shipped in the Public Review Package. Verify the bytes first with
sha256sum -c SHA256SUMS.txt.
Start with test_canonical.py
If your canonicaliser disagrees with those 30 vectors, stop. Nothing downstream of it can be trusted, including the tests that pass.
10
Making a conformance claim
A claim is a public, checkable statement — not a marketing line.
A claim must state
| Field | Requirement |
|---|---|
| Role | Which of the five. Not "conformant" unqualified. |
| Level | Where levels apply. Level 3 requires two independent logs. |
| Version | v1.0-FC1. A claim without a version is not a claim. |
| Results | Every assertion, with its value — including every fail. |
| Attestor | A named human, with resolvable identity, for each not-automatable result. |
| The gate | All 8 JCS-* vectors, passed. Without this, the claim is void. |
Our own claim carries the same caveats
MassMediaHub is Reference Implementation #001. It is one implementation. It is not the specification, it is not privileged, and it is not required.
Its results are self-reported, its Consumer is the only one that exists, its Monitor and Auditor are not built, and it cannot claim Level 3. All four facts are on this page because a reviewer would find them anyway, and finding them themselves is worse.
Read BI-009 Reference implementation
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.