> Published copy: URL matches at catalog, catalog-directory and folder level were removed from the published manifests after a check found them crossing sources (for example a Brazilian MANIFEST.json matched to a Quebec page). Only file-level URLs remain.

# NOTES: how the v5e provenance package was built

Built 15 October 2026 for the public site. No network request was made. Nothing outside this folder was changed. `E:\Backups` and `B:\Backups` were not touched. Every script is in this folder (`build_01` to `build_07`). Run order: 01, 02, 03, 04, 05, 06, 07. Each uses `python -I -X utf8`.

## What was done

1. **Code trace (`build_01`).** Entry points: 9109, 9521, 9522, 9523, 9505, 9514, 9998, 9799, 9999. Added by me: 9504 (weights stage), 9506 (shared results writer), 9710 (A5 battery), 9997 (A7 pins drafter), because the post-fit stage order names them. Also added: all 325 adapter scripts named in `INVENTORY_v5e.csv` `adapter_version`, and the 42 code files pinned in `RULE_9160_v5c_inputs.sha256`. Followed: static `import`, plus any non-docstring string constant that names a script in `07_analysis_code`. Local helper modules found through `sys.path.insert` were added from `processed/` and `qa/completeness_20260907/brazil_raw/`. Result: 475 scripts.
2. **Pins check (`build_01`, `build_05`).** All 14 code hashes in the A7 table and all 42 in the manifest equal the files on disk. All 149 files in `RULE_9160_v5c_inputs.sha256` re-hash equal. The four design frames, the design pins file, the fit-chain value in `design_pins_v5c.json` and the A7 table agree. Both pinned prefixes of `AMENDMENTS_9160.md` (A4: 93,448 bytes; manifest: 104,743 bytes) re-hash equal.
3. **Secret scan and zip (`build_02`).** 475 scripts scanned. 473 are in the zip (3.82 MB, scripts only, fixed timestamps, every member re-hashed equal to the manifest). 2 are excluded and listed in `code_bundle_exclusions.csv` with line numbers and no matched text.
4. **Sources (`build_03`).** One row per (part, raw file) from `parts/<source_id>/meta.json` `sources`. 609 parts (600 in `SOURCE_ROLES_v5e.csv` plus 9 part folders that are not in it). 28,865 rows. `sources_v5e_by_source.csv` (`build_06`) is the compact one-row-per-part version, because the file-level table is 26 MB.
5. **Events (`build_04`).** 881 events referenced by the primary-design stacks.
6. **Environment and pins (`build_05`).** Package versions are those of the interpreter that built this package.
7. **Layout (`build_07`).** `expected_layout_v5e.csv`, from the `sources` keys.

## Assumptions

1. **What "feeds the design" means.** The roles come from `SOURCE_ROLES_v5e.csv`. Primary and continuation parts feed the primary design. Sensitivity parts feed only the A6 maximal-inclusion supplement (listed in `MAX_INCL_PARTS.csv`). Descriptive parts feed no fit. I list all of them, plus the excluded parts (pending, superseded, not admitted) with the reason. `design_use` states which.
2. **`sources` in `meta.json` is not only raw input.** It also holds crosswalks, reference files used by the numeric checks, scripts, and earlier derived tables. I kept them all and added `file_kind` (raw, derived_table, factory_or_design_table, script, other_local_file). I did not drop anything. Of the 28,865 rows, 28,419 are `raw`.
3. **Continuation parts.** A part ending `_EXT`, `_EXT2` or `_EXT3` is merged into its stem source in `cells_primary_v5e.parquet`. `n_cells_primary` for a continuation counts rows of the stem source whose `src_file` is in the continuation's source list. For other parts it counts rows with that `source_id`. Sensitivity, descriptive, pending and superseded parts show 0 because their cells are not in `cells_primary_v5e.parquet`. `n_cells_part` is the inventory count.
4. **Which events table.** The fit used `work_v5c_v5e/a4_events/events_primary_v5e_a4.parquet` (factory events with the A3 corrections). Its event ids equal those of the factory `events_primary_v5e.parquet`, and the checked fields (date, first cohort, type, product, country) do not differ for any of the 881. I selected events by the `events` field of primary-design stacks (881). 404 of them are the lead events of the headline pool, equal to `headline.distinct_schedule_changes`. The headline pool has 39,753 stacks. The profile table has 39,757 stacks with status ok and a finite profile. I did not trace the 4-stack difference (the numbers file says the pool requires a finite dense-grid profile).
5. **Which cells.** The fit read the declared tables in `work_v5c_v5e/declared/` (9.58 million cells), not the factory file directly (12.13 million cells). The provenance columns (`src_file`, `src_sha256`, `adapter_version`) exist only in the factory file. I used the factory file for attribution. Both hashes are in `pins_v5e.json`.
6. **URL resolution order.** (1) the entry for exactly that file in a `MANIFEST.json`, `MANIFEST.csv`, `SOURCES.csv`, `*.sources.json` or other manifest-like JSON in the same folder or its parent; (2) a sidecar `<file>.meta.json` or `<file>.json`; (3) for derived Brazil aggregates, the upstream `.dbc` entry in the Brazil acquisition manifests; (4) a folder-level URL in a manifest; (5) a URL string in the adapter script whose last path segment equals the file name; (6) `source_catalog.csv` `official_url` matched by the file's name or folder in `local_archive`; (7) the single URL named in the part's `INVENTORY_v5e.csv` text. `url_level` records which one applied. Levels `dir_manifest`, `catalog`, `catalog_dir` and part-level are less specific than `file`. I did not search the web or follow redirects. I did not use `UNOBTAINABLE_SOURCES.csv` or `GPT_ROUND_DISPOSITIONS_AUDIT.csv` for file URLs: they are keyed by source or item, not by file. `UNOBTAINABLE_SOURCES.csv` is used in `REPRODUCE_v5e.md` for the sources that cannot be obtained.
7. **`publisher`** is the host of the URL (for a Wayback URL, the host of the archived address), for example `tea.texas.gov`. It is not a curated organisation name. Publisher fields inside manifests were not used.
8. **`access`** is filled only on evidence: Wayback snapshot (URL contains `web.archive.org`), API (the URL has an API endpoint pattern), or open download (the manifest carries an approval text saying open official data, no accounts, no logins, certificates verified). Everything else is `not recorded`. That is 25,749 of 28,865 rows. I did not infer "open" from a successful download alone.
9. **`retrieved`** is the manifest date or time of the entry (UTC where recorded). `not recorded` for 6,075 rows.
10. **Secret scan.** Hard hits exclude a file: e-mail address (TLD must be a real TLD, because `@` is also matrix multiplication), credential-like assignment (name contains key, token, secret, password, credential, bearer or auth; value is a quoted literal of 16 or more characters that is not a URL, a path, a hash pin, an environment lookup, a snake_case or dotted label, or a composite with `| { } ( ) [ ] % $ < >`), Bearer literals, known token formats, URL query secrets, the author's real name or handle, and "contact / maintainer / prepared by / author" followed by a personal name. Keyword-only mentions (`token`, `api_key`, `IPUMS`, `secret`, `password`, `key=` with no literal) are not excluded. They are listed in `code_bundle_scan_review.csv` (184 files, line numbers only). I made this choice because the bare words occur in unrelated code (for example tokenising text). No literal credential, personal name or private e-mail address was found in any file kept. A looser second check (any key-like name with an 8 or more character literal) over the kept files, run before the last rule change, found only two ordinary labels. The first draft of the scan flagged 29 files. I read each flagged line. All but two were false positives (data labels, matrix multiplication, the words "contact" and "written by"). I tightened the rules and re-ran. The two kept exclusions are conservative: `9202_download_usa_coverage.py` has a UUID literal named `ND_KEY` that its comment calls a public Power BI embed key; `9569_ita_pat_coverage_24m.py` mentions an institutional (publisher) e-mail address inside a string. Whether to publish those two is the owner's call. 17 of the 475 scripts contain a local absolute path (17 lines). They were kept as allowed.
11. **Code roles** are assigned by file name and by membership (adapter list, entry points). The categories are factory, adapter, driver, estimator, numbers, chart and test. The boundary between "driver" and "estimator" for the 9150 to 9160 modules is my judgement. The trace is static and over-approximates: it follows every string reference to a script, so it may include scripts that only run when a particular older part is rebuilt (for example the 3341 to 3385 injury negative-control scripts and `processed/` modules). It cannot find a script that is run only through a command line that is not in the code.
12. **Environment.** Worker count 14 (profile stage) is from the A4 addendum, the A7 pins and `FIT_LOG_v5c.json`. Cores (32) and RAM (125 GB) are recorded in the A4 addendum and a script docstring. The OS and Python version in `environment_v5e.json` are those of the interpreter that built this package.

## Fields I could not fill (written as "not recorded" or left to the notes)

1. Original URL: 5,341 of 28,865 rows (18.5%). Most are older US state files in `raw/us` (about 3,250 raw rows), `raw/vaccine_coverage` (814: CDC NIS public-use files), `raw/subnational_frontier` (402), plus smaller groups. 23,097 rows have a file-level URL. By source part, 602 parts have at least one file row; `url_share` per part is in `sources_v5e_by_source.csv`.
2. Access type for 25,749 rows; retrieval date for 6,075 rows.
3. `publisher` for rows without a URL.
4. Version of Python and of every package used by the fit itself. The fit log does not record them.
5. Random seeds (not extracted).
6. Full command lines of: the adapters, the factory merge (inferred from the 9109 command-line interface and `factory_v5e.log`), and the post-fit stages (stage order and script names only). The two fit commands (`9523 --final --tag v5e` and `9523 --fit --workers 14 --tag v5e --reuse-from work_v5c_v5d`) are in the A7 text.
7. `VALIDATION_v5e.json`, the numbers file and the whole `AMENDMENTS_9160.md` have no standalone pin in the amendments. I computed their hashes. `VALIDATION_v5e.json` is hashed in `RULE_9160_v5c_inputs.sha256`; the numbers file inputs are hashed in its own `input_sha256` block, and all 11 match.
8. The fit-chain hash is not recomputed here. It needs the project drivers to produce the declared fit configuration JSON. Its recorded value agrees across `design_pins_v5c.json` and the A7 table, and the per-file hashes it covers all match.
9. Extraction locators are summarised from `src_locator` templates (digits replaced by `#`, top 3 by row count). Sheet or page names are included only where the adapter wrote them into `src_locator`.
10. Checks: `checks_passed` / `checks_total` are the inventory counts. I did not re-run the checks.

## Things a reader should know

1. The record says the primary design has 41 countries and 95,462 stacks; the headline pool has 40 countries and 39,753 stacks, because the pool keeps only stacks with a successful profile. Both are correct for their stage.
2. `Brazil` rows are many: 17,564 file rows belong to `BRA_SIH_F84` and `BRA_SIH_CANCER`. Their listed file is the derived aggregate; the URL is of the upstream DATASUS `.dbc`.
3. One continuation part (`USA_CO_CDE_AU_EXT2`) shares 269 keys with its held part, with zero disagreements. The other continuations share none (A7 pins).
4. `sources_v5e.csv` is 26 MB. For the website use `sources_v5e_by_source.csv` (0.5 MB) and link the large file.