# Data and Asset Provenance

This record separates four questions that must not be conflated:

1. which exact bytes are in the workspace and publish artifact;
2. whether those bytes represent the intended provider or dataset;
3. where the bytes came from and how they were transformed; and
4. whether Zynor has adequate rights to redistribute them.

A checksum answers only the first question. An Engineer identity decision
answers only the second. Neither establishes copyright ownership, a license,
or redistribution permission. Unknowns below remain release blockers rather
than being filled from resemblance to a public repository.

The machine-readable records are `config/data-provenance.json` and
`config/logo-provenance.json` in the source repository. Run
`npm run provenance:check` after any dataset or logo change. The checkers
validate current bytes, counts, dimensions, media types, relationships, and
approved identity hashes; they do not declare unresolved rights to be clear.

## Dataset inventory

| Dataset surface | Current integrity and relationship | Runtime role | Provenance and redistribution state |
| --- | --- | --- | --- |
| `src/email/disposable.ts` | Source SHA-256 `33f375b8b0b4dd202b417c8be735103ca9c8ff51226609fb53454dd441ef1cba`; embedded payload is 1,093,459 bytes and 71,554 entries | Canonical runtime disposable-domain payload | Upstream snapshot, version, license, attribution, capture date, and refresh policy unresolved |
| `src/disposable/4.txt` and `5.txt` | Byte-identical to each other and to the runtime payload; SHA-256 `4a6f507b593d76491a03facbeef00f9c230c8552fd13aae776ac8b77067aebda` | Workspace mirrors; no runtime import found | Same unresolved origin/rights as the runtime payload |
| `src/disposable/1.txt` | 61,102 bytes, 4,724 entries, SHA-256 `8d4ce87d236daa3fd40b3351c364163b4650b6f64821c2e8aed68650c5124525`; exact prefix/subset of the runtime payload | Legacy workspace subset; not additive to the 71,554 count and no runtime import found | Origin, purpose, license, and refresh policy unresolved |
| `src/disposable/2.json` | 61,931 bytes, SHA-256 `8fe8af713e8a3b5a295eac879433e5248417e310c7042a7cfafce0cada3d0405`; 67 root records, 2,324 unique hosts, and 2,333 unique root-key/host values combined | Legacy workspace metadata; no runtime import found | Exact upstream snapshot and license unresolved |
| `src/email/freeProviders.ts` | 4,835 unique entries, source SHA-256 `b99ebe7f484821a74d8a1d44dc48948541264553258bb672e0130016d5b37c94` | Canonical runtime known-free-domain payload | Upstream snapshot, version, license, attribution, capture date, and refresh policy unresolved |

The text files intentionally have no final newline. Unix `wc -l` therefore
reports newline separators — 71,553 for `4.txt`/`5.txt` and 4,723 for
`1.txt` — while the logical non-empty entry counts are 71,554 and 4,724.
`src/disposable/t.ts` is a Bun workspace utility. When invoked as `bun t.ts`
with `src/disposable` as its working directory, it merges `1.txt` and `4.txt`,
de-duplicates, lowercases, and writes process-relative `./5.txt` (the repository
file `src/disposable/5.txt`). Because `1.txt` is already a subset of `4.txt`,
the current generated `5.txt` is byte-identical to `4.txt`. Running that utility
from another directory would target a different path and is not the recorded
procedure.

Relationship checks are part of the integrity gate: the combined JSON root-
key/host set overlaps the free-domain payload by 1,962 values, with 371 JSON-
only and 2,873 free-only values. Only 62 of the 67 JSON root keys are FQDN-
shaped, so the combined set is not mislabeled as a domain list. The disposable
and free payloads overlap by 756 domains. Those overlaps are facts about the
current bytes, not evidence that one file was derived from another. The
runtime disposable corpus is 71,554 entries; adding the 4,724-entry subset
would double-count it.

Searches found public datasets with partial or close overlap, but no exact
snapshot relationship was proven. They are therefore not named here as
sources. Before release, the Engineer must either establish a documented
origin and redistribution basis for each runtime dataset, replace it with a
rights-cleared reproducible source, or remove the affected functionality by a
separately reviewed product decision.

### Runtime boundary and checker limits

The canonical bundle embeds the reviewed runtime payload and does not stage
`src/disposable/` into the published package. The data-provenance gate checks
that artifact boundary independently from its source inspection. In source,
the excluded workspace generator is the only file allowed to reference the
raw directory directly. Three operational files that legitimately load other
runtime-selected paths are fenced by whole-source SHA-256 plus exact reviewed
loader-call counts.

The source guard blocks the hazardous loader and execution channels enumerated
in `config/data-provenance.json` for the currently supported Node.js, Bun,
Deno, and web profiles. It also requires dynamic import targets to be inline
literals and performs bounded static-path normalization as defense in depth.
This is not a JavaScript sandbox, arbitrary-computation or dependency-taint
analysis, or automatic protection from an unknown future runtime API. Adding a
runtime capability requires an explicit threat-model and manifest review; do
not mechanically refresh source hashes or extend the channel list merely to
make the gate green.

## Logo inventory and identity decisions

The workspace currently contains 174 `.png`/`.jpg` provider assets, each
statically imported exactly once. The logo manifest pins every file's hash,
byte length, media type, and dimensions. Assets without individual research
remain `unreviewed` for identity and `unresolved` for redistribution even
though their current bytes are pinned.

Four current identity decisions have stronger evidence:

| Provider/file | Approved identity bytes | Source/transformation record | Redistribution status |
| --- | --- | --- | --- |
| Proton Mail, `src/logos/protonmail.png` | 128×128 indexed-colour PNG, SHA-256 `837f379456d25d5481a67bf59056ddef6c941149c1f8dc2bf627a7a72fe4a8ac` | Original repository asset retained by Engineer identity decision; existing result links to `mail.proton.me` | Upstream source asset and permission chain are not established; no project-wide legal clearance is inferred from identity approval |
| Riseup, `src/logos/riseup.png` | 256×256 RGBA PNG, SHA-256 `35a6204cfc4e0ebea799dd5baa595323180cf89b51956917fdb9c808a6345b9b` | Mechanical extraction/raster of the icon group from Riseup's first-party reusable SVG; recorded source SHA-256 `0b36221391b946a8a1b98b516eed1d93271d4a4a11250c42408e5ac472c58a23` | First-party reuse invitation is recorded; no project-wide legal clearance is inferred from identity approval |
| Ziggo, `src/logos/ziggo.png` | 256×256 RGBA PNG, SHA-256 `697642b36a4704ad18bdd178b9d3905297871ff58f81147a528942cb6ac98fde` | Engineer-directed smooth identity-locked reconstruction from first-party 32×32/48×48 Ziggo rocket favicons; not first-party output bytes | Identity approved; redistribution basis for the reconstruction remains unresolved |
| Tuta, `src/logos/tutanota.jpg` | Original 200×200 JPEG, SHA-256 `5abe3988658d3db06169c1da02ccf8336a60dd450d88a2f64fe2d72cf5c0d265` | Engineer selected the repository's original provider-specific artwork | Identity approved; exact source and redistribution chain remain unresolved |

Identity review currently does not cover the other 170 assets. Seven exact
duplicate pairs require individual provider research rather than assuming one
brand may stand in for another:

- `blueyonder.png` / `ntl-world.png`;
- `chello.png` / `home-nl.png`;
- `cox-webmail.png` / `cox.png`;
- `hetnet.png` / `planet-nl.png`;
- `neuf.png` / `sfr.png`;
- `outlook.jpg` / `owa.jpg`;
- `yahoo-external-provider.png` / `yahoo.png`.

Some duplicates may ultimately be legitimate shared branding. Byte equality
alone is not that proof. In particular, current first-party service evidence
associates Chello and Home.nl domains with Ziggo operations but does not prove
that the frozen historical provider identities may use the current Ziggo
rocket.

## Change and review procedure

For each dataset or logo addition/replacement:

1. claim the exact files before editing and preserve frozen public provider
   names;
2. prefer a first-party source, record the exact URL/member, capture date,
   source dimensions/format/hash, and every mechanical transformation;
3. record license or permission text precisely, or leave redistribution
   `unresolved`; never infer rights from public availability;
4. visually verify that logos are provider-specific, sharp, nonblank,
   unclipped, and not fabricated or generic;
5. update the machine-readable manifest deliberately and run
   `npm run provenance:check`, the logo/provider fixtures, canonical build,
   and package checks;
6. request independent review of identity, integrity, transformation, and
   rights claims before accepting the change.

Dependency license texts are handled separately in
[`THIRD_PARTY_NOTICES.md`](../THIRD_PARTY_NOTICES.md). Data flow, egress,
retention, and operator responsibilities are documented in
[`DATA_PROCESSING.md`](../DATA_PROCESSING.md). Neither document overrides the
project license or third-party rights.