accessaudi Source — Dealer-Portal Feeds

accessaudi is the Audi US dealer portal, mirrored into BigQuery. Three raw assets read it, all through BQTableRawComponent with a service-account connection:

Asset	BigQuery source	Structure
raw/accessaudi_inventory	accessaudi.inventory_* (one table per dealer)	one row per dealer order, full order object in raw_blob
raw/accessaudi_models	accessaudi.product_models	one row per product model
raw/accessaudi_features	accessaudi.product_models	same table, read for options_blob

The portal writes irregular snapshots — zero or several collections a day — so every asset sets latest_snapshot: true, which takes the latest fetch_date on or before the partition date, per shard for the wildcard read. The reach is bounded by snapshot_lookback_days (30): a dealer shard whose extension has been uninstalled contributes its last snapshot for that long and then drops out, and the scan does not widen as the table ages. A downstream tier may still judge a shorter window stale.

What an accessaudi record states

A record states its model code, a model year, and a flat list of options as (option_code, label) pairs. It does not state a catalog id, a trimline, a model version, or PR extensions — those belong to the public carline feed. How the pipeline resolves that identity is on Model Identity.

accessaudi's year is the sales model year — the year the carline name and the VIN agree on — not the year inside a catalog id, which can run a year behind.

Order status between the factory and the lot

The portal states where an order sits between the factory and the dealer lot. inventoryStatusGroup names that status and lands on vehicle_order_status; inventoryStatus and inventorySubStatus are its numeric form (inventory_status, inventory_sub_status). orderType is the sales order type — SHIP, HELD, SOLD, LHLD, AVBL — and lands on sale_order_type.

OneGraph states the same statuses as display text, so its source module names them the portal's way as it parses, and both feeds reach the transformed tier on one vocabulary:

status_code	portal inventoryStatus	OneGraph orderStatusText
FACTORY	10, 15	— (the order has no VIN, so the public feed cannot list it)
IN_TRANSIT_FROM_FACTORY	20	Intransit From Factory
PORT	30	Port Stock
IN_TRANSIT_TO_DEALER	35	Intransit Inland
DEALER_STOCK	50	Dealer Stock

The two feeds' status sets are not identical. FACTORY is portal-only: the order has no VIN, so the public feed cannot list it. Center Stock is OneGraph-only and has no portal equivalent; the mapping's ELSE clause carries it through as CENTER_STOCK rather than nulling it, which is why status_code has six values and not five. Neither feed's orderType / sale_order_type vocabulary needs mapping — both spell it SHIP - Deliverable Inventory Order, and the portal's five values are a subset of the public feed's nine.

Which feed wins

The portal is the system of record for where a vehicle currently sits. On the vehicles both feeds saw, they agree once mapped in 91% of cases and disagree by one adjacent status in the rest — and in 82 of those 93 disagreements the portal is the further along one, the public feed lagging propagation. Source-group priority puts OneGraph first, so each adapter writes its mapped status to its own column — onegraph_status_code and accessaudi_status_code, matching the per-feed date columns beside them — and status_code is reconciled after the merge as COALESCE(accessaudi_status_code, onegraph_status_code). A single shared adapter name would collide in the merge and resolve by priority, taking whichever feed ranks first rather than the authoritative one. Both feeds' views stay on the row under those names.

Arrival date

A vehicle's arrival_date is the earliest partition any feed watched it reach DEALER_STOCK. Each source group carries its own min window aggregation over its history and arrival_date takes the LEAST of them, because the portal tracks a unit from the factory while the public locator lists it only once it is for sale — preferring either feed alone would read late.

A feed contributes its date only when its own first sighting of the vehicle predates that status. Where the feed's coverage opens on DEALER_STOCK, the date marks when the feed started carrying the vehicle, not when it landed. That guard matters most for the portal, whose window opens a median 29 days after the public feed's for the same VIN — 79% of the vehicles it ever shows at DEALER_STOCK are already there on its first sighting, against 21% on the public side. Without it roughly a third of arrival dates would be coverage artifacts, and days_on_lot would inherit them. LEAST ignores nulls, so a vehicle neither feed watched arrive keeps a null arrival_date, which days_to_lot/status_codes exists to impute.

filter_window_boundary (on by default under inventory) removes the same class of truncation at the 365-day window edge, but not a feed's mid-window coverage start, which is a property of the feed rather than of the window.

No feed states a retail date, so inferred_sold_date is the vehicle's disappearance from every feed that carried it, with a two-day grace for the portal export's lag. days_on_lot is the span between the two.

days_to_lot/status_codes learns the lag from status_code to arrival per (model_id, status_code). It keys observations on vin, so FACTORY orders contribute nothing — they have no VIN in any feed until they ship.

Known gaps

• product_models exposes no package containment (options_blob is flat and rules_blob carries only option constraints), so accessaudi features always have a null parent_package_code; package structure comes from the catalog source.
• Option pricing lives in a separate getAdditionalCharges endpoint the portal mirror does not capture, so feature price is unset and msrp on the option rows is always 0.
• The portal's commNum is a different identifier from the factory commission number (AB1234 vs 505214159) and maps to order_number; the canonical commission_number stays null for this source.