Turn 1 — User
What is a doc.html file and how does it store information?
This is a writing-room-tail doc.html: a chat exchange stored as an ordered sequence of witnessed <article> elements. No <nav id="manifest"> — shape detection finds the tail by the presence of <article data-witness> elements with valid witnesses.
Two witness epochs: a writing-room timestamp (YYYY-MM-DDTHH:MM:SSZ) records live entries in order; a consecrated SHA-256 hex digest seals a unit's bytes for all time. This file carries only consecrated witnesses.
To verify: detect tail shape, walk articles in document order, recompute SHA-256 over each article's raw inner UTF-8 bytes (untrimmed, §6.2), confirm each digest equals the stored data-witness. Single carrier per unit — no manifest link to cross-check (§6.3).
Kind vocabulary (declared in-band, §8.3): this body uses two data-kind values — transcription (a verbatim user turn) and synthesis (a model-authored assistant turn). data-kind is descriptive only; a conforming reader never branches trust on it.
What is a doc.html file and how does it store information?
A doc.html is a single, self-verifying HTML file. It stores information as addressable units — either <section> elements (manifest-first shape) or <article> elements (writing-room-tail shape) — each carrying a data-witness: a SHA-256 digest over the unit's raw inner bytes.
id; a reader fetches only #the-id it needs.You mentioned two shapes — manifest-first and writing-room-tail. What is the difference?
The two shapes differ in how a reader discovers addressable units:
<nav id="manifest"> listing every <section data-witness>. A reader reads the manifest first, decides which sections it needs, and fetches only those by #id.<article data-witness> elements read in document order. Suits a chat log or append-only body.The shapes are mutually exclusive: a document MUST be exactly one shape. A reader detects the shape first, then follows the appropriate discovery path.
Note: the comment above is part of this turn's witnessed bytes — it exercises the §6.2 rule that an </article> token inside an HTML comment MUST NOT be treated as this article's closing tag.
How does the witness work exactly? What bytes does SHA-256 cover?
The witnessed bytes are the bytes between the > that ends the opening tag and the < that begins the element's own closing tag — the raw inner span, UTF-8, untrimmed. No normalization, no trimming.
For a tail document the addressable element is <article>. The closing tag is found by a depth-walk that counts nested article tokens and skips any inside HTML comments. SHA-256 is then computed over those exact bytes.
data-char-count is the Unicode code-point count of the same slice — Array.from(inner).length in JavaScript. A reader that trims, re-encodes as UTF-16, or normalizes whitespace will get a different digest and fail.
What are the two witness epochs? What is the difference between a writing-room witness and a consecrated one?
The data-witness slot carries one of two formally disjoint grammars:
YYYY-MM-DDTHH:MM:SSZ, exactly 20 chars). Used while the document is live: timestamps must be strictly increasing in document order. An ordinal witness — fixes sequence, not bytes.The grammars are disjoint by length (20 vs 64) and alphabet (-T:Z never appear in hex). A reader recovers the epoch from the form alone — no separate kind attribute is needed. Consecration replaces a timestamp with the SHA-256 of the bytes it was witnessing. This file carries only consecrated witnesses — it is a sealed example.