diff --git a/.gitignore b/.gitignore
index 9401b1f..34db9cf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,6 +23,8 @@
 *.pdf
 paper/dist/
 paper/tmp/
+/tmp/
+/output/
 
 # OS files
 .DS_Store
diff --git a/Makefile b/Makefile
index 120f901..b6e56e1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-.PHONY: all check ietf paper paper-docker paper-arxiv paper-arxiv-docker w3c w3c-check
+.PHONY: all check ietf paper paper-diagram paper-docker paper-arxiv paper-arxiv-docker w3c w3c-check
 
 all: check ietf w3c-check paper
 
@@ -11,6 +11,10 @@ ietf:
 paper:
 	./scripts/build-paper.sh
 
+paper-diagram:
+	mmdc $(MERMAID_ARGS) -i diagrams/architecture1.mmd \
+		-o paper/images/architecture1.png -b white -w 1200 -s 2
+
 paper-docker:
 	./scripts/build-paper-in-docker.sh
 
diff --git a/README.md b/README.md
index 5b2a29e..8bcb49e 100644
--- a/README.md
+++ b/README.md
@@ -21,6 +21,7 @@ From the repository root:
 make check       # validate vectors and repository invariants
 make ietf        # regenerate the IETF XML, HTML, and text artifacts
 make paper       # build paper/htmltrust.pdf
+make paper-diagram # regenerate the paper architecture diagram
 make w3c         # serve the W3C draft at http://localhost:8000
 make w3c-check   # render the W3C draft and fail on ReSpec diagnostics
 ```
@@ -79,6 +80,12 @@ from `.docker/paper/Dockerfile`, then mounts the checkout into a short-lived
 container. Docker caches the package-install layer; source files and the PDF
 remain on the host. Set `HTMLTRUST_PAPER_IMAGE` to use another local tag.
 
+The generated paper diagram is committed. To change it, edit
+`diagrams/architecture1.mmd`, install Mermaid CLI with
+`npm install --global @mermaid-js/mermaid-cli`, and run
+`make paper-diagram`. Pass extra Mermaid CLI options through `MERMAID_ARGS`
+when Chromium needs a Puppeteer configuration file.
+
 ### W3C draft
 
 The W3C draft uses ReSpec. Run `make w3c`, open <http://localhost:8000>, and
@@ -88,13 +95,21 @@ writes its temporary snapshot under `$TMPDIR` when set, then `RUNNER_TEMP` or
 
 ## Understand implementation status
 
-The drafts define the target protocol. The reference repositories implement
-the stable `v0.2.2` canonicalization profile and the current end-to-end flow.
-The newest draft rules still require downstream implementation work. These
-include the v1 JCS signing object and location scope, safe signed URLs,
-parser-profile rejection, U+0040 escaping, complete RFC 8785 processing,
-resource ceilings, and the native browser lifecycle. The review documents
-identify each remaining gap.
+The reference repositories implement the v1 signing profile, including the
+JCS signing object, URL and origin scopes, HTTPS-only signed URLs, parser
+preflight, resource ceilings, and source-to-rendered browser lifecycle. The
+2026-08-28 evidence snapshot pins these tested revisions:
+
+| Component | Revision | Validation |
+|---|---|---|
+| Canonicalization | [`b0c8f305`](https://github.com/HTMLTrust/htmltrust-canonicalization/commit/b0c8f305425de190a7f209ac117d34f88c2b1946) | 123 shared fixtures across five language ports |
+| Browser verification library | [`d25c6d3c`](https://github.com/HTMLTrust/htmltrust-browser-client/commit/d25c6d3c2d0f4d67483da20853f22e94a11b89cc) | 51 tests |
+| Reference extension | [`5237f070`](https://github.com/HTMLTrust/htmltrust-browser-reference/commit/5237f07098da8b6542f0fd8f1c613ae8dbf4e6dd) | 64 tests plus a Chromium lifecycle check |
+| Directory server | [`f84f5148`](https://github.com/HTMLTrust/htmltrust-server-reference/commit/f84f51482ba2a925d9b5ff148185adf6dedef566) | 85 tests plus OpenAPI conformance |
+| End-to-end harness | [`034af226`](https://github.com/HTMLTrust/htmltrust-e2e/commit/034af22697f8b2a1c08b0c01200ca019995ca817) | Clean HTTPS simulation and CI |
+
+Native browser support remains a standards proposal. The current browser
+implementation is a Chromium extension.
 
 Current prototype repositories:
 
@@ -109,8 +124,10 @@ Current prototype repositories:
 | [htmltrust-e2e](https://github.com/HTMLTrust/htmltrust-e2e) | Combined system tests |
 | [htmltrust-website](https://github.com/HTMLTrust/htmltrust-website) | Project website and published draft copies |
 
-For a workspace-wide checkout and the combined run order, use the umbrella
-[developer guide](../README.md).
+To run the coordinated system, clone these repositories as siblings and start
+with the
+[end-to-end harness](https://github.com/HTMLTrust/htmltrust-e2e#readme). Its
+one-command workflow validates sibling paths and builds the required services.
 
 ## Contribute or report a problem
 
diff --git a/diagrams/architecture1.md b/diagrams/architecture1.md
deleted file mode 100644
index 4c7ed8a..0000000
--- a/diagrams/architecture1.md
+++ /dev/null
@@ -1,13 +0,0 @@
-flowchart TD
-    A[Author] -->|Manage Keys| B(Web Browser)
-    A[Author] -->|Author Content| C(CMS)
-    B -->|Obtain Public Key| C
-    C -->|Request Signature| B
-    C -->|Deliver| P(Pages with Signed Blocks)
-    P -->|Viewed| Br(Viewer's Web Browser)
-    P -->|Crawled| Cr(Crawler)
-    Br -->|Validate| Val(Validation Status)
-    Cr -->|Validate & Extract Articles| Researcher(Researcher)
-    C -->|Publish Keys & Hashes| Dir(Directories)
-    Br -->|Query for Bad Keys| Dir
-    Researcher -->|Mark Bad Keys| Dir
\ No newline at end of file
diff --git a/diagrams/architecture1.mmd b/diagrams/architecture1.mmd
new file mode 100644
index 0000000..dd4de95
--- /dev/null
+++ b/diagrams/architecture1.mmd
@@ -0,0 +1,9 @@
+flowchart TB
+    A[Author] -->|writes content| C[CMS signing integration]
+    K[Author private key] -->|signs region| C
+    C -->|publishes| P[Page with signed section]
+    C -->|publishes public key| D[HTTPS key endpoint or optional directory]
+    P -->|source snapshot| V[HTMLTrust verifier]
+    D -->|key and optional endorsements| V
+    V -->|interactive use| U[Browser indicator]
+    V -->|crawl-time use| I[Verified content record]
diff --git a/paper/ARXIV-SUBMISSION.md b/paper/ARXIV-SUBMISSION.md
index 99dd425..3f607b9 100644
--- a/paper/ARXIV-SUBMISSION.md
+++ b/paper/ARXIV-SUBMISSION.md
@@ -27,18 +27,18 @@ This command builds the PDF and writes
 
 Inspect the printed archive listing and the final PDF before upload. The
 supplementary Study 1 source and evidence remain in
-`paper/artifacts/study1-v03/`; the paper cites that stable repository snapshot.
+`paper/artifacts/study1-v04/`; the paper cites that stable repository snapshot.
 
 ## Plain-text abstract
 
-> We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The version 0.3 prototype includes five parser-backed language bindings, a reference directory, a browser verifier, and publishing integrations. All five bindings pass 118 shared canonicalization fixtures, including expected rejections. A separate Ed25519 vector fixes the signing input and signature; JavaScript and Go recompute and verify the full vector, while the remaining bindings exercise its canonicalization or payload stages. On 4,846 Common Crawl News body regions, the five independent ports produce matching digests for 119 of the 121 jointly canonicalizable inputs. Shared-core adapters agree on all 174 inputs they jointly canonicalize. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
+> We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The v1 prototype includes five parser-backed language bindings, a reference directory, a browser extension, and publishing integrations. All five bindings pass 123 shared canonicalization fixtures, including expected rejections. On 4,846 Common Crawl News body regions, all five ports accepted 121; 119 of those 121 produced identical digests. A selected 47-case adversarial evaluation matched every expected outcome. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
 
 ## Replacement comment
 
 Use this comment for a replacement submission and adjust the version number if
 needed:
 
-> Updated the protocol description to match signing profile v1 and canonicalization revision 12bc7e839d5e2a858c29bba651e704e8ed036d95. Added the final 4,846-region Common Crawl operational study, including separate independent-port and shared-core results, source-transformation probes, sampling limits, and a supplementary reproducibility archive. Narrowed claims about end-to-end vector coverage, replay scope, deployment evidence, and generalizability.
+> Updated the implementation evidence to canonicalization revision b0c8f305425de190a7f209ac117d34f88c2b1946 and expanded the conformance suite to 123 fixtures. Added selected adversarial cases, signing measurements, a Chromium lifecycle check, a local HTTPS integration simulation, and a Sybil policy-sensitivity model. Clarified the historical 31.4% result and the limits of the operational sample, benchmark, browser tests, and Sybil model. Replaced the supplementary archive with Study 1 v0.4.
 
 ## Final checks
 
diff --git a/paper/README.md b/paper/README.md
index e711a5d..2e3a41c 100644
--- a/paper/README.md
+++ b/paper/README.md
@@ -17,6 +17,10 @@ make paper
 The build runs `pdflatex`, `biber`, and two final `pdflatex` passes. It writes
 `paper/htmltrust.pdf`, which Git ignores.
 
+The architecture image is committed. Edit `diagrams/architecture1.mmd` and
+run `make paper-diagram` from the repository root to regenerate it. The root
+README lists the Mermaid CLI install command.
+
 If TeX Live is unavailable on the host, use Docker:
 
 ```sh
@@ -60,10 +64,16 @@ Check the page limit of any external review service before submitting. The
 paper length can change as the source changes. Completed external reviews live
 under `paper/reviews/` with their submission date.
 
+PaperReview.ai accepts PDF files up to 10 MiB and analyzes the first 15 pages.
+Before submitting, use `pdfinfo paper/htmltrust.pdf` to confirm the page count
+and `wc -c paper/htmltrust.pdf` to confirm the size. Save the private review
+token returned by the service because review email delivery can fail.
+
 ## Related documents
 
 - [Repository guide](../README.md)
 - [IETF protocol draft](../ietf-draft/README.md)
 - [W3C browser-integration draft](../w3c-cg/README.md)
-- [Study 1 v0.3 supplementary artifact](artifacts/study1-v03/README.md)
+- [Study 1 v0.4 supplementary artifact](artifacts/study1-v04/README.md)
+- [Historical Study 1 v0.3 artifact](artifacts/study1-v03/README.md)
 - [PaperReview.ai round-one review](reviews/paperreview-round1.md)
diff --git a/paper/artifacts/study1-v04/README.md b/paper/artifacts/study1-v04/README.md
new file mode 100644
index 0000000..10fd58c
--- /dev/null
+++ b/paper/artifacts/study1-v04/README.md
@@ -0,0 +1,38 @@
+# HTMLTrust Study 1 v0.4 supplementary artifact
+
+This directory archives the study source and compact evidence cited by the
+HTMLTrust paper.
+
+| Field | Value |
+|---|---|
+| Study commit | `2265eebdbc20cf16e59c1d8d4571d0235f9ebadf` |
+| Canonicalization commit | `b0c8f305425de190a7f209ac117d34f88c2b1946` |
+| Corpus records | 4,846 |
+| Corpus SHA-256 | `8c6831bece6f45f25622cf011ac1fcf45d1fcda36f14b8e111566317c12c7f92` |
+| Container image ID | `sha256:579515b828ef6930af9fc52b92c79ed9bc91520577682b11de1aa14214be09f1` |
+
+[`htmltrust-study1-2265eeb.tar.gz`](htmltrust-study1-2265eeb.tar.gz)
+contains the Docker harness, tests, corpus and run manifests, aggregate corpus
+results, adversarial fixture evidence, signing measurements, and the Sybil
+policy-sensitivity model. It excludes the 1.2 GB corpus, per-record run output,
+and source WARC files. The corpus manifest identifies each WARC by filename,
+size, and SHA-256 and records the selection parameters.
+
+Verify and extract the archive:
+
+```sh
+sha256sum -c SHA256SUMS
+tar xzf htmltrust-study1-2265eeb.tar.gz
+cd htmltrust-study1
+```
+
+Start with `results/v04/README.md`. It gives the current findings, evidence
+layout, checksum command, and exact Docker commands for each experiment. The
+top-level README explains how to rebuild the pinned image and run the study
+from a clean checkout.
+
+The historical v0.2 and v0.3 evidence remains inside the archive so readers
+can trace earlier measurements. Reproducing the Common Crawl experiment
+requires the external corpus named by the manifest. Package repositories can
+change over time, so retain the recorded image when exact runtime layers are
+required.
diff --git a/paper/artifacts/study1-v04/SHA256SUMS b/paper/artifacts/study1-v04/SHA256SUMS
new file mode 100644
index 0000000..3e6ccf3
--- /dev/null
+++ b/paper/artifacts/study1-v04/SHA256SUMS
@@ -0,0 +1 @@
+be013cd01f9fa5c1be4af5c9f2ff7485a52310851a7396fb4fb6a0551e1323d8  htmltrust-study1-2265eeb.tar.gz
diff --git a/paper/artifacts/study1-v04/htmltrust-study1-2265eeb.tar.gz b/paper/artifacts/study1-v04/htmltrust-study1-2265eeb.tar.gz
new file mode 100644
index 0000000..ba53344
Binary files /dev/null and b/paper/artifacts/study1-v04/htmltrust-study1-2265eeb.tar.gz differ
diff --git a/paper/htmltrust.tex b/paper/htmltrust.tex
index cab1900..c568e29 100644
--- a/paper/htmltrust.tex
+++ b/paper/htmltrust.tex
@@ -9,7 +9,7 @@
 \usepackage{xcolor}
 \usepackage{biblatex}
 \addbibresource{references.bib}
-\titleformat{\section}{\normalfont\Large\bfseries}{\thesection}{1em}{}
+\titleformat{\section}{\normalfont\Large\bfseries}{\makebox[2.25em][l]{\thesection}}{0pt}{}
 \titleformat{\subsection}{\normalfont\large\bfseries}{\thesubsection}{1em}{}
 
 \graphicspath{{images/}}
@@ -26,7 +26,7 @@
 \maketitle
 
 \begin{abstract}
-We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers \cite{HTMLTrustDraft}. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The version 0.3 prototype includes five parser-backed language bindings, a reference directory, a browser verifier, and publishing integrations. All five bindings pass 118 shared canonicalization fixtures, including expected rejections. A separate Ed25519 vector fixes the signing input and signature; JavaScript and Go recompute and verify the full vector, while the remaining bindings exercise its canonicalization or payload stages \cite{HTMLTrustCanon}. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
+We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers \cite{HTMLTrustDraft}. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The v1 prototype includes five parser-backed language bindings, a reference directory, a browser extension, and publishing integrations. All five bindings pass 123 shared canonicalization fixtures, including expected rejections. On 4{,}846 Common Crawl News body regions, all five ports accepted 121; 119 of those 121 produced identical digests. A selected 47-case adversarial evaluation matched every expected outcome \cite{HTMLTrustCanon,HTMLTrustStudy1}. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
 \end{abstract}
 
 \section{Introduction}
@@ -140,7 +140,7 @@ \subsection{Endorsements}
 \section{Browser and CMS Integration}
 
 \subsection{Browser Behavior}
-User agents perform verification in two distinct layers:
+The browser processing model has two distinct layers. The reference extension implements both:
 
 \begin{itemize}
   \item \textbf{Cryptographic verification}: The user agent obtains a source snapshot, refetching the current URL when the original response is unavailable. It canonicalizes the signed content and direct-child claims, checks the content and claims hashes and the mandatory \texttt{signed-at} value, resolves the \texttt{keyid}, and validates the signature. After the source snapshot is available, this processing is local except for any key-resolution fetch and produces a deterministic yes/no result.
@@ -152,18 +152,15 @@ \subsection{Browser Behavior}
 User interfaces SHOULD present the trust outcome as a graduated score or ranking and SHOULD distinguish the two layers visually. Cryptographic verification is a binary result; trust is a policy result with degrees of confidence. A score-based indicator with a detail view can expose the inputs that contributed to the result, the directories consulted, and the endorsements applied.
 
 \subsection{CMS Workflows}
-Content management systems generate:
-\begin{itemize}
-  \item Canonicalized content blocks.
-  \item Embedded signatures from author keys.
-  \item Optional submissions to trust directories.
-\end{itemize}
+Content management systems canonicalize the selected block and embed the
+author's signature. They may also submit records to configured trust
+directories.
 
 \section{Threat Model}
 
 The threat model includes an active rewriter who changes delivered HTML, a republisher who copies a section to another location, and an attacker who changes unsigned metadata around a signed section. A change to canonical text or a covered attribute changes the content hash. Cross-origin replay fails under both v1 location scopes. Replay at a different path or query on the same origin fails under \texttt{url} scope; \texttt{origin} scope permits that replay. Fragment-only changes are outside the signed URL location because fragments are excluded. The signing object binds the profile, algorithm, and \texttt{keyid}; a v1 verifier does not retry a failed artifact under legacy rules.
 
-The protocol has explicit residual risks. Signature stripping is detectable when a client or directory expects a signature at that location. Surrounding markup and uncovered attributes can change while the section remains valid. A compromised private key can produce valid forgeries until policy applies revocation or expiry. The \texttt{signed-at} claim records a time asserted by the signer; trusted time requires independent evidence, such as a timestamp token or trusted log record. Directory endorsements provide no Sybil-resistance guarantee. This paper evaluates protocol conformance and implementation behavior; user comprehension and Sybil resistance remain outside its evidence.
+The protocol has explicit residual risks. Signature stripping is detectable when a client or directory expects a signature at that location. Surrounding markup and uncovered attributes can change while the section remains valid. A compromised private key can produce valid forgeries until policy applies revocation or expiry. The \texttt{signed-at} claim records a time asserted by the signer; trusted time requires independent evidence, such as a timestamp token or trusted log record. Directory endorsements provide no Sybil-resistance guarantee. This paper evaluates protocol conformance and implementation behavior. It includes a policy-sensitivity model for Sybil attacks, but no empirical Sybil-resistance measurement or user-comprehension study.
 
 \section{Related Work}
 
@@ -182,18 +179,26 @@ \section{Related Work}
 \section{Implementation and Results}
 \label{sec:results}
 
-The design above is implemented in the HTMLTrust v1 prototype. The wire format is documented in an IETF-formatted Internet-Draft work in progress \cite{HTMLTrustDraft}; a companion proposed W3C Community Group report defines the element and browser processing model \cite{HTMLTrustW3C}. The system includes five language bindings, a reference federated trust-directory server with an OpenAPI description, a browser verifier, publishing integrations, and an end-to-end test harness. The canonicalization release is pinned to revision \nolinkurl{12bc7e839d5e2a858c29bba651e704e8ed036d95} \cite{HTMLTrustCanon}.
+The design above is implemented in the HTMLTrust v1 prototype. The wire format is documented in an IETF-formatted Internet-Draft work in progress \cite{HTMLTrustDraft}; a companion proposed W3C Community Group report defines the element and browser processing model \cite{HTMLTrustW3C}. The system includes five language bindings, a reference federated trust-directory server with an OpenAPI description, a browser verifier, publishing integrations, and an end-to-end test harness. The canonicalization release is pinned to revision \nolinkurl{b0c8f305425de190a7f209ac117d34f88c2b1946} \cite{HTMLTrustCanon}.
 
-\paragraph{Cross-implementation interoperability.} Because the security of the scheme depends on byte-identical canonicalization (\S\ref{sec:canon}), we measure interoperability across every language binding. A shared conformance suite of 118 fixtures, including expected rejections, is executed against every binding. The shared Ed25519 vector fixes a key, HTML fixture, canonical bytes, content and claims hashes, signing payload, and signature. JavaScript and Go tests recompute and verify the full vector; the remaining bindings validate the corresponding canonicalization or payload components. All five implementations produce the expected results across the canonicalization suite \cite{HTMLTrustCanon}.
+\paragraph{Cross-implementation interoperability.} Because the security of the scheme depends on byte-identical canonicalization (\S\ref{sec:canon}), we measure interoperability across every language binding. A shared conformance suite of 123 fixtures contains 24 normalization cases, 57 extraction cases, 17 claims cases, and 25 JCS cases, including expected rejections. The shared Ed25519 vector fixes a key, HTML fixture, canonical bytes, content and claims hashes, signing payload, and signature. JavaScript and Go tests recompute and verify the full vector; the remaining bindings validate the corresponding canonicalization or payload components. All five implementations produce the expected results across the suite \cite{HTMLTrustCanon}.
 
 \paragraph{Real-web operational sample.} We analyzed 4{,}846 HTML \texttt{<body>} regions from \texttt{text/html} 200 responses in the five WARC files listed by the run manifest, drawn from Common Crawl's news dataset \cite{CommonCrawlNews}. The deterministic selector retained URLs whose first 12 SHA-1 hexadecimal digits, interpreted as an integer, were congruent to zero modulo 17. It then required HTTPS and body sizes from 1 KiB through 1 MiB, with an 8 MiB response limit. The manifest records source-file hashes, skip counts, the corpus hash, container image identifier, toolchain versions, and the canonicalization revision \cite{HTMLTrustStudy1}. This operational sample has no probability-sampling interpretation. Its results should not be generalized to the Web, Common Crawl, or all news publishers. The pages predate HTMLTrust-specific authoring, so successful canonicalization measures strict-profile applicability to this sample and does not measure publisher adoption.
 
-\paragraph{Independent-port result.} All five independent language implementations returned success for 121 of 4{,}846 regions (2.5\% of the corpus). Among those 121 jointly canonicalizable regions, 119 produced the same SHA-256 digest, for 98.3\% conditional agreement and 2.5\% agreement over the full corpus. The implementations agreed on success-or-rejection status for 4{,}777 regions (98.6\%). Individual success rates ranged from 2.5\% to 3.6\%. The two jointly successful digest disagreements were localized to URL serialization. Among the Rust reference's 4{,}672 failures, 4{,}196 were classified as unsupported parser forms, 474 as HTTPS URL-policy violations, and two as attribute-canonicalization failures. Deployment tooling therefore needs to author or extract conforming regions and report preflight failures.
+\paragraph{Historical baseline.} A v0.2 study used a different 5{,}146-region corpus and a more permissive profile. All five ports produced identical bytes for 1{,}589 of the 5{,}067 regions they all accepted, or 31.4\% conditional agreement \cite{HTMLTrustStudy1Historical}. The v1 profile deliberately converts ambiguous source forms into rejections, so that historical percentage is not directly comparable with the strict v1 results below.
 
-\paragraph{Shared-core result.} We repeated E1 with each language adapter calling the same Rust canonicalization core. All adapters agreed on status for all 4{,}846 regions and produced matching digests for all 174 jointly canonicalizable regions. Successful coverage was 3.6\%. This shared-core control tests adapter fidelity and localizes the E1 differences to the independent-port paths. It does not distinguish parser, URL, or adapter causes individually and does not add an independent implementation of the canonicalization algorithm.
+\paragraph{Independent-port result.} All five independent language implementations returned success for 121 of 4{,}846 regions (2.5\% of the corpus). Among those 121 jointly canonicalizable regions, 119 produced the same SHA-256 digest, for 98.3\% conditional agreement and 2.5\% agreement over the full corpus. The implementations agreed on success-or-rejection status for 4{,}777 regions (98.6\%). Individual success rates ranged from 2.5\% to 3.6\%. The two jointly successful digest disagreements were localized to URL serialization. Among the Rust reference's 4{,}672 failures, 4{,}196 were classified as unsupported parser forms, 474 as HTTPS URL-policy violations, and two as attribute-canonicalization failures. Deployment tooling therefore needs to author or extract conforming regions and report preflight failures.
 
 \paragraph{Publishing transformations.} E2 applied source-level transformations to the 121 regions successfully canonicalized by the independent Python binding. Re-serialization through Python's \texttt{html.parser} preserved 121 of 121 hashes. Re-serialization through lxml caused all 121 transformed inputs to fail the v1 preflight. Inserting whitespace between tags preserved 89 of 121 hashes (73.6\%). These probes measure byte-level signature stability and do not establish that every transformation preserves rendered meaning.
 
+\paragraph{Selected adversarial cases.} A separate evaluation ran 47 normative parser, URL, Unicode, delimiter, signed-attribute, excluded-subtree, character-reference, and resource-ceiling fixtures through every independent port. All 47 produced the expected success or rejection result. For the 19 accepted cases, every port matched the normative digest and byte length \cite{HTMLTrustStudy1}. This selected fixture set tests known failure modes; it is not a security proof.
+
+\paragraph{Signing performance.} In one pinned Node.js process, synthetic signed sections from 1 KiB through 1 MiB were canonicalized, signed with Ed25519, and verified over 20 measured iterations after three warmups. Median total times were 0.640 ms, 1.364 ms, 8.540 ms, and 97.106 ms at 1 KiB, 10 KiB, 100 KiB, and 1 MiB. Median signature-verification time ranged from 0.066 ms to 0.082 ms. The signature was 64 bytes, and the generated signed-section envelope added 423 bytes at every size \cite{HTMLTrustStudy1}. The benchmark excludes process startup, browser work, network fetches, memory use, and user-perceived latency.
+
+\paragraph{Browser lifecycle and integration.} The reference Chromium extension verified a signed source snapshot, placed its indicator immediately after the signed section, changed the indicator after a post-load DOM mutation, and returned to the verified state after reload \cite{HTMLTrustBrowserReference}. A local HTTPS integration simulation with three authors, five consumers, eight articles, and 18 visits recorded 18 successful verifications and 18 source-to-rendered matches \cite{HTMLTrustE2E}. Its two synthetic metadata mismatches were reported with no false positives in the visited set. These tests establish prototype lifecycle behavior in one controlled Chromium environment. They do not measure content truth, production detection, user comprehension, or other browser engines.
+
+\paragraph{Sybil policy sensitivity.} An illustrative model starts with 20 honest endorsements across five configured directories. Raw endorsement counting gives an attacker a majority at 21 identities. With a cap of five endorsements per open directory, an attacker needs five controlled directories for a majority under the model's assumptions. A 3-of-5 configured-directory quorum fails after three configured directories are compromised \cite{HTMLTrustStudy1}. These thresholds are deterministic model outputs; they do not estimate attacker cost, directory prevalence, or empirical resistance.
+
 \paragraph{Normalization hazards surfaced.} Earlier implementation and conformance iterations exposed the following hazards; the current suite pins each with a fixture:
 \begin{itemize}
   \item \textbf{URL serialization.} Bindings diverged on host case, explicit default ports, dot-segment resolution, and internationalized-domain handling. V1 requires the WHATWG URL serializer, including punycode hosts, resolved dot segments, and preserved query and fragment.
@@ -204,17 +209,17 @@ \section{Implementation and Results}
 \end{itemize}
 Each case now has a dedicated conformance fixture.
 
-\paragraph{Limitations.} The portable v1 profile rejects source forms whose HTML5 tree construction cannot be established consistently across bindings. Whitespace inside \texttt{<pre>} is normalized under the general text rules, so verbatim code indentation is not byte-bound in this revision. Native \texttt{<signed-section>} support requires a multi-engine commitment from browser vendors. A crawl-time verifier could evaluate signed sections during search or answer-engine ingestion; this paper reports no deployment measurement.
+\paragraph{Limitations.} The portable v1 profile rejects source forms whose HTML5 tree construction cannot be established consistently across bindings. Whitespace inside \texttt{<pre>} is normalized under the general text rules, so verbatim code indentation is not byte-bound in this revision. The browser evaluation uses a local Chromium extension and synthetic pages; it does not measure native \texttt{<signed-section>} support, other engines, real sites, or real users. The timing study uses one process and synthetic content, and the Sybil analysis is a sensitivity model. A crawl-time verifier could evaluate signed sections during search or answer-engine ingestion; this paper reports no production deployment measurement.
 
 \section{Future Work}
 
-Concrete next steps, in rough priority: (1) deploy a crawl-time verifier at a search or AI-answer platform and measure false-positive and false-negative rates on a real content corpus; (2) define wrapper re-signing through a \texttt{claim:CanonicalURL} envelope that gives legitimate republication a verifiable attribution chain; (3) measure Sybil resistance in the endorsement and directory-reputation layer; (4) propose native \texttt{<signed-section>} support to the relevant browser-standards bodies; and (5) expand the signed-attribute set only after every implementation demonstrates byte-identical support for each addition.
+Concrete next steps, in rough priority: (1) deploy a crawl-time verifier at a search or AI-answer platform and measure false-positive and false-negative rates on real content; (2) run a user study of indicator comprehension and warning response; (3) define wrapper re-signing through a \texttt{claim:CanonicalURL} envelope that gives legitimate republication a verifiable attribution chain; (4) measure Sybil resistance in deployed endorsement and directory-reputation systems; (5) test the reference behavior in multiple browser engines; and (6) expand the signed-attribute set after every implementation demonstrates byte-identical support for each addition.
 
 \section{Conclusion}
 
-HTMLTrust v1 defines an in-band signature for semantic HTML regions. The signer binds canonical text, four semantic attributes, claims, a publication location, a key identifier, and a selected algorithm in a versioned signing object. The 118-fixture conformance suite and the Ed25519 vector at revision \nolinkurl{12bc7e839d5e2a858c29bba651e704e8ed036d95} provide reproducible implementation evidence \cite{HTMLTrustCanon}. The real-web operational sample shows 98.3\% conditional digest agreement among the 121 regions successfully canonicalized by all five independent ports. The shared-core adapters agree completely on the sample, while strict-profile success remains 3.6\%. These results make parser preflight, authoring support, and shared implementation code concrete deployment requirements.
+HTMLTrust v1 defines an in-band signature for semantic HTML regions. The signer binds canonical text, four semantic attributes, claims, a publication location, a key identifier, and a selected algorithm in a versioned signing object. The 123-fixture conformance suite and the Ed25519 vector at revision \nolinkurl{b0c8f305425de190a7f209ac117d34f88c2b1946} provide reproducible implementation evidence \cite{HTMLTrustCanon}. In the real-web operational sample, Rust accepted 174 of 4{,}846 regions (3.6\%), while all five independent ports jointly accepted 121 (2.5\%). Of those 121, 119 produced identical digests, for 98.3\% conditional agreement. These results make parser preflight and conforming authoring support concrete deployment requirements.
 
-Cryptographic validity covers the accepted source region and its selected location. Trust directories, endorsements, and client policy add optional social context. This paper presents protocol and implementation evidence; it reports no user study and no Sybil-resistance result.
+Cryptographic validity covers the accepted source region and its selected location. Trust directories, endorsements, and client policy add optional social context. This paper presents protocol and prototype evidence. It reports no user study, production deployment, or empirical Sybil-resistance result.
 
 \printbibliography
 
diff --git a/paper/images/architecture1.png b/paper/images/architecture1.png
index a5b18f5..ea17494 100644
Binary files a/paper/images/architecture1.png and b/paper/images/architecture1.png differ
diff --git a/paper/references.bib b/paper/references.bib
index 7b504c2..19ea751 100644
--- a/paper/references.bib
+++ b/paper/references.bib
@@ -238,10 +238,10 @@ @misc{TDMRep
 }
 
 @misc{HTMLTrustCanon,
-  title = {{HTMLTrust Canonicalization, version 0.3.0}},
+  title = {{HTMLTrust Canonicalization and Signing Profile v1}},
   author = {Grey, Jason},
   year = {2026},
-  note = {Commit \texttt{12bc7e83}, \url{https://github.com/HTMLTrust/htmltrust-canonicalization/commit/12bc7e839d5e2a858c29bba651e704e8ed036d95}}
+  note = {Revision \texttt{b0c8f305}, \url{https://github.com/HTMLTrust/htmltrust-canonicalization/tree/b0c8f305}}
 }
 
 @misc{HTMLTrustDraft,
@@ -261,11 +261,33 @@ @misc{HTMLTrustW3C
 }
 
 @misc{HTMLTrustStudy1,
-  title = {{HTMLTrust Study 1: Canonicalization on Real Web HTML}},
+  title = {{HTMLTrust Study 1 v0.4: Canonicalization, Signing, and Policy Evidence}},
   author = {Grey, Jason},
   year = {2026},
   howpublished = {Supplementary research artifact},
-  note = {Study commit \texttt{dcb2b451}; corpus SHA-256 \texttt{8c6831be}; container image \texttt{sha256:2cea8d3a}; \url{https://github.com/HTMLTrust/htmltrust-spec/tree/beabda866b24b0da3c0cd991f5779584b1d20115/paper/artifacts/study1-v03}}
+  note = {Study revision \texttt{2265eebd}; \url{https://github.com/HTMLTrust/htmltrust-spec/tree/main/paper/artifacts/study1-v04}}
+}
+
+@misc{HTMLTrustStudy1Historical,
+  title = {{HTMLTrust Study 1 v0.2: Historical Cross-Implementation Result}},
+  author = {Grey, Jason},
+  year = {2026},
+  howpublished = {Supplementary research artifact},
+  note = {Retained in study revision \texttt{2265eebd}; \url{https://github.com/HTMLTrust/htmltrust-spec/tree/main/paper/artifacts/study1-v04}}
+}
+
+@misc{HTMLTrustBrowserReference,
+  title = {{HTMLTrust Reference Browser Extension}},
+  author = {Grey, Jason},
+  year = {2026},
+  note = {Revision \texttt{5237f070}, \url{https://github.com/HTMLTrust/htmltrust-browser-reference/tree/5237f070}}
+}
+
+@misc{HTMLTrustE2E,
+  title = {{HTMLTrust End-to-End Integration Harness}},
+  author = {Grey, Jason},
+  year = {2026},
+  note = {Revision \texttt{034af226}, \url{https://github.com/HTMLTrust/htmltrust-e2e/tree/034af226}}
 }
 
 @misc{CommonCrawlNews,