# PDFCarry proof pack: synthetic revision walkthrough

This folder is a self-contained evidence pack for the worked example "What still stands when the client sends version two". Open `index.html` in a browser for the designed walkthrough, or read `article.md` for the same content as plain text. Both are written from `results.json`, which is the factual authority for every count.

Generated 7 September 2026. Prepared by the PDFCarry product team at RYOX Sales Pty Ltd, with AI assistance: Claude (Fable) wrote and designed the walkthrough, article and this README; an OpenAI Codex agent (Astra) wrote the builder, ran the engine, verified the outputs and inspected the rendered pages at 390, 768 and 1280 pixels wide.

Presentation revised 8 September 2026 by Fable: `index.html`, `design/proof.css`, `article.md` and this README changed; see "Presentation revision" below. No PDF, JSON, preview, source or checksum file changed.

## What is in the pack

| Path | Contents |
|---|---|
| `index.html`, `design/proof.css` | Responsive walkthrough with print styling. Loads no external resources, sets no cookies, includes no analytics. |
| `article.md` | Plain-text version of the walkthrough for editors and reviewers. |
| `results.json` | Run summary for both cases: scope states, counts, events, heading roles, group warnings, validation results, per-item states, provenance and limits. |
| `guide-baseline.pdf`, `guide-revision.pdf`, `guide-output-for-review.pdf`, `guide-evidence.json` | Guide case: a fictional three-page tagged guide, its revision, the exported output and its evidence manifest. |
| `table-baseline.pdf`, `table-revision.pdf`, `table-output-for-review.pdf`, `table-evidence.json` | Table case: a one-page tagged table baseline, an untagged revision with a changed value, the exported output and its evidence manifest. |
| `previews/*.png` | One PNG per page of every PDF, rendered with pypdfium2 at 1.2 scale. Twelve files. |
| `SHA256SUMS.txt` | SHA-256 for every PDF and JSON file in the top level of this folder. |
| `source/build_acquisition_example.py` | A copy of the builder that produced this pack, for reading the method. See "Regenerating the pack" before running it. |
| `source/fixtures/word/table-old.pdf`, `source/fixtures/word/provenance.json` | The tagged Word fixture the table baseline was derived from, with its provenance record. |
| `source/fixtures/untagged-word/table-new.pdf`, `source/fixtures/untagged-word/provenance.json` | The untagged Word fixture used unchanged as the table revision, with its provenance record. |
| `source/bitstream-vera-license.txt` | Licence for the Bitstream Vera font embedded in the guide PDFs. |

## What the two cases show

**Guide case.** Baseline import: 19 items, 55 scopes, 0 review events. Automated setup recorded all 55 scopes (19 events). The revision changes one sentence, adds one paragraph, and tags every heading as P. After import: 58 scopes, of which 35 prior-reviewed, 17 reopened (all reading order, reason "A dependency changed between document versions.") and 6 with no carried review (the changed and new sentences). 20 items, 19 needing some review. Six heading roles restored (H1, H2 on each page). Events 19 before and after. Output renders identical to the revision on all three pages. Originals unchanged. Export purpose `further-review`. veraPDF 1.30.2 PDF/UA-1: passed, 106 rules, 2,663 checks.

**Table case.** Baseline import: 37 scopes, all recorded by automated setup (11 events). The revision is untagged and changes 100 to 900. After import: 40 scopes, of which 7 prior-reviewed, 3 reopened and 30 with no carried review. 13 items, 12 needing review. The Table group is refused: "Complete group text, boundaries or geometry could not be uniquely established." No Table context survives in the output; cells carry as loose items; 900 is preserved; pixels identical. Export purpose `further-review`. veraPDF PDF/UA-1: failed, 3 rules and 5 checks (missing PDF/UA identification, three Figure elements without alternative text, missing dc:title). These failures are not attributed entirely to the table change.

## Provenance

- Guide PDFs are original fictional content generated by the builder with ReportLab and pikepdf. Structure was authored directly: H1, H2 and P elements with a parent tree, artifacts for header, footer and page number, `en-GB` language, `dc:title` and `pdfuaid:part` 1. The revision variant tags every element P. Fonts: Bitstream Vera, as shipped with ReportLab.
- Table PDFs come from the repository's synthetic Word fixtures, copies of which are under `source/fixtures/`. The baseline is `table-old.pdf` from the tagged Word export set, with its header-row cells promoted to `TH` with column scope by the builder. The revision is `table-new.pdf` from the untagged export set, copied unchanged; its SHA-256 in `source/fixtures/untagged-word/provenance.json` matches `table-revision.pdf` in `SHA256SUMS.txt`. Both provenance records name Microsoft Word 16.0 as the producer of original synthetic DOCX content.
- No customer documents, names or data were used anywhere.
- All review events carry the reviewer label `SYNTHETIC fixture setup - not a professional reviewer` and an explanatory note. No human accessibility review occurred.

## Engine and environment

- Engine: the locally installed PDFCarry 0.2.2 Python engine (package `review_memory`) at source commit `f33848a222979fa97ff4ac92c30d8ab06e220ca4`, with the builder added to that tree for the run. The engine source under `src/review_memory` was compared against the frozen 0.2.2 runtime and the diff was empty. This was not a run of the frozen or signed installer. The application, frozen release and website were not changed. Application source remains private and is not part of this pack.
- Validator: veraPDF 1.30.2 (core, validation model and apps), provisioned privately as described in the repository README.
- Rendering: pypdfium2 for page hashes and previews. Pixel identity is asserted between each output and its incoming revision.
- Platform: the project's Windows development machine, not a fresh or clean-machine run. Astra can record the exact Windows build if that matters for a later archive.

## Presentation revision, 8 September 2026

Fable redesigned `index.html` and `design/proof.css` and revised `article.md` and this README, using the frontend-design skill and the project's anti-slop copy guidance. The page now opens with the page 2 comparison, a proportional bar of the 58 scope states and the item/scope key, then the disclosure, then the numbered walkthrough. The full item/scope ledgers, the refused-table case with its failed validation, the limits list and every download and checksum are unchanged in substance and still on the page. The page 2 previews at the top are shown cropped by CSS to their upper part; the PNG files are untouched and the full pages appear in the walkthrough. Guide links now use https://pdfcarry.com/guide, the canonical form; the earlier `/guide.html` form also resolves. The engine was not rerun, and every count still comes from `results.json`. Because `PACK-SHA256SUMS.txt` covers the presentation files, Astra regenerates it after accepting this revision; `SHA256SUMS.txt` covers only the unchanged PDFs and JSON and is still valid. Fable's design rationale, copy audit and browser checks at 390, 768 and 1280 pixels are recorded beside the refresh working copies, not in this pack.

## Regenerating the pack

From the repository root, with the development virtual environment, the package installed in editable mode, and the private validator provisioned:

```powershell
.venv/Scripts/python.exe tools/build_acquisition_example.py
```

The builder writes into `output/acquisition/pdfcarry-proof/`, creating the folder if needed. It asserts, for the guide case, that prior-reviewed, reopened and imported-baseline scopes all exist and that exactly six heading roles are present; for the table case, that a group warning was recorded, no Table context survives and the text `900` exists. It checks that both originals are byte-identical after the run and that each output's SHA-256 matches its manifest. Failing any assertion stops the build.

The copy under `source/` is for reading the method. It locates the repository root relative to its own path and imports the private engine, so it must be run from the repository's `tools/` folder inside the authorised project environment, not from this pack. There is no standalone engine bundle.

Re-running overwrites this folder. The JSON files contain project identifiers and timestamps, so `results.json`, both evidence manifests and `SHA256SUMS.txt` will change on every run. The PDFs are written with deterministic identifiers and are expected to be stable, but byte-for-byte reproduction across runs and machines is not promised. The hash tables in `index.html` and `article.md` were written by hand from the `SHA256SUMS.txt` in this archived copy. If the pack is regenerated, either keep this archived copy separate or update those tables to match, so the walkthrough and the files it describes never disagree.

## Limits, stated once

- Illustrative synthetic examples only. Nothing here is a customer result.
- Automated setup stands in for human review. Reviewer labels are local, unauthenticated strings.
- No durations were measured. No time saving or commercial performance is claimed.
- Two controlled producers, one three-page document and one one-page document. Coverage of real agency exports, larger documents and other producers is not established by this pack.
- A veraPDF pass covers machine-checkable PDF/UA-1 rules only. It is not accessibility certification or a substitute for the reviewer's own checks.
- The results date from 7 September 2026; publication notes were updated on 23 September 2026. The current Windows application offers a trial and paid subscriptions. This educational pack remains freely accessible and does not contain the application. The built-in sample in 0.2.3 uses explicitly labelled synthetic attestations; this historical pack retains its original automated setup records and hashes.

## Contact

support@pdfcarry.com