Technical
Where the data comes from, and what each lane may claim
Two lanes, different provenance, different limits. One is machine-generated from a seed and was never observed anywhere; the other is a de-identified snapshot of a public listing source, and it describes listings rather than sales results.
- Sanitized listings
- 541
- Observed, then de-identified
- Governed workbooks
- 3
- Each declared with its SHA-256
- Pipeline stages
- 7
- Private input to governed view
Sanitized reference data over a synthetic warehouse.Granite Auto Group is fictional.Listings, not sales results.Real-engine validation pending.How this is governed
This is the one part of ARPI that is not fully synthetic
This feature uses a de-identified public inventory reference snapshot. Dealer and vehicle identities are synthetic. Listing attributes are not confidential DMS data and do not establish sales or inventory ownership.
- Sanitized public reference data
- Dealer and vehicle identifiers: synthetic
- Listing attributes: de-identified snapshot
- Source dealership: never named
The operational problem
What a dealership actually asks about its own website
None of those needs the DMS. All of them need a repeatable capture, a contract that refuses a malformed one, and a warehouse that will not let one capture be counted twice.
What is visible to a shopper right now, and how much of it shows a price?
What appeared since the last look, and what came off?
Which models and trims are we advertising, and at what spread?
How long has each unit been sitting on the site?
The source contract
What the sanitizer removes, and what it costs
The private workbook stays outside the repository, always. What is committed is the output of a transformation that is deliberately one-way: the result cannot be traced back to a source listing, which is the point, and therefore cannot be re-verified against one.
| Removed | Replaced with | How |
|---|---|---|
| Original VIN | A deterministic ARPI-prefixed synthetic VIN and vehicle identifier | SHA-256 over a group namespace. The same physical vehicle gets the same identity at every store and on every capture, so a cross-store appearance is detectable. No reverse mapping is produced and none could be built. |
| Row-level source URL | A neutral feed label | The label names the lane, never the origin. No URL appears on any sheet of a committed artifact, and CI fails if one does. |
| External dealer identity | A fictional Granite Auto Group store | Resolved from the ARPI dealership registry, never inferred from the file name. The source dealership is not named anywhere. |
| Street address | Nothing | Geography stops at store name and market region, which is the standing rule for every ARPI store. |
The boundary
A listing proves that something was advertised, and nothing else
The right-hand column is the more important one. Every item in it is enforced somewhere: in a view definition, in a column comment, in a CI check that fails the build if a document contradicts it.
What this data can establish
A vehicle listing was visible at this store in a public source on this capture date.
What the listing advertised: condition, model year, make, model, trim, odometer and price.
Whether the listing showed a price at all.
Which listings appeared, disappeared or changed price between two captures.
How long a vehicle has been visible online across the captures taken.
What it cannot, and must never be read as
That the vehicle was physically on the ground.
That the dealership owned it.
What it cost, what it sold for, or what it grossed.
That a listing which disappeared was sold. It can equally be a trade, a wholesale, a feed suppression or an error.
Days in stock. That runs from acquisition and lives in the DMS; this lane never sees it.
Current business performance of any kind.
Source to report
Seven steps, and the private file never enters any of them twice
Private workbook
Stays outside the repository, always. It is read once and never committed.
outside GitSanitizer
Validates the private input before transforming anything, replaces identifiers, removes URLs, resolves the store from the registry and writes a governed four-sheet workbook atomically.
scripts/sanitize_inventory_workbook.pyGoverned artifact
Four sheets, an explicit classification on every row, and the approved underscore-based file name. Declared in the contract with its digest.
data/reference/inventory/Validator
Fourteen workbook-answerable checks refuse a real VIN, a URL, a wrong classification, a duplicated grain, a broken pricing contract, an unknown store or a file name that disagrees with its own contents.
arpi validate-inventoryRaw and staging
Landed as untyped text with the file digest, then typed, domain-filtered, deduplicated and classified. Rejected rows keep a redacted payload and a REJ-* code.
raw.inventory_listing_snapshot_loadWarehouse
A separate observed-vehicle dimension and a listing snapshot fact, because this source proves observation rather than ownership. The grain is a UNIQUE constraint.
warehouse.fact_vehicle_listing_snapshotReporting and Excel
Six governed views, and a dealership-ready operating report built from the views rather than from the input workbook.
arpi export-inventory-report
The listing snapshot grain
One observed vehicle listing per dealership per captured_at value.
Declared once and enforced by the database, not by the importer’s good intentions.
Natural key
dealership_id + captured_at + synthetic_vehicle_idEnforcement
uq_fact_vehicle_listing_snapshot_grain, a UNIQUE constraint on the surrogate-key form of the same triple.
Immutability
The load inserts and never updates. A rerun of the same workbook writes nothing; a different workbook for a capture already loaded is refused rather than silently restating history.
Governed reporting
Six views, and one of them exists to stop a sentence being written
Twenty-two governed KPIs sit on these views, each with its grain, formula, null rule, additivity and interpretation caution recorded in the catalogue. None of them is a DAX measure yet: the current semantic model is awaiting real-engine validation, and adding measures before that validation would change what is being validated.
reporting.vw_vehicle_listing_currentThe latest observed listing for each store and vehicle, with the age of that observation on every row so a stale capture cannot read as a current one.
reporting.vw_vehicle_listing_summaryUnits, listed-price and call-for-price counts, advertised total and snapshot freshness by store and capture date.
reporting.vw_vehicle_listing_model_mixCondition, make, model and trim with unit counts and price statistics, and both mix denominators published as columns.
reporting.vw_vehicle_listing_price_completenessWhere the listing shows no price, by store, condition, make and model.
reporting.vw_vehicle_listing_observation_spanFirst observed, last observed, snapshots seen and days observed online, which is not days in stock.
reporting.vw_vehicle_listing_changeNew Listing, Still Listed, Removed From Listing, Price Increase, Price Reduction, Price Unchanged. There is no Sold label and there must never be one.
The deliverable
An Excel report a dealership can actually open
Built from the reporting views over PostgreSQL, never from the input workbook. A report assembled from its own source would prove nothing about the load. Formula-driven where a user will filter, values where two captures are being compared.
arpi export-inventory-report --dealership-id GSA-001 --captured-at 2026-08-02artifacts/inventory/ARPI_Granite_Chevrolet_Inventory_Report_2026-08-02.xlsxWhat the workbook contains
README: provenance, and a question-and-answer table of what the report can and cannot establish
Summary: formula-driven metrics beside the warehouse's own figures, with condition and top-model charts
Inventory: the listing detail, as a filterable Excel table with frozen headers
Model Summary: formula-driven price statistics per condition, make and model
Snapshot Changes: present only when a prior capture exists to compare against
The committed artifacts
Three stores, one capture date, 541 listing rows
Every figure below is a count of what the files contain. None of them is a finding, a performance figure, or a statement about any real dealership. Where a capture could be misread, the reason is stated on the card rather than left for someone to discover.
Granite Chevrolet of Nashua
GSA-001Reference rows
Used-condition rows
195 new
Rows showing a price
2 showing none
Rows with no mileage
Granite Subaru of Manchester
GSA-002Reference rows
Used-condition rows
8 new
Rows showing a price
Rows with no mileage
Partial capture. 24 visible indexed listing records from a larger reported inventory. The source did not expose every listing through a reliably extractable path, so this row count is a count of what was visible to the capture and not of the store's inventory.
Granite Pre-Owned Center of Merrimack
GSA-003Reference rows
Used-condition rows
0 new
Rows showing a price
287 showing none
Rows with no mileage
Not rows with zero miles
287 listings published no price field and no mileage. That is a property of the listing surface, not a merchandising choice and not a defect, so it is counted separately from call-for-price. No price statistic and no average mileage can be computed for those rows, and the lane reports them as a count rather than as a zero.
Each name, such as ARPI_Granite_Chevrolet_Inventory_Sanitized_2026-08-02.xlsx, intentionally uses underscores between filename words and hyphens only inside the ISO date. Each is declared in the workbook contract with its SHA-256, each lives under its own store’s directory, and no duplicate or alias copy of any of them exists anywhere in the repository.
Multi-store
The second and third stores arrived, and nothing needed rewriting
The dealership is resolved from the workbook's own metadata against the ARPI registry, never inferred from a file name.
GSA-002 and GSA-003 loaded with no Chevrolet-specific change, and their Subaru, Jeep and thirty other makes were accepted because nothing in the lane knows what a franchise brand is.
A franchise store's used inventory of other makes is accepted, which is what the committed Chevrolet artifact already contains.
What did have to change was the contract, not the code: one store publishes no mileage and no price for most of its listings, so the odometer column became optional and 'Price not exposed' was added as a status distinct from call-for-price.
That is the intended shape of a contract change. It is one reviewed edit to a versioned YAML file that five consumers read, rather than a new branch in five modules.
Vehicle identity is group-stable, so the same physical vehicle observed at two stores resolves to one identity and the appearance is detectable.
Detectable is not explained: ARPI holds no dealer-trade event and does not infer one.
Implementation status
What is finished, and what is deliberately not
- Complete
Sanitizer, validator, importer and exporter
Implemented, tested and exercised against the committed artifact.
- Complete
Warehouse objects and reporting views
Built, constrained and covered by the PostgreSQL integration suite.
- Complete
Governed listing KPIs
Twenty-two definitions in the KPI catalogue, each with its grain, formula, null rule, additivity and interpretation caution.
- Pending external validation
Second store
The code accepts a Granite Subaru workbook today. No Subaru artifact is generated in advance, and no placeholder exists.
- Pending external validation
Semantic model extension
Deliberately not started. The current model is awaiting real-engine validation, and adding tables before that validation would change what is being validated.
- Pending external validation
Repeat-capture analysis
The change and observation-span views are built and queryable, and a single capture cannot exercise them. A second capture of the same store is what turns them on.
Public-reference governance
The exception is narrow, explicit, and checked by a machine
ARPI’s standing policy is that every row is machine generated. This lane is the only exception, and it exists on these terms.
Public listing data is used only where it was publicly accessible. No authentication bypass, no scraping circumvention, no restricted data.
No customer or employee data, and no confidential DMS, CRM, F&I, service, lender or transaction data, in any form.
Sanitized reference data lives outside data/sample, which stays synthetic-only. CI fails if a workbook appears there.
The artifact carries an explicit classification and cannot be presented as fully synthetic.
A removal request is honoured by deleting the artifact and its loaded rows. There is no review period.
The canonical file name uses underscores, is declared with its digest, and cannot be renamed without an explicit migration.