1. Where the sale happened
A registered location is resolved once to Census boundaries and stored with provenance. A transaction that carrieslocation_id uses those identifiers. A transaction that carries only a ZIP code is resolved from the ZIP’s primary assignment, which is less precise and is recorded as such. See Jurisdiction resolution.
2. Which rules could reach it
Rules live at five levels. The engine builds a candidate chain from the most specific level to the least and evaluates each in turn.
A more specific rule that governs wins. A more specific rule that does not govern (wrong scope, not yet effective, not binding) falls through to the next level, and the engine records why.
3. Which rule governs today
A rule governs only when four things are true: its status is binding, the transaction type is inside its scope, its activation conditions are satisfied, and the sale’s local calendar date is on or after its effective date and before any sunset. Anything else falls through. See Rule activation.4. What the rule does to cash
The governing rule or tier names a method (symmetrical nearest five cents, round down only, or the operator’s choice), an obligation (obligates or permits), and any exclusions (California excludes totals of two cents or less). The engine applies the method to the cash total and never to the ledger total. See Rounding methods.
5. What proves it
The transaction is sealed into a SHA-256 hash chain with astatutory_basis block (the law, its citation, its status, the activation state, the tier, the local date, the dataset version) and, when a registered location was used, a location_resolution block (method, confidence, source, vintage, identifiers). See The audit record.

