Neuro-Symbolic Conversational Vehicle Advisor: Deterministic Constraint Solving, State Integrity, and Multi-Stage Recommendation A developer built Vehicle Advisor, a production conversational automotive discovery and financing platform on NestJS, TypeScript, and PostgreSQL that uses a hybrid neuro-symbolic architecture to keep LLM reasoning separate from business truth. The system confines non-deterministic language understanding to slot extraction, intent classification, and response synthesis, while inventory validation, constraint satisfaction, candidate scoring, and ranking run in deterministic, auditable stages, backed by an evaluation harness that checks invariant safety, slot extraction recall, and zero-drift persistence across multi-turn multilingual conversations. Most conversational AI implementations in industry rely on naive Retrieval-Augmented Generation RAG or unconstrained agentic loops. While adequate for open-ended queries or low-stakes search, pure probabilistic Large Language Model LLM architectures fail catastrophically in high-consideration automotive e-commerce. In automotive discovery, hallucinating non-existent inventory, violating strict budget ceilings, misinterpreting physical vehicle capabilities, or dropping conversational constraints across multi-turn sessions directly destroys transactional trust and violates financial compliance boundaries. This paper details the architecture, mathematical formulations, and engineering principles behind Vehicle Advisor—a production conversational discovery, recommendation, comparison, and financing decision-support platform engineered on NestJS, TypeScript, and PostgreSQL. By implementing a hybrid neuro-symbolic architecture, the system isolates non-deterministic natural language understanding NLU to slot extraction, intent classification, and conversational synthesis, while delegating inventory validation, constraint satisfaction, candidate scoring, and business ranking to deterministic, auditable software stages. Furthermore, this paper presents an evaluation harness evals that continuously verifies invariant safety, slot extraction recall, and zero-drift persistence across multi-turn multilingual conversational trajectories. Automotive transactions are governed by an asymmetric balance of hard constraints strict maximum purchase price, verified seating capacity, location proximity, financing eligibility and soft preferences fuel efficiency, cargo practicality, ground clearance, brand affinity . When deploying conversational agents in automotive marketplaces, four systemic failure modes arise in pure LLM architectures: 1. Inventory Hallucination & Phantom Listings: Autoregressive models generate plausible-sounding vehicles e.g., a "2021 Toyota RAV4 for ₦8,500,000" that do not exist in live inventory or have stale pricing. 2. Constraint Amnesia & Parameter Drift: Over a 4- to 8-turn negotiation, stochastic context windows experience catastrophic forgetting, dropping prior hard filters such as budget ceilings or 7-seater requirements . 3. Zero Automotive Knowledge Translation: First-time buyers express needs in human lifestyle terms "I have 3 toddlers and need to navigate flooded streets during the rainy season in Lekki" . Standard keyword search fails, while naive LLMs invent unverified vehicle specifications e.g., claiming a sedan has high ground clearance . 4. Uncontrolled Business & Financing Policies: Commercial prioritisation dealer tiers, inspection grades and regulatory financing boundaries must never secretly override customer hard constraints or imply credit approval without underwriting. To resolve these failure modes, we established a strict architectural boundary: The LLM never defines business truth, inventory state, or ranking outcomes. The system is architected as a Clean Architecture, Domain-Driven Design DDD backend built on NestJS and Fastify, decoupled from specific LLM providers through abstract orchestration adapters supporting Google Gemini and OpenAI . 3.1 Pillar 1: Conversation State & Attribute Provenance Conversation state belongs exclusively to the application database, never to the ephemeral context window of an LLM. In this architecture, user requirements are modelled via a strongly typed BuyerProfile aggregate containing granular attributes with explicit provenance and preference types: // conversation.model.ts Excerpt export enum AttributeCategory { BUDGET = 'BUDGET', BODY TYPE = 'BODY TYPE', SEATING = 'SEATING', MAKE = 'MAKE', USAGE = 'USAGE', LOCATION = 'LOCATION', FEATURE = 'FEATURE', FINANCING = 'FINANCING', } export enum PreferenceType { HARD CONSTRAINT = 'HARD CONSTRAINT', // Absolute invariant; zero violation tolerance SOFT PREFERENCE = 'SOFT PREFERENCE', // Used for scoring and affinity ranking } export enum AttributeProvenance { USER EXPLICIT = 'USER EXPLICIT', // Stated directly by the user MODEL INFERRED = 'MODEL INFERRED', // Inferred from natural language context SYSTEM DEFAULT = 'SYSTEM DEFAULT', // Fallback policy } export interface BuyerProfileAttribute { category: AttributeCategory; key: string; value: BuyerAttributeValue; preferenceType: PreferenceType; provenance: AttributeProvenance; confidenceScore: number; isConfirmable: boolean; } The Provenance Rule If a customer explicitly specifies "Budget max 15 million naira", it is stored as USER EXPLICIT + HARD CONSTRAINT. If a customer mentions "I have a family", the system infers a SOFT PREFERENCE for spacious body types SUV, MINIVAN, MPV . Crucially, the recommendation pipeline enforces that model-inferred attributes cannot create artificial hard filters that would prematurely collapse viable inventory. 3.2 Pillar 2: Domain Intelligence & Goal Decomposition Raw inventory records contain low-level attributes make, model, year, price, mileage . However, users express lifestyle goals. To bridge this gap, we engineered SoftVehicleClassAffinityService to deterministically translate high-level customer intents into canonical body-class affinities without LLM hallucinations: // soft-vehicle-class-affinity.service.ts Excerpt @Injectable export class SoftVehicleClassAffinityService { private readonly goalClassAffinityCatalog: Record