Own the citation IDs, rent the model: two RAG write-ups agree on where the contract lives

Two dev.to posts published from different domains land on the same boundary: one on turning support tickets into structured, cited answers for a property-management SaaS ^[1], the other on semantic search over messy B2B catalog PDFs ^[8]. Both treat the model vendor as a replaceable part and put the durable contract somewhere else, which inverts the question most teams start with.

The triage post's recommendation is explicit: use a portable contract for embeddings and chat completions, keep retrieval in the application, and add reranking only after an evaluation shows first-pass semantic search is losing relevant passages ^[1]. The minimum useful system is small - chunk approved documents, embed the chunks and the question, retrieve nearest matches, and ask a chat model to answer only from those passages ^[2]. According to the author, the application, not the model, owns the citation IDs and the final schema, and that boundary matters more than an elaborate orchestration framework because a triage result can route an urgent maintenance report, expose account data, or end up in an audit trail ^[3].

The catalog post reaches the same place through storage. It names the durable contract as the evidence record: stable document version, stable chunk identity, normalized text, page bounds, catalog identifiers, and the embedding configuration that produced the vector ^[9]. Upload worker, embedding adapter, and Postgres repository are treated as replaceable components around it ^[10]. It also splits metadata into two jobs that teams routinely merge: filter metadata narrows candidates before ranking (tenant, catalog version, locale, availability, exact SKU), while evidence metadata explains the result afterwards (filename, page range, chunk identifier, content hash, extraction version) ^[11]. Collapsing both into one unversioned JSON blob, the author writes, makes migrations deceptively easy and audits painfully vague ^[12].

The validation rules are where this stops being architecture talk. A triage record needs a category, a confidence value, an escalation decision, and citations resolvable to immutable document versions ^[4]; the backend validates the structure, rejects unknown categories, and confirms every cited identifier came from the retrieved set, because a fluent answer with a fabricated citation is a failed transaction ^[5]. The schema stays narrow: category as an enum of maintenance, billing, lease, or other; needs_human as a boolean; citations as an array of chunk IDs, with the application mapping a validated category to an approved queue rather than letting the model invent workflow actions ^[6].

Neither post claims exactly-once inference. The triage version gives each ticket revision a deterministic processing key such as ticket-1842-r7, records corpus version, query hash, retrieved chunk IDs, model selection, validated result and request ID, and makes the write idempotent, so a retry after a 429 may re-run inference but does not multiply the queue assignment ^[7][13]. The catalog version does it with a unique constraint on (tenant_id, document_version, chunk_id) inside one transaction, plus a content hash so reconciliation can tell a new version from a retry ^[14].

Worth noting: both are single-author recommendation posts with no measured retrieval metrics ^[16]. The triage author says a generic vendor matrix cannot settle regional processing, retention, and subprocessor questions, and that legal and security review must ^[15]. The catalog author says none of the three chunking regimes wins universally ^[17]. So the thing to build first is the eval that tells you whether first-pass search is actually dropping passages ^[1], and the thing to watch is whether your citation IDs resolve to immutable versions when someone asks why one ticket reached one queue ^[18].