Red Anvil Creative: September 2026

Product Requirements Document

A deterministic publisher-supplied information format for verifiable digital provenance

Document Control

Field	Value
Product	Dumpty Humpty — Project 20
Document Type	Product Requirements Document (PRD)
Scope	DH Blocks deterministic normalized-content profile
Profile	`dh-blocks-v1`
Version	0.2
Status	Phase 0 Schema-Freeze Candidate — final for current review cycle
Owner	Rhombus — Product
Last Updated	September 7, 2026
Related Document	Dumpty Humpty PRD v1.3

1. Executive Summary

Dumpty Humpty is an open information-provenance protocol built around a simple distinction:

The exact bytes of a document are not the same thing as the information represented by those bytes.

A webpage may change because an advertisement changed, a tracking script changed, the site's navigation changed, or the page was reformatted for mobile. None of those changes necessarily mean the article itself changed.

Conversely, two pages can look almost identical while containing a meaningful change to the published information.

Dumpty Humpty therefore separates:

Representation — the exact bytes that existed;
Artifact — the normalized information represented by those bytes;
Artifact Claim — the signed claim an identity makes concerning that information.

The DH Blocks Profile defines the deterministic publisher-supplied format used to create textual Artifacts.

Instead of asking a verifier to scrape an arbitrary HTML page and guess which parts constitute “the article,” the publisher supplies a structured JSON representation of the information it considers canonical.

That representation can then be validated, canonicalized, hashed, signed, cited, mapped to derivatives, corrected, and independently verified.

The core requirement is:

Two independent conforming implementations given the same valid DH Blocks information must calculate the same canonical bytes, block identifiers, and Artifact ID.

The MVP deliberately removes heuristic HTML extraction from the trust path.

The publisher declares the canonical information.

Dumpty Humpty makes that declaration deterministic and independently verifiable.

2. Product Promise

Make canonical published information deterministic without pretending that arbitrary webpage extraction is proof.

DH Blocks does not attempt to decide what a publisher “really meant.”

It provides a precise machine representation in which the publisher explicitly states what information it considers canonical.

The protocol then ensures that everyone derives the same identifier from that declaration.

3. Problem & Context

Most published textual information is delivered through HTML.

HTML is an excellent presentation format.

It is a poor universal canonical information format.

A modern webpage may contain:

article text;
navigation;
advertisements;
analytics;
personalization;
accessibility structures;
dynamic widgets;
recommended stories;
embedded social content;
scripts;
styling;
responsive markup;
user-specific state.

Two extraction systems can therefore process the same page and produce different versions of “the article.”

If those extracted results are hashed, they produce different identifiers.

That makes heuristic extraction unsuitable as the foundation of a cryptographic provenance system.

Dumpty Humpty instead uses a publisher-supplied canonical information representation.

Publisher information
        ↓
DH Blocks JSON
        ↓
Exact Representation
        ↓
Validation + JCS canonicalization
        ↓
Normalized Artifact

The HTML remains independently verifiable as exact bytes where appropriate.

It is not silently treated as equivalent to the normalized Artifact.

4. Goals

The DH Blocks Profile must:

Define a publisher-supplied JSON representation of normalized textual information.
Guarantee deterministic Artifact-ID derivation across independent implementations.
Separate exact-byte identity (dh:rep:) from normalized-content identity (dh:art:).
Provide stable block-level addressing for corrections, derivation mappings, citations, and downstream provenance.
Make invalid input fail consistently.
Reject invalid information rather than silently “repairing” it.
Coexist with exact-byte provenance systems such as C2PA.
Supply conformance vectors sufficient to prove interoperability between independently written implementations.
Remain simple enough for publishers to generate without replacing their existing publishing systems.
Freeze the semantics of dh-blocks-v1 once Phase 0 completes.

5. Non-Goals

DH Blocks v1 does not attempt to:

extract canonical information from arbitrary HTML;
determine factual truth;
normalize semantic equivalence between independently authored documents;
preserve page styling, CSS, fonts, layout, animation, or responsive behavior;
carry correction history directly inside normalized information;
carry publisher identity directly inside normalized information;
carry protocol timestamps directly inside normalized information;
carry hosting URLs merely because they identify where a page was served;
support arbitrary block extensions in v1;
perform formal media-type registration during Phase 0;
preserve an external code file byte-for-byte inside normalized article text.

Hosting and protocol URLs therefore remain outside normalized content.

A URL that is itself part of the published information—such as a citation or hyperlink target—may appear in a semantic reference.

6. Users

6.1 Publisher

The publisher wants to declare:

This is the informational content I consider canonical.

The publisher should be able to make that declaration without requiring consumers to trust the publisher's software.

6.2 Verifier

The verifier wants to independently calculate the same Artifact ID and determine whether a claimed REPRESENTS relationship is mechanically valid.

6.3 Protocol Implementer

An implementer needs enough specificity that two separately written systems produce identical outputs without coordinating implementation details.

6.4 Downstream Provenance Systems

Correction propagation, citation systems, AI transformation receipts, evidence systems, and derivation tracking need stable sub-document identifiers.

7. Core Identity Model

DH Blocks separates exact serialization from normalized information.

7.1 Exact Representation

The exact bytes receive:

dh:rep:<multibase(multihash(raw bytes))>

Any byte change produces a different Representation.

That includes changes to:

JSON indentation;
insignificant JSON whitespace;
property order;
line formatting.

7.2 Artifact

The validated JSON data model is serialized using JCS and receives:

dh:art:<multibase(multihash(canonical bytes))>

Different byte Representations may therefore produce the same Artifact.

Example:

Pretty JSON     → Representation R1
Compact JSON    → Representation R2
Different order → Representation R3

R1 ≠ R2 ≠ R3

but:

R1 ─┐
R2 ─┼── dh-blocks-v1 ──→ Artifact A
R3 ─┘

This behavior is intentional.

8. Profile Identifier and Media Type

The normative profile identifier is:

dh-blocks-v1

Protocol semantics depend on this value.

They do not depend solely on an HTTP media type.

During development, implementations should use:

application/vnd.dumptyhumpty.blocks+json

A later formally registered media type may replace this transport label.

Such registration must not change Artifact identity or profile semantics.

9. Dumpty Humpty ID Profile

DH Blocks v1 freezes its initial content-ID encoding.

9.1 Hash Algorithm

SHA-256

9.2 Multihash

The digest is encoded as a self-describing sha2-256 multihash.

9.3 Text Encoding

Externally serialized identifiers use:

multibase base32lower
without padding

with the normal multibase prefix:

9.4 Representation ID

dh:rep:<base32lower(multihash(SHA-256(raw_bytes)))>

Example shape:

dh:rep:b...

9.5 Artifact ID

dh:art:<base32lower(multihash(SHA-256(canonical_artifact_bytes)))>

Example shape:

dh:art:b...

9.6 Protocol Object ID

Other Dumpty Humpty objects use:

dh:obj:<base32lower(multihash(SHA-256(canonical_object_bytes)))>

9.7 Block Hash

Block hashes use the same base32lower multihash representation:

b...

A block hash does not receive its own global dh: namespace because a complete block reference also contains its parent Artifact ID.

10. Numeric Profile

All integers in dh-blocks-v1 must fall within:

0 – 9007199254740991

inclusive unless a field specifies a tighter range.

This is:

2^53 - 1

The restriction prevents disagreement between arbitrary-precision implementations and implementations based on IEEE-754 binary64 numbers.

Negative zero is invalid.

No field in DH Blocks v1 requires floating-point values.

11. Verifier Processing Pipeline

A conforming verifier performs the following operations in order.

Failure terminates Artifact derivation.

Step 1 — Exact Representation Hash

Hash the exact byte stream before decoding or normalization.

Produce:

dh:rep:...

Step 2 — UTF-8 Decoding

The Representation must decode as valid UTF-8.

Malformed UTF-8 is invalid.

Invalid Unicode scalar values are invalid.

Step 3 — JSON Parsing

Reject input containing:

malformed JSON;
duplicate property names;
non-finite numbers;
lexical negative zero;
integers outside the safe-integer profile;
values incompatible with JCS.

Step 4 — JSON Schema Validation

Validate the document against the frozen DH Blocks schema.

Step 5 — Normative Semantic Validation

Validate requirements that JSON Schema alone cannot express adequately:

language-tag syntax;
canonical language case;
Unicode NFC;
whitespace restrictions;
annotation ordering;
annotation boundaries;
reference resolution;
footnote resolution;
identifier validity.

The verifier does not repair invalid information.

Step 6 — JCS Serialization

Serialize the validated JSON data model using RFC 8785 JSON Canonicalization Scheme.

Step 7 — Artifact Hash

Calculate:

SHA-256(JCS(document))

and encode the result using the Dumpty Humpty ID profile.

Step 8 — `REPRESENTS`

A statement:

Representation R REPRESENTS Artifact A

is mechanically valid under dh-blocks-v1 only when:

derive_artifact(R, "dh-blocks-v1") == A

Otherwise:

INVALID REPRESENTS RELATIONSHIP

A publisher signature cannot override a failed calculation.

12. Top-Level Document

Required properties:

profile
language
blocks

Optional properties:

direction
references

No additional top-level properties are permitted.

Minimal structure:

{
  "profile": "dh-blocks-v1",
  "language": "en",
  "blocks": []
}

The blocks array must contain at least one block.

13. Language

language must:

syntactically conform to BCP 47 / RFC 5646;
contain ASCII subtags;
use lowercase DH Blocks lexical form.

Examples:

en
en-us
fr-ca
zh-hant
x-example

The following is rejected:

en-US

The verifier does not silently convert it to:

en-us

Validation relies on frozen syntax rather than membership in a changing external language registry.

14. Text Direction

Optional values are:

ltr
rtl

auto is not permitted.

If direction is omitted, Dumpty Humpty makes no directional assertion.

Display software may infer direction locally, but that inference is not part of Artifact identity.

15. Ordinary Text Rules

Human-readable informational text must:

contain valid Unicode;
be NFC normalized;
contain no carriage returns;
use LF where multiline content is permitted;
contain no TAB characters;
preserve internal ordinary spaces exactly;
contain at least one non-whitespace character where the block requires informational text.

A verifier rejects non-conforming text.

It does not normalize the text and continue.

16. Code Text Rules

code blocks deliberately preserve more lexical information.

Code:

must contain valid Unicode;
must contain at least one Unicode scalar value;
may contain tabs;
may contain CR;
may contain LF;
does not require NFC;
preserves whitespace exactly.

If exact external source-code bytes matter, they should also be published as their own dh:rep: Representation.

17. Block Ordering

The blocks array is ordered.

Array position is part of the information model.

Moving a paragraph therefore changes the Artifact ID even when the paragraph's own block hash does not change.

No separate position field exists.

18. Block Types

DH Blocks v1 recognizes:

headline
subheadline
byline
dateline
heading
paragraph
blockquote
list_item
table
figure
caption
footnote
code

Unknown block types are invalid.

There is no general extension block mechanism in v1.

19. Basic Text Blocks

The following use the basic text structure:

headline
subheadline
byline
dateline
paragraph
blockquote
caption

Example:

{
  "type": "paragraph",
  "text": "The article text."
}

Optional:

annotations

text must contain at least one non-whitespace character.

20. Heading

Example:

{
  "type": "heading",
  "level": 2,
  "text": "Background"
}

level must be an integer between:

1 and 6

21. List Item

Example:

{
  "type": "list_item",
  "depth": 0,
  "style": "unordered",
  "text": "First item"
}

Allowed styles:

ordered
unordered

Depth:

0–32

22. Table

Example:

{
  "type": "table",
  "rows": [
    {
      "cells": [
        {
          "role": "header",
          "text": "Year"
        },
        {
          "role": "header",
          "text": "Value"
        }
      ]
    },
    {
      "cells": [
        {
          "role": "data",
          "text": "2026"
        },
        {
          "role": "data",
          "text": "42"
        }
      ]
    }
  ]
}

Each table must contain at least one row.

Each row must contain at least one cell.

Cell roles:

header
data

Optional cell fields:

rowspan
colspan

Both must be positive safe integers.

Row and cell ordering are normative.

An empty table cell is valid because structural emptiness can itself carry information.

23. Figure

Example:

{
  "type": "figure",
  "media_ref": "dh:rep:b...",
  "alt_text": "Satellite image of the affected region.",
  "credit": "Example Agency"
}

media_ref must identify:

dh:rep:...

or:

dh:art:...

A dh:rep: should be preferred when exact media bytes matter.

Mutable ordinary URLs must not be used as media_ref.

24. Caption

A caption is an independent block.

Example:

{
  "type": "caption",
  "text": "Figure 1. Satellite image taken September 7."
}

This allows captions to participate independently in:

correction mapping;
derivation;
block addressing;
citation.

25. Footnote

Example:

{
  "type": "footnote",
  "note_id": "n1",
  "text": "Source methodology is described in Appendix B."
}

note_id must:

match ^[A-Za-z0-9._-]{1,64}$;
be unique within the document.

A footnote_ref may reference only a footnote present in the same DH Blocks document.

External references use citations instead.

26. Code

Example:

{
  "type": "code",
  "language": "python",
  "text": "print('hello')\n"
}

language is informational.

No programming-language registry is normative in v1.

27. Inline Annotations

DH Blocks v1 supports:

link
citation
footnote_ref

Offsets are:

zero-based;
start-inclusive;
end-exclusive;
measured in UTF-8 bytes of the block's text.

Offsets must fall on UTF-8 code-point boundaries.

28. Annotation Ordering

Annotations must appear in strictly increasing start order.

A verifier rejects unsorted annotation arrays.

It does not silently reorder them before hashing.

This prevents two different ordered arrays from representing what appears to be the same annotation structure while producing different Artifact IDs accidentally.

29. Annotation Validity

An annotation is invalid when:

end <= start

or when:

either endpoint falls outside the text;
either endpoint splits a UTF-8 sequence;
annotations overlap;
annotations are not ordered correctly.

Adjacent annotations are permitted.

30. Link Annotation

Example:

{
  "kind": "link",
  "start": 10,
  "end": 20,
  "target": "https://example.org/"
}

No URL normalization is performed.

The target string is part of normalized informational content exactly as supplied.

31. Citation Annotation

Example:

{
  "kind": "citation",
  "start": 39,
  "end": 45,
  "ref": "report"
}

The referenced local key must exist in the top-level references object.

32. Footnote Reference

Example:

{
  "kind": "footnote_ref",
  "start": 12,
  "end": 13,
  "note_id": "n1"
}

The corresponding footnote must exist in the same document.

33. References

Example:

{
  "references": {
    "report": {
      "kind": "artifact",
      "target": "dh:art:b..."
    }
  }
}

Reference keys must match:

^[A-Za-z0-9._-]{1,64}$

Supported kinds:

artifact
representation
claim
url
doi
other

Each reference requires:

kind
target

Optional:

label

34. Reference Semantics

Reference keys are structural identifiers local to the document.

For example:

report

and:

source1

produce structurally different documents even when they point to the same target.

DH Blocks deliberately does not attempt to recognize those as semantically equivalent.

DH Blocks canonicalizes serialization and validates structure. It does not canonicalize meaning.

This means two publishers independently encoding apparently identical articles do not necessarily produce the same Artifact unless their canonical DH Blocks data models are actually identical.

35. Block Hash

Each block receives:

block_hash =
base32lower(
    multihash(
        SHA-256(
            JCS(block_object)
        )
    )
)

The block hash is not stored inside the block itself.

36. Duplicate Blocks

Two identical canonical blocks produce the same block hash.

A complete Block Reference therefore contains:

artifact_id
block_hash
occurrence

occurrence is the zero-based count of that hash encountered so far in document order.

Example:

{
  "artifact_id": "dh:art:b...",
  "block_hash": "b...",
  "occurrence": 1
}

This identifies the second occurrence of an identical block.

37. Block Maps

A derivation relationship may map one block to another.

Example:

{
  "source": {
    "artifact_id": "dh:art:b...",
    "block_hash": "b...",
    "occurrence": 0
  },
  "target": {
    "artifact_id": "dh:art:b...",
    "block_hash": "b...",
    "occurrence": 0
  },
  "relation": "MODIFIED"
}

Allowed relations:

IDENTICAL
MODIFIED
SPLIT
MERGED

IDENTICAL is mechanically verifiable through equality of the referenced canonical blocks.

MODIFIED, SPLIT, and MERGED remain provenance assertions.

They do not constitute cryptographic proof of semantic faithfulness.

38. Artifact ID Calculation

The validated DH Blocks document is serialized using JCS:

canonical_artifact_bytes =
JCS(validated_document)

Then:

artifact_digest =
SHA-256(canonical_artifact_bytes)

Then:

artifact_id =
dh:art:<base32lower(multihash(artifact_digest))>

The Artifact ID commits to the complete ordered informational document.

Block hashes are subordinate addressing mechanisms.

39. HTML Integration

HTML and DH Blocks perform different jobs.

HTML Representation
dh:rep:...
       |
       | advertises or is signed-associated-with
       v
DH Blocks Representation
dh:rep:...
       |
       | mechanically REPRESENTS
       v
Artifact
dh:art:...

For MVP:

Only the valid DH Blocks Representation mechanically REPRESENTS the DH Blocks Artifact.

An arbitrary HTML page does not.

A publisher may make a separately signed association between the HTML and the DH Blocks information.

That is a provenance assertion, not canonicalization proof.

40. C2PA Interoperation

C2PA and DH Blocks operate at complementary layers.

Conceptually:

Exact HTML bytes
      ↓
C2PA / exact Representation proof

DH Blocks JSON
      ↓
DH Blocks exact Representation
      ↓
dh-blocks-v1
      ↓
Normalized Artifact

Both may participate in the same Dumpty Humpty Artifact Claim.

Their proofs remain independently inspectable.

Dumpty Humpty must not modify imported C2PA credentials.

41. JSON Schema

The machine-readable schema uses JSON Schema Draft 2020-12.

Schema validation is necessary but not sufficient.

The normative validator additionally checks:

UTF-8;
duplicate object properties;
safe numeric values;
language syntax;
language case;
NFC;
whitespace rules;
annotation ordering;
annotation byte boundaries;
reference resolution;
footnote resolution;
Dumpty Humpty IDs.

42. Reference Validator

A small reference validation CLI is a required Phase 0 deliverable.

Minimum commands:

dh-blocks validate <file>
dh-blocks canonicalize <file>
dh-blocks representation-id <file>
dh-blocks artifact-id <file>
dh-blocks block-ids <file>

Optional:

dh-blocks inspect <file>

Example:

$ dh-blocks validate article.json
VALID dh-blocks-v1

$ dh-blocks artifact-id article.json
dh:art:b...

Invalid documents return a nonzero exit status.

Machine-readable error output should also be supported.

43. Normative Error Classes

Initial error identifiers:

DH-BLOCKS-E001 INVALID_UTF8
DH-BLOCKS-E002 INVALID_JSON
DH-BLOCKS-E003 DUPLICATE_MEMBER
DH-BLOCKS-E004 UNSAFE_INTEGER
DH-BLOCKS-E005 NEGATIVE_ZERO
DH-BLOCKS-E006 SCHEMA_INVALID
DH-BLOCKS-E007 LANGUAGE_INVALID
DH-BLOCKS-E008 LANGUAGE_NONCANONICAL
DH-BLOCKS-E009 TEXT_NON_NFC
DH-BLOCKS-E010 TEXT_INVALID_WHITESPACE
DH-BLOCKS-E011 EMPTY_INFORMATIONAL_TEXT
DH-BLOCKS-E012 ANNOTATION_ORDER
DH-BLOCKS-E013 ANNOTATION_BOUNDARY
DH-BLOCKS-E014 ANNOTATION_OVERLAP
DH-BLOCKS-E015 REFERENCE_MISSING
DH-BLOCKS-E016 FOOTNOTE_MISSING
DH-BLOCKS-E017 FOOTNOTE_DUPLICATE
DH-BLOCKS-E018 INVALID_DH_ID
DH-BLOCKS-E019 INVALID_REPRESENTS

The exact taxonomy may be refined before Phase 0 exits.

Conformance fixtures must nevertheless fail under the same normative error classes across independent implementations.

44. Conformance Tests

DH Blocks is not considered interoperable because one implementation works.

At least two independent implementations must pass the same vector suite.

V1 — Serialization Independence

Change only:

indentation;
insignificant JSON whitespace;
object-property ordering.

Expected:

different dh:rep
same dh:art

V2 — Content Mutation

Change one character in one paragraph.

Expected:

different dh:rep
different dh:art
different affected block hash
unchanged unaffected block hashes

V3 — Block Movement

Move an unchanged paragraph.

Expected:

same paragraph block hash
different Artifact ID

V4 — Duplicate Blocks

Two identical paragraphs.

Expected:

same block hash
occurrence 0
occurrence 1

V5 — Invalid UTF-8 Annotation Boundary

Expected:

DH-BLOCKS-E013

V6 — Missing Citation

Expected:

DH-BLOCKS-E015

V7 — Invalid `REPRESENTS`

If the claimed Artifact differs from the calculated Artifact:

INVALID REPRESENTS RELATIONSHIP

V8 — Arbitrary HTML

HTML input does not qualify as dh-blocks-v1.

V9 — Duplicate JSON Member

Expected:

DH-BLOCKS-E003

V10 — Maximum Safe Integer

9007199254740991

Expected:

valid

V11 — Unsafe Integer

9007199254740992

Expected:

DH-BLOCKS-E004

V12 — Negative Zero

Expected:

DH-BLOCKS-E005

V13 — Non-NFC Ordinary Text

Expected:

DH-BLOCKS-E009

V14 — NFC Ordinary Text

Expected:

valid

V15 — CRLF in Ordinary Text

Expected:

DH-BLOCKS-E010

V16 — Tab in Ordinary Text

Expected:

DH-BLOCKS-E010

V17 — Code Whitespace

Code containing TAB, CR, and LF:

valid

V18 — Annotation Ordering

Valid non-overlapping annotations in descending order:

DH-BLOCKS-E012

V19 — Empty Paragraph

Expected:

DH-BLOCKS-E011

V20 — Whitespace-Only Paragraph

Expected:

DH-BLOCKS-E011

V21 — Empty Table Cell

Expected:

valid

V22 — Noncanonical Language Case

en-US

Expected:

DH-BLOCKS-E008

V23 — Canonical Language Form

en-us

Expected:

valid

V24 — Missing Footnote

Expected:

DH-BLOCKS-E016

V25 — Duplicate Footnote ID

Expected:

DH-BLOCKS-E017

V26 — Different Local Reference Identifiers

Two otherwise similar documents use different local reference names for the same destination.

Expected:

different Artifact IDs

This confirms that DH Blocks does not attempt semantic-equivalence canonicalization.

45. Minimal Valid Example

{
  "profile": "dh-blocks-v1",
  "language": "en",
  "blocks": [
    {
      "type": "headline",
      "text": "Example Article"
    },
    {
      "type": "byline",
      "text": "Alice Reporter"
    },
    {
      "type": "paragraph",
      "text": "This is the first paragraph."
    },
    {
      "type": "paragraph",
      "text": "The evidence is described in the cited report.",
      "annotations": [
        {
          "kind": "citation",
          "start": 39,
          "end": 45,
          "ref": "report"
        }
      ]
    }
  ],
  "references": {
    "report": {
      "kind": "artifact",
      "target": "dh:art:bexampleplaceholder"
    }
  }
}

The example identifier is illustrative.

Actual conformance fixtures must use syntactically valid encoded IDs.

46. Registry Governance

Dumpty Humpty maintains public registries for protocol identifiers.

Initial registry categories include:

profiles
block types
relationship types
status types
operation types
cryptographic suites
legacy verification suites
witness types
Merkle profiles
verification-report versions

Registry changes use a public specification process.

47. DH-RFC Process

Substantive changes receive permanent proposal numbers:

DH-RFC-0001
DH-RFC-0002
...

Each proposal contains:

Motivation.
Exact proposed specification.
Security implications.
Privacy implications.
Compatibility analysis.
Test vectors where appropriate.
Implementation notes.

Published registry history remains public.

48. Registry Immutability

A published registry entry is immutable.

If a mistake is discovered, the entry may be:

deprecated
superseded
replaced

It is not silently edited.

Historical verification therefore does not depend on today's interpretation of yesterday's identifier.

49. Dependencies

DH Blocks v1 depends on:

RFC 8785 / JCS;
BCP 47 / RFC 5646 syntax;
JSON Schema Draft 2020-12;
SHA-256;
Dumpty Humpty's multihash/multibase ID profile;
the parent Dumpty Humpty Representation / Artifact / Artifact Claim model.

The HTML discovery mechanism is not required for Artifact derivation.

C2PA integration is an independent interoperability layer.

50. Parent Dumpty Humpty PRD Requirement

The parent Dumpty Humpty architecture must represent the MVP relationship as:

Web Representation
dh:rep:...
     ↓
exact-byte verification / C2PA where available

advertises or is signed-associated-with

DH Blocks Representation
dh:rep:...
     ↓
mechanically REPRESENTS using dh-blocks-v1

Artifact
dh:art:...
     ↓
Artifact Claim

It must not state that arbitrary HTML mechanically REPRESENTS a DH Blocks Artifact.

51. Phase 0 Exit Criteria

DH Blocks leaves Phase 0 only when:

The requirements are translated into a normative implementation specification.
The JSON Schema is frozen.
ID encoding is frozen.
Unicode rules are frozen.
Language rules are frozen.
Block definitions are frozen.
Annotation rules are frozen.
Block-reference calculation is frozen.
At least two independent implementations produce identical outputs for every valid vector.
Invalid vectors fail under the same normative classifications.
The reference CLI passes the full vector suite.
The parent Dumpty Humpty PRD reflects the correct HTML/DH Blocks relationship.
Provisional media-type documentation is published.
The registry and DH-RFC process exist.

52. Implementation Order

Phase 0 engineering should proceed in this order:

1. Raw Representation hashing
2. JSON parser constraints
3. Schema validation
4. Semantic validation
5. JCS canonicalization
6. Artifact ID derivation
7. Block hashing
8. Block Reference calculation
9. REPRESENTS verification
10. Reference CLI
11. Conformance vectors
12. Second independent implementation

No blockchain, node network, publisher CMS integration, browser extension, or user interface is required to validate the DH Blocks core.

53. Risks to Revisit

53.1 Figure Workflow

Publishers may not always have a content-addressed media identifier at article-composition time.

Publisher tooling may need to automate media hashing.

53.2 Reference Identifier Sensitivity

Changing:

report

to:

source1

changes the Artifact even if both resolve to the same reference.

This is intentional in v1 but should be evaluated during implementation.

53.3 Annotation Ergonomics

UTF-8 byte offsets are deterministic but awkward in environments whose normal string-indexing model is UTF-16.

Publisher tooling should hide this complexity.

53.4 Table Complexity

Real publishing systems may eventually require richer table semantics.

The v1 model should not be expanded until actual use demonstrates the requirement.

53.5 Cross-Profile Equivalence

Future canonicalization profiles may produce human-similar information.

The protocol must not automatically assume equivalence between those Artifacts.

54. Architectural Requirements

A conforming implementation must derive a DH Blocks Artifact without:

network access;
machine learning;
DOM extraction;
natural-language interpretation;
semantic similarity;
external publisher trust;
implementation-specific normalization.

The result must depend entirely on:

input bytes
+
dh-blocks-v1
+
frozen normative standards

55. MVP Proof

DH Blocks succeeds when:

Publisher DH Blocks
        ↓
Independent validator A
        ↓
Artifact A

Publisher DH Blocks
        ↓
Independent validator B
        ↓
Artifact A

and both implementations also agree on:

block hashes;
invalid-input classifications;
REPRESENTS validity;
canonical bytes.

The profile is not frozen merely because one implementation works.

56. Product Boundary

DH Blocks determines:

What structured information was declared and what deterministic identifier represents it?

It does not determine:

Is that information accurate?

It does not determine:

Is this the best possible representation of the article?

It does not determine:

Did the publisher act honestly?

It establishes what the publisher declared and whether that declaration can be independently reconstructed.

57. Design Principle

The publisher tells Dumpty Humpty what information it considers canonical. Dumpty Humpty makes that declaration deterministic, signed, portable, and independently verifiable.

It does not guess the canonical article out of arbitrary HTML and pretend the guess is proof.

Current Status

DH Blocks PRD v0.2 is the final design version for the current review cycle.

It is now a:

Phase 0 Schema-Freeze Candidate

The document should remain stable until implementation or later deliberate review exposes a concrete contradiction, interoperability failure, security defect, or impractical requirement.

The next engineering path is intentionally narrow:

Schema
→ Validator
→ Canonicalizer
→ ID Generator
→ Block Addressing
→ Conformance Vectors
→ Independent Second Implementation

Only after those implementations agree should dh-blocks-v1 be declared frozen.

Monday, September 7, 2026

Dumpty Humpty — DH Blocks Profile

Product Requirements Document

Document Control

1. Executive Summary

2. Product Promise

3. Problem & Context

4. Goals

5. Non-Goals

6. Users

6.1 Publisher

6.2 Verifier

6.3 Protocol Implementer

6.4 Downstream Provenance Systems

7. Core Identity Model

7.1 Exact Representation

7.2 Artifact

8. Profile Identifier and Media Type

9. Dumpty Humpty ID Profile

9.1 Hash Algorithm

9.2 Multihash

9.3 Text Encoding

9.4 Representation ID

9.5 Artifact ID

9.6 Protocol Object ID

9.7 Block Hash

10. Numeric Profile

11. Verifier Processing Pipeline

Step 1 — Exact Representation Hash

Step 2 — UTF-8 Decoding

Step 3 — JSON Parsing

Step 4 — JSON Schema Validation

Step 5 — Normative Semantic Validation

Step 6 — JCS Serialization

Step 7 — Artifact Hash

Step 8 — REPRESENTS

12. Top-Level Document

13. Language

14. Text Direction

15. Ordinary Text Rules

16. Code Text Rules

17. Block Ordering

18. Block Types

19. Basic Text Blocks

20. Heading

21. List Item

22. Table

23. Figure

24. Caption

25. Footnote

26. Code

27. Inline Annotations

28. Annotation Ordering

29. Annotation Validity

30. Link Annotation

31. Citation Annotation

32. Footnote Reference

33. References

34. Reference Semantics

35. Block Hash

36. Duplicate Blocks

37. Block Maps

38. Artifact ID Calculation

39. HTML Integration

40. C2PA Interoperation

41. JSON Schema

42. Reference Validator

43. Normative Error Classes

44. Conformance Tests

V1 — Serialization Independence

V2 — Content Mutation

V3 — Block Movement

V4 — Duplicate Blocks

V5 — Invalid UTF-8 Annotation Boundary

V6 — Missing Citation

V7 — Invalid REPRESENTS

V8 — Arbitrary HTML

V9 — Duplicate JSON Member

V10 — Maximum Safe Integer

V11 — Unsafe Integer

Step 8 — `REPRESENTS`

V7 — Invalid `REPRESENTS`