Canonical Domains
The operational domains of the dealership, each a stable resource and tool namespace that a conformant server implements.
4.1 Overview
The dealership is divided into canonical domains. Each domain is a stable namespace of resources (reads) and tools (actions), and every resource is dealership-scoped. A conformant server declares which domains it supports and implements the full required surface for each.
Within a domain, tools follow a predictable set, list, get, and, where the domain is
writable, create and update, so the surface is learnable and mirrors a conventional REST
resource (see Naming).
The eight domains below are the v0.1 set. Each domain's concrete object shapes are published as versioned JSON Schemas, read, validate against, or export them from Schemas, linked per domain below.
4.2 The domains
inventory, Inventory
New, used, and in-transit vehicles. Core resource: a vehicle with vin, condition, year,
make, model, trim, options, media, status, and price. Representative tools: inventory.search,
inventory.get.
Schemas: Vehicle · Inventory Snapshot · Appraisal
leads, Leads & CRM
The people and the opportunities. Two core resources:
- A customer (the person) with a
primary_contact, location, lifetime value, thelatest_leadandlatest_sale, and anyvehicle_of_interest. - A lead (an opportunity) with source, status, owner, and the vehicle in play.
Representative tools: leads.list, leads.get, leads.create, leads.update,
customers.list, customers.get. A customer resource generalizes to:
{
"id": "cus_4Qd9",
"type": "customer",
"dealership_id": "dlr_001",
"primary_contact": {
"name": "Dana Ruiz",
"email": "dana@example.com",
"phone": "+15125550143"
},
"location": { "city": "Austin", "region": "TX", "country": "US" },
"lifetime_value": { "amount": 4120000, "currency": "USD" },
"latest_lead": { "id": "led_88", "status": "working" },
"latest_sale": { "id": "sal_12", "closed_at": "2025-11-02T17:30:00Z" },
"vehicle_of_interest": { "make": "Toyota", "model": "RAV4" }
}Schemas: Lead · Customer · Activity / Task · Appointment
deals, Deals & Desking
Quotes, payments, trade valuations, incentives, and desking scenarios. Representative tools:
deals.create_quote, deals.request_trade_value, deals.apply_incentive.
Schemas: Deal
service, Service
Repair orders, appointments, technician time, and service history. Representative tools:
service.find_open_appointments, service.book_appointment, service.get_repair_order.
Schemas: Service Order
parts, Parts
Catalog, availability, pricing, supersessions, and ordering. Representative tools:
parts.search, parts.check_availability, parts.create_order.
Schemas: Part
fni, F&I
Finance and insurance products, lender programs, menus, and compliance artifacts. F&I tools carry heightened security and PII obligations (see Auth & Security).
Schemas: Credit Application
signals, Marketing & Analytics
Who a customer is to the marketing stack, and what they have done. Two parts:
- Audiences: named segments a customer belongs to. Tools:
signals.list_audiences,signals.get_audience,signals.list_audience_members,signals.list_customer_audiences. - Events: a time-ordered stream of engagement, sale, and service signals. Tools:
signals.list_events(scoped to a customer or dealership).
Event type is drawn from a controlled vocabulary so agents can reason across vendors. The v0.1
set generalizes the common automotive engagement signals:
| Group | Event types |
|---|---|
| Web | page_view, input_tracking, ad_click, conversion |
| Lead | lead, enrichment |
| Sale | sale |
email_sent, email_open, email_click | |
| SMS | sms_sent, sms_click, sms_replied |
| Service | service_lead, service_appointment, service_ro |
| Scheduling | appointment |
This domain is read-only; it exposes signals, not write actions.
Schemas: Campaign
consent, Consent & Compliance
Communication consent is a first-class resource in automotive retail, TCPA and privacy law make it load-bearing, not optional metadata. A consent record captures whether a contact has granted or revoked permission to be contacted, on what channel, and how that was established.
Representative tools: consent.list, consent.get, consent.create, consent.update. A consent
record generalizes to:
{
"id": "con_7f3a",
"type": "consent",
"dealership_id": "dlr_001",
"consent_status": "granted",
"channel": "sms",
"purpose": "marketing",
"source": "website_form",
"method": "double_opt_in",
"contact": { "phone": "+15125550143" },
"captured_at": "2026-01-14T15:04:00Z"
}consent_statusis one ofgranted,revoked,unknown.channelis one ofemail,sms,phone,mail.purposedistinguishesmarketingfromtransactionalconsent.contactcarries exactly one ofemailorphone, the identity the consent applies to.
Servers MUST treat consent as authoritative: an agent SHOULD check consent before initiating
contact through the leads or signals surfaces, and writes that would contact a customer MUST
respect a revoked status. Consent records are PII and fall under the
security profile.
Schemas: Consent Record
4.3 Domain support is declared
Because a real server may front only some systems, a server MUST advertise the domains it
implements and the conformance level per domain. An agent MUST NOT assume a
domain is present without checking. A CDP, for example, might implement leads, signals, and
consent at a high level while not exposing parts or deals at all.