Synthetic import-entry unit family: ledger-margin-generated trade entries, engine-runnable

Synthetic import-entry unit family

A new unit family alongside households: synthetic US import entries — (date, HTS-10 line, origin, customs value, mode/postal flag, weight) — generated from official trade margins and calibrated back to them, engine-runnable against the rulespec-us tariff composition.

Principle compliance (#530)

Populace should be solely based on the raw microdata, the ledger, and the rules engine — plus inflation/aging updates.

No public entry-level microdata exists for imports, so this family is built entirely from the ledger + engine legs: official Census/USITC series ingested as ledger facts, a generative step whose distributional assumptions are explicit and documented (never presented as records — synthetic labeling throughout), and calibration/validation against the same ledger facts. No processed third-party datasets.

Sources (ledger ingest, P1)

• Census import statistics: customs value by HTS-10 × country × month (USA Trade Online / Census API), plus district/mode splits where published.
• USITC DataWeb: calculated duties and dutiable value by line (validation leg).
• CBP published entry counts (entry-size distributions where available; otherwise the size distribution is an explicit assumption with sensitivity documented).

Schema + engine contract

Entries carry exactly the composed tariff spine's input surface (rulespec-us us:policies/cbp/us-tariff-duty/composition): dotted hts_number, country_of_origin (ISO-2 via the census bridge already maintained in axiom-oracles reference/us-tariff-panel/census_iso_bridge.csv — reuse, don't rebuild), customs_value, is_postal_shipment, entry date — so the file is directly consumable by dense engine runs (duty aggregates, de minimis exposure, refund-window analyses).

Calibration + validation

• Calibration targets: customs value margins by HTS chapter × country × month (dashboard rows, same loss-matrix treatment as household targets).
• Reality-leg validation (leads, never gates): engine-computed duties over the entries vs DataWeb calculated duties — collected differs from statutory through exclusions/drawback/compliance; divergence is signal, not error.

Phases

1. P1 — ledger ingest: the margin series above, admitted per ledger conventions with source manifests.
2. P2 — generator: entry synthesis + weights reproducing the P1 margins on a pilot window; assumptions doc.
3. P3 — calibration targets + dashboard rows; gates/holdout per repo conventions.
4. P4 — engine-run integration: dense duty computation over the file; DataWeb validation report.

Epic-scoped per standing populace ownership; PRs land per phase.

Start by reading the rulespec-us us:policies/cbp/us-tariff-duty/composition contract and the existing axiom-oracles/reference/us-tariff-panel/census_iso_bridge.csv bridge. Review the listed Census, USITC DataWeb, and CBP sources, then identify the appropriate phase and repository conventions for ledger manifests, calibration, and engine runs. Done means the selected phase has its documented inputs, assumptions, validation or gates, and synthetic labeling in place.