Documentation

Specification

The complete LEX standard reference — covering message structure, field definitions, extensions, conformance, and all supporting specifications.

v1.0 Draft Apache 2.0 April 2026

Core Standard

LEX Core Specification

Core standard — message structure, versioning, transport, governance, anti-capture clause, simplicity budget. The primary reference document.

Message Types

LEX defines five primary message types. Each has a specific purpose, direction, and response expectation.

Message Type	Direction	Purpose
`LEAD`	Bidirectional	Create, update, and query lead information across the ecosystem
`ASSET`	Outbound	Vehicle / product inventory updates pushed to downstream systems
`ACKNOWLEDGMENT`	Response	Receipt confirmation, validation result, and error reporting
`SUBSCRIPTION`	Bidirectional	Subscribe or unsubscribe to lead event streams and notifications
`LEAD_CLOSURE`	Bidirectional	Record deal outcome — won, lost, duplicate, or abandoned with reason codes

Full message types reference ↑

Field Dictionary

Every field in the LEX schema — type, constraints, required/optional, and examples.

# Selected key fields (see full reference for all fields)

lex.header.messageId UUID v4 Required — unique per message

lex.header.messageType Enum Required — LEAD | ASSET | ACK …

lex.header.timestamp ISO 8601 Required — within ±60s

lead.customer.email string Required — RFC 5322 validated

lead.customer.phone string Optional — E.164 format

lead.status Enum Required — 15 valid values

lead.desiredProduct.assetClass Enum Optional — VEHICLE | AVIATION …

Full field dictionary ↑

Product Model

LEX uses a product-agnostic model. The desiredProduct block accepts any asset class using a universal structure, with optional industry-specific spec blocks.

Product Model

Product-agnostic model covering 50+ product types across all industry verticals, fleet/multi-unit orders, and B2B procurement structures.

Extension Standard

LEX is designed to be extended without breaking core compatibility. Extensions use namespaced fields added to the extensions object.

{
  "lex": { /* standard fields */ },
  "extensions": {
    "toyota.fleet.costCentre": "FLEET-NE-42",
    "cdk.crm.opportunityId": "OPP-987654",
    "acme.insurance.bundleRef": "INS-2026-XYZ"
  }
}

Extension Standard Extension Registry ↗

Supporting Specifications

Multi-Industry Extensions

Industry-specific extensions for heavy equipment, aviation, maritime, real estate, and technology

EV Extensions

Electric vehicle spec block — battery, range, charging standard, and subscription data

Organisation Extensions

Organisation context — fleet buyers, government procurement, NGOs

Data Governance

Data retention, jurisdiction, and PII handling policies

Deduplication

Customer fingerprinting and duplicate detection across systems

Financial Summary

Deal financials — pricing, incentives, taxes, and net deal value

Captive Finance

OEM captive financing, lease structures, and balloon payment terms

Lead Closure

Deal outcome recording — won, lost, duplicate, merged with reason codes

Deal Lineage

Full audit trail — lead ancestry, conversion path, and attribution chain

Transport Resilience

Retry context, dead-letter queue headers, and idempotency guarantees

Lead Intelligence

Behavioural signals, intent scores, and predictive lead attributes

OpenAPI 3.1 — REST API

Machine-readable REST endpoint definitions — import directly into Swagger UI, Postman, or any OpenAPI-compatible toolchain

AsyncAPI 3.0 — Event-Driven

Channel and message definitions for Kafka, AMQP, WebSocket, and webhook transports — includes CloudEvents alignment