Tax Inventory & Report

Planned

The generic lot and publication-manifest contracts exist. The Korean tax inventory engine, report model, generator, and publication store do not.

Two different models

Provenance Lot Graph

The Provenance Lot Graph explains where a quantity came from and where it went. The implemented schema and storage contracts support immutable LotRun and LotAllocation records for:

• ACQUIRE — establishing a quantity and its known or unknown acquisition basis;
• DISPOSE — consuming one or more parent allocations and recording per-lot basis contribution; and
• CARRY — moving provenance only across a confirmed continuity relation.

Unknown acquisition cost remains basisStatus: UNKNOWN; it is never silently converted to zero.

This is a lineage model. It is not yet the Korean tax inventory calculation.

KR Tax Inventory

The target calculation scope is:

resident × tax_year × tax_asset_id

Within that scope:

• all owned exchange accounts, wallets, and other locations are pooled;
• account or wallet location remains provenance, not a separate tax inventory;
• confirmed self-transfers preserve basis and do not create an acquisition or disposal;
• annual total-average cost is applied to the pooled acquisitions and disposals; and
• a run is explicitly PROVISIONAL while required evidence or review remains open, and FINAL only after the declared closure conditions pass.

The current LotRun.scope contains only assetIds. It does not carry resident, taxYear, taxAssetId, or runMode. A typed TaxInventoryRun contract and calculation runtime are therefore required before a Korean tax result can be claimed.

ReportModel and Evidence Pack

The report stage must consume an immutable ledger revision and tax inventory run, not recompute hidden business logic in a template.

A planned ReportModel should include:

• reporting subject, resident scope, tax year, and policy version;
• income, acquisition, disposal, gain/loss, fee, and exception lines;
• source Event, Posting, Valuation, and tax-inventory identifiers for every figure;
• unresolved, unsupported, excluded, and provisional disclosures; and
• the revision relationship to any prior publication.

The schema already defines #EvidenceManifestData and #ValidatePublication. Those contracts can pin the evidence generation, coverage, closure, exact Event revisions, lot run, artifacts, and hashes used by a publication.

What is absent today is the ReportModel, its generator, rendered report/Evidence Pack artifacts, and a publication-specific persistence package such as publicationstore. Existing evidence, ledger, lot, and artifact stores do not by themselves implement report publication.

Required build sequence

Component	Current state	Completion evidence
Generic lot schema and persistence	Implemented	Validated LotRun/LotAllocation contracts and typed DB clients
Provenance lot calculation runtime	Planned	Allocation ancestry and self-transfer continuity fixtures
TaxInventoryRun contract	Planned	Typed resident/year/tax-asset/run-mode scope
Annual total-average engine	Planned	Pooled multi-account fixtures with provisional/final closure
ReportModel and generator	Planned	Every report line resolves to ledger and inventory identifiers
Evidence Pack renderer and publication store	Planned	Immutable artifact, manifest validation, current revision, and diff

Golden Path acceptance

The stage is complete only when a fixture spanning exchange and EVM evidence can:

1. preserve a self-transfer without gain or duplicated inventory;
2. value an external disposal with exact price and FX evidence;
3. calculate annual total-average cost across all owned locations;
4. remain provisional when evidence or review is open;
5. produce a report whose figures drill down to exact source coordinates; and
6. validate the unmodified manifest while rejecting a tampered artifact or stale revision.

The output supports review; it does not replace tax-professional judgment or claim filing accuracy.