This page exposes the audit result, exact A–H fixture evidence and truthful operating boundaries. The interactive inventory is fictional demonstration data; automated persistence and delivery verification use isolated fictional dealer tenants and an owner-controlled destination, and make no customer or traction claim. RFQ persistence and external delivery through a signature-verified provider webhook are production-verified.
Demonstration import: 9 source rows · 8 published · 1 inactive private draft · original bytes and field provenance retained.
Classification meanings: PASS = implemented and verified; FAIL = present but broken; MISSING = absent; UNVERIFIED = present without sufficient evidence.
| Capability | Status | Verification evidence |
|---|---|---|
| Dealer-specific inventory ingestion | PASS | Authenticated dealer ownership is bound before preview or commit. |
| CSV import | PASS | Quoted fields, malformed rows, missing values and size limits are tested. |
| XLSX / Excel import | PASS | Only the bounded first worksheet is parsed; formulas are not executed. |
| Original vs normalized values | PASS | Original upload bytes and raw rows remain separate from reviewed normalized records. |
| Field-level provenance | PASS | Raw value, normalized value, source, confidence and verification state are stored per field. |
| Dealer ownership / tenant isolation | PASS | Every protected query and mutation is scoped by authenticated seller membership. |
| Active / inactive inventory | PASS | Draft, published, paused, sold and rejected states are distinct. |
| Natural-language extraction | PASS | Payload, reach, application and commercial context are extracted with explicit unknowns. |
| Missing critical requirements | PASS | Application, payload and reach gate ranking until complete. |
| Intelligent follow-up | PASS | Only materially missing hard-screening fields are requested. |
| Deterministic matching | PASS | Payload and reach failures remain authoritative regardless of AI output. |
| Four match states | PASS | MATCH, POSSIBLE MATCH, INSUFFICIENT INFO and INCOMPATIBLE are covered. |
| Qualified structured RFQ | PASS | Buyer, requirement, commercial context, shortlist, exclusions, unknowns and caveats persist. |
| Persisted lead | PASS | RFQs are committed to D1 with idempotent identifiers and audit events. |
| Dealer workspace persistence | PASS | The structured RFQ is stored in the correct tenant's private D1-backed dealer inbox. |
| External dealer email notification | PASS | A clearly synthetic owner-controlled RFQ was accepted by Resend; the real signed email.delivered webhook correlated the provider ID to the durable outbox and persisted delivered_at. |
| Dealer embed / widget | PASS | Dealer branding, inventory, attribution and exact-origin authorization are preserved. |
| Source attribution | PASS | Import-row, listing, landing surface, referrer and UTM fields are retained where available. |
| Pilot funnel analytics | PASS | The same production journey persists the complete session-to-RFQ funnel and exactly one dealer_lead.delivered created only by the signed delivery webhook. |
| AI provider abstraction | PASS | A provider-independent validated interface uses the OpenAI Responses API in production, with strict schema validation and deterministic fallback. |
| Graceful AI failure | PASS | Timeout, invalid output and provider failure return the deterministic safe result. |
| Security / authorization | PASS | Role checks, same-origin enforcement, validation, rate limits and safe failures are tested. |
| SEO foundations | PASS | Canonicals, schema controls, segmented sitemaps, index gates and facet controls remain in place. |
| AI-retrieval relationships | PASS | Dealer, listing, brand, model, application, location, controller, payload, reach, availability and update date are connected. |
Verified in the isolated server-side acceptance suite.
Verified in the isolated server-side acceptance suite.
Commercial demonstration boundary
The public demo supports natural-language intake, follow-up, deterministic matching, explainable selection and a dealer-facing RFQ preview without submitting the contact form. Requirement-text processing is disclosed in the pilot data notice. Real dealer RFQs persist in D1 and remain visible in the correct tenant workspace even when external notification fails.
Current AI boundary
The production OpenAI Responses API interprets buyer requirement text through a provider-independent adapter with strict structured output, evidence checks and bounded timeout. Provider failure activates a deterministic fallback. Matching never treats AI output as authority over technical constraints.