Don't start at the model layer: classify inputs by reliability, then let RAG wait

The team behind Inspecly published a build note on dev.to arguing that the expensive mistake in AI product work is starting at the model layer, and that the first question should be what information you actually have, how reliable it is, and which system should process it ^[1][3]. The consequence is architectural rather than philosophical: once inputs are classified by reliability, the fashionable components (vector database, RAG, agents, one large multimodal prompt) get demoted from foundation to fallback ^[2][11].

The inputs in this domain are messy by construction. A single request can arrive as a written description, a voice message, vehicle photos, an OBD scan, vehicle metadata, or only some of those ^[4]. According to the post, these are not interchangeable text: an OBD code is structured data, a photo is visual evidence, a voice note is what the driver observed, and vehicle metadata may need an exact lookup ^[5]. So the pipeline builds a normalized evidence object first, holding make, model, optional VIN, description, transcription, OBD codes and images, and containing no diagnosis at all ^[6].

That object then routes. OBD code to deterministic lookup, vehicle information to exact lookup or API, photo to visual analysis, voice to transcription, unknown technical information to tool-based retrieval, safety constraint to an explicit business rule ^[7]. Two of the six paths never touch a model, and a third is a hard-coded rule ^[18]. Collapse them into one multimodal prompt and you get something attractive for a prototype, difficult to control, and unable to answer where a conclusion came from ^[8].

The ordering rule that does the most work: if reliable structured information already exists, use it directly ^[9]. When a diagnostic trouble code is present, the system queries a curated OBD database whose records carry explanation, possible causes, possible actions and a validation_status of reviewed ^[9]. Semantic retrieval over paragraphs is the wrong instrument for an exact identifier against validated fields; RAG earns its place when the knowledge only lives in documents ^[10].

Agents arrive last, and conditionally. The internal database cannot cover every code, every manufacturer-specific interpretation and every vehicle configuration, so a tool-using agent searches when structured knowledge is missing ^[11]. The stated discipline is that such output is tagged with a source type of tool_agent and a validation_status of unverified rather than quietly acquiring the standing of a reviewed record ^[12]. The system is meant to know at all times whether a fact came from the reviewed internal database, an external technical source, an agent, image analysis, or the driver ^[13].

Vision gets the same treatment. A photo can show a dashboard warning light, body damage, tyre wear, a fluid trace or a damaged component, but the post notes it almost never tells the whole story ^[14], so the output is an observation with confidence, limitations and a requires_physical_inspection flag, not a flat "Your vehicle has an oil leak" ^[15]. The author's blunt version: AI systems often sound more certain than the evidence actually allows ^[16]. Voice is treated as one more source of context ^[17].

What to watch: this is one team's account, with no accuracy, latency or cost figures attached to any of it ^[19]. The load-bearing questions are operational. Who keeps coverage of the curated OBD database current as codes and manufacturer variants multiply, given that the post concedes it cannot be complete ^[11]. And whether validation_status survives into the user-facing answer, or gets flattened back into prose by the final prompt, which would undo the provenance the rest of the pipeline exists to preserve ^[12][13].