Pattern-Approved Retrieval
RAG generates.
PAR matches.
PAR keeps the retrieval foundation RAG made standard, then swaps the generation step for a pattern a human already approved. Same input, same answer, every time.
400,000/sec
decisions, one commodity node
Zero
LLM calls in production
Named
approver on every decision
The One Substitution
Same record, same answer, every time, with a name on it.
A state examiner does not want a good answer; they want the same answer they got last quarter and the name of the person who stands behind it. Any system that writes fresh text on every request fails both of those tests. PAR keeps the retrieval and removes the writing step.
In six words
Retrieval, with a human approval gate.
In one sentence
PAR discovers the patterns already in your data, has your own experts sign off on each one, then matches every new record against the approved set at 12ms p95.
In one paragraph
PAR runs on the same primitives as RAG (embed, index, retrieve by similarity) and swaps the final step. Instead of handing retrieved context to a language model that writes an answer, PAR returns the nearest pattern a human already approved. That one substitution makes the output deterministic, makes hallucination structurally impossible, drops per-record API cost to zero, and puts a named approver and a timestamp on every decision.
RAG
Retrieval-Augmented Generation
The first four steps are retrieval your team already runs; the fifth writes something new, and that is where reproducibility ends.
PAR
Pattern-Approved Retrieval
Same retrieval foundation, plus a gate; the final step returns a pattern your own expert signed off on, at 12ms p95.
Swap the generation step for a human approval gate and you don't get a better answer; you get the same answer, every time, with a name on it.
What follows from it
Same input, same answer
Same record, same pattern, same similarity score, whether you run it today or reproduce it for an examiner two years from now.
Nothing to hallucinate
There is no generation step, so there is nothing to invent; PAR returns a pattern from the approved set or it returns no match at all.
Cost stops tracking volume
Zero LLM calls in the production match path means zero per-record API cost, so your bill stops climbing with your record count.
Named approver, every time
Every decision logs the pattern ID, the approver, the timestamp, and the similarity score, so “why was this record flagged?” answers in one SQL join.
The Lineage
One letter changed. Generation became Pattern-Approved.
PAR is not a rebrand, and it is not a science project. The retrieval line it sits at the end of runs back to 2017, through the papers that made vector search an enterprise default and the libraries your data team probably already runs. What PAR changes is the last step, and only the last step.
70%
of GenAI companies use RAG
Databricks State of Data + AI, 2025
377%
year-over-year growth in vector database adoption
Databricks, 2025
72–80%
of enterprise RAG never reaches production
CloudFactory / industry consensus
- 2017
DrQA (Facebook AI)
Retrieve then read. The ancestor of every retrieval system since.
- 2017
FAISS (Facebook AI)
Billion-scale vector similarity search, open-sourced. Still the engine underneath.
- 2019
kNN-LM (Facebook AI, Stanford)
Nearest-neighbor lookup augments a language model's predictions.
- 2020
DPR (Facebook AI)
Dense vector retrieval beats keyword search.
- 2020
RAG (Facebook AI)
Embed, index, retrieve, generate. The G enters the stack.
- 2022
ChatGPT (OpenAI)
Hallucination stops being an academic concern and becomes a boardroom one.
- 2023
RAG becomes the default
Every major cloud vendor ships a RAG service.
- 2024
RAG matures
GraphRAG, corrective RAG, agentic RAG. The G remains.
- 2025
PAR (Coherany)
Same retrieval foundation. The generation step becomes an approval gate.
The 2024 node
GraphRAG, corrective RAG, and agentic RAG each made retrieval smarter and left the generation step exactly where it was. The G remained.
Why the name is PAR
PAR stands for Pattern-Approved Retrieval, and the name was picked to make the relationship to RAG explicit rather than hide it. One letter changes: Generation becomes Pattern-Approved. Everything before that substitution is identical, down to the embedding model and the index type.
Retrieval-Augmented Generation
Pattern-Approved Retrieval
RAG's inventors at Facebook AI solved the retrieval problem. They gave language models a library card. PAR's contribution is recognizing that for classification in regulated industries, the language model never needed to check out a book. It just needed to look up the right shelf, and a domain expert needed to have organized that shelf first.
The PAR Pipeline
Discovery runs once per dataset. Matching runs forever at 12ms p95.
Phase 1 builds the pattern library. It runs once per dataset and ends with a named human signing off on every pattern that reaches production. Phase 2 runs on every record that arrives after that, at 400,000 decisions per second, with no LLM anywhere in the path.
Phase 1: Discovery
runs once per datasetYou ask in English, the pipeline surfaces the patterns already sitting in your data, and your experts decide which ones reach production.
Raw records become fingerprints
Each record becomes a consistent, domain-shaped description instead of an arbitrary text chunk. This is where your experts' knowledge enters the system, and it decides everything downstream.
Domain-informed composition template, built visually in Studio. No code.
Fingerprints become vectors
The same embedding step any retrieval system runs. Nothing proprietary here; PAR uses the standard math your data team already maintains.
nomic-embed-text-v1.5, 768-dim, L2-normalized, search_document: prefix.
Patterns surface without labels
Clustering finds the groupings already present in your data. No labeled training set, no six-month annotation project, no guessing at categories before you start.
HDBSCAN over UMAP-reduced vectors. Confidence scored on four signals.
Your expert signs off
Each draft pattern goes to the person who knows the data best, who approves, rejects, merges, or refines it. An LLM coach proposes wording and surfaces edge cases; the expert signs off.
Approver, timestamp, and per-pattern similarity threshold recorded here.
Only approved patterns get indexed
The production index holds hundreds of approved patterns, not millions of raw chunks. Smaller index, faster search, and nothing in it that a human didn't sign off on.
FAISS IndexHNSWFlat, inner-product metric. Hundreds to low thousands of vectors.
Phase 2: Matching
runs continuouslyEvery record that arrives from here on runs the same route, deterministically, with a name attached to the answer.
Same template, new record
A new claim, ticket, or reading gets composed with the identical template used in discovery. Change it and the similarity scores stop meaning anything, so the template is locked to the dataset.
Event-driven: PostgreSQL NOTIFY on insert queues the job.
Same vector math as discovery
The identical embedding operation from step 02, one record at a time. No new model, no retraining, no drift between how patterns were built and how records get scored.
Nearest approved pattern wins
The record scores against every approved pattern and returns the closest one clearing that pattern's threshold. 12ms p95, 400,000 decisions per second on a commodity node, zero LLM calls.
FAISS HNSW batch search. Multi-match enabled; below threshold, no match.
Every decision leaves a record
Each match writes the pattern ID, the approver's name, the timestamp, and the similarity score. When an examiner asks why a record was flagged, that is one query, not a project.
Written to a partitioned match store. Unmatched records logged separately.
Gaps become the next patterns
Records that matched nothing accumulate, cluster, and come back as draft patterns for review. The library grows out of its own blind spots, which is why PAR gets sharper with volume.
Mini-HDBSCAN over unmatched records seeds the next review queue.
↶ Unmatched records feed the next discovery round.
What is not in Phase 2
Count the LLM calls in Phase 2: there are none. The model coaches your expert through the review gate at step 04, and from step 06 onward it is not in the path at all.
The Load-Bearing Steps
Your expertise, your accountability, and your next round of patterns all live in three of these steps.
Most of the ten steps are mechanics: compose a thing, embed a thing, look a thing up. Three of them are where PAR actually differs, and those three are the ones worth taking apart before you sign anything.
What goes into the fingerprint sets the ceiling on every decision that follows.
RAG chunks mechanically: split on token count, overlap at the boundaries, trust that the chunk caught enough context. That works when a language model is going to read the chunk and write an answer from it. It works against you when the chunk is the decision, because a 512-token boundary lands where it lands and can cut a liability clause in half. PAR composes on purpose. A weather fingerprint carries 72 hours of neighborhood temporal progression and the spatial gradients around it; a turbofan fingerprint carries a 10-cycle drift window of baseline-relative sensor deltas. Neither is a chunk. Both are a domain expert's judgment about what actually separates one case from another, written into a form the engine can index. Coherany Studio exists mostly so that expert can design the fingerprint without writing code: 1,507 pre-built templates, 143 visual nodes.
Get the fingerprint right and everything after it is plumbing.
Nothing reaches production without a person putting their name on it.
The clustering step proposes draft patterns. It does not get to ship them. Every draft goes to the person who knows the data best, and they approve, reject, merge, or refine it, with an LLM coach at their shoulder proposing wording, surfacing edge cases, and explaining tradeoffs in plain English. The coach can suggest and explain. It cannot approve. For volume, you set an autopilot threshold so drafts scoring above your confidence bar clear automatically, and that threshold is itself a policy a human defines and signs off on; a person can override any pattern at any time. What ships is a pattern with a named approver, a timestamp, and a complete audit trail, which is exactly the artifact your examiner asks for.
The LLM coaches. The person decides. That order is the whole compliance story.
The records that matched nothing are the most valuable output of the run.
Most systems treat a non-match as a failure and drop it in a queue nobody reads. PAR treats it as the seed corpus for the next discovery round. Unmatched records accumulate, cluster, and come back as draft patterns for a person to review, so the library grows out of its own gaps instead of out of a roadmap meeting. This is a structural property RAG's retrieval quality does not have: a RAG index returns what was chunked into it, and it returns the same quality on day 400 as on day one unless someone re-ingests. The misses are also where the interesting cases live. On the NASA C-MAPSS turbofan dataset, records that matched no approved pattern carried a 3.3x anomaly premium.
Your misses today are the drafts your team signs off on next round.
A 512-token boundary lands where it lands, and it can cut a liability clause in half.
Step 01 · Compose
“Why can't I just use RAG for this?”
You can, and if you already run RAG you already run the foundation: the embeddings, the index, and the similarity search are the same. The difference sits on either side of the retrieval. RAG chunks on token boundaries because a language model is going to read the chunk and write an answer from it, and a chunk only has to be good enough to write from; PAR composes a domain-informed fingerprint because in PAR the fingerprint is the decision itself. Then, instead of generating an answer, PAR returns the nearest pattern a named person already approved, at 12ms p95 with zero LLM calls in the production path.
Shared Foundation
Your team already runs roughly 60% of PAR. The rest is a workflow change, not an infrastructure project.
Same HNSW indexes, same cosine similarity, same vector math your team already maintains. PAR sits on the retrieval foundation you are already running and changes what happens after the search returns. The adoption work lands on the workflow layer, not on your infrastructure.
Shared with RAG (~60%)
If you run RAG today, you already operate every line of this.
Embedding models
Same models, same providers, already in your pipeline.
L2 normalization
Unit vectors before indexing. Already a step you run.
HNSW approximate search
The same graph index your vector search already builds.
Cosine / inner-product similarity
Same distance math. Nothing new for your team.
Batch processing
Parallel embedding jobs your team already schedules.
What PAR adds (~40%)
Six additions. Every one of them workflow, none of them a migration.
Deliberate composition
Domain-informed fingerprints replace chunking on token boundaries.
HDBSCAN pattern discovery
Clustering surfaces the patterns already in your unlabeled data.
Human approval gate
Nothing reaches production without a named approver signing off.
Per-pattern thresholds
Precision tuned per category, not one global setting.
Deterministic matching
Same record, same pattern, same score, every run.
Unmatched feedback loop
Records that match nothing seed the next discovery round.
What PAR removes
One component. The LLM, out of the hot path.
Every decision is a FAISS lookup against approved patterns, so there is nothing to rate-limit, no vendor outage that can stop production, no token budget to forecast, and no per-record API cost on the line item. Match latency holds at 12ms p95 whether or not your provider is having a good afternoon.
Zero LLM calls in the production match path.
The stack, named
- Embedding model
- nomic-embed-text-v1.5. 768 dimensions, L2-normalized.
- Vector index
- FAISS IndexHNSWFlat, inner-product metric.
- Vector storage
- PostgreSQL with pgvector, HNSW indexes.
- Pattern discovery
- HDBSCAN density clustering via BERTopic. No labels required.
- LLM providers
- Bring your own key. Claude, OpenAI, Bedrock, Ollama. No vendor lock.
Runs on your infrastructure. Nothing leaves your VPC.
What the Substitution Buys
The decision holds still, the trail holds up, and the bill stops climbing with volume.
None of these are features somebody added. They are what a system does once you take the generation step out and put an approval gate where it used to be. You do not turn determinism on; you get it because nothing left in the production path is capable of returning a different answer twice.
The answer holds still
Run the same record twice and you get the same pattern, the same similarity score, and the same outcome.
A match is a nearest-neighbor lookup against a fixed set of approved patterns. There is no sampling step, no temperature setting, and no quiet model version change that can move the answer between today and your next exam.
For the Chief Compliance Officer who has to defend last quarter's decisions using this quarter's system.
Nothing writes an answer
PAR cannot invent a category, because no part of the production path generates text.
The generation step is gone. A record either matches a pattern a person approved, or it matches nothing and routes to review. Those are the only two outcomes the system has available to it.
For the general counsel, and for the plaintiff's attorney who will go looking for the part that was generated.
Matched on arrival
Every record gets matched as it lands, so there is no overnight batch and no scoring queue to drain.
400,000 decisions per second on a commodity node, at 12ms p95. No LLM sits in the hot path, so there is no rate limit to hit and no vendor outage that can stop production.
For the VP of Claims Operations who keeps being told the backlog is a staffing problem.
Flat cost curve
Adding records does not add per-record API cost, so the curve flattens instead of tracking volume.
Zero LLM calls in the production match path means there is no per-record token charge on the line item. Your cost tracks infrastructure and storage, which you can size in advance, not record count, which you cannot.
For the CFO who has to forecast a number that currently moves every time the business grows.
RAG is the right architecture when you need an answer written in prose; PAR is the right one when you need a decision you can defend. Read the table as two sets of guarantees for two different jobs, not as a scorecard.
| Dimension | RAGRetrieval-Augmented Generation | PARPattern-Approved Retrieval |
|---|---|---|
| Determinism | Non-deterministic | Same input, same score, always |
| Hallucination | Present | Structurally impossible; nothing generates |
| Human approval gate | None | Required before production |
| Audit trail | Typically none | Pattern ID, approver, timestamp, score |
| Index contents | Every chunk, millions of them | Approved patterns only, hundreds |
| Latency | 500ms to 3s | 12ms p95 |
| Cost curve | Tracks record volume | Flat; no per-record API cost |
| Feedback loop | Typically none | Unmatched records seed new discovery |
The regulator test
A market conduct examiner will not ask how the system works. They will pick one record and ask about that.
“Why was this record classified this way?”
That question is one SQL join. The decision row carries the pattern it matched, the similarity score it matched at, the name of the person who signed that pattern off, and the timestamp on both the decision and the approval. Producing the answer takes a query rather than a project, and re-running the record today returns the same pattern it matched then.
The same query works for one record or for every record in the exam sample.
Eight rows is the short version. See the full PAR and RAG comparison
Who PAR Is For
Everyone keeps their job and their judgment. The system scales what they already know.
PAR runs through a long chain in a regulated enterprise: the adjuster who triages first notice of loss, the officer who signs the audit response, the examiner who reads it two years later. Every seat lands in the same place, which is that the expertise stays with the person who has it and the engine runs their call at volume.
Claims Adjuster
Keeping the judgment they spent 18 years building
“PAR is the first tool that asked me what I know instead of telling me what to do.”
VP of Claims Operations
Senior-adjuster hours in a market with no hires
“I'm not buying AI. I'm buying back senior-adjuster hours in a market where I cannot hire another one.”
Chief Compliance Officer
Defending every decision when the auditor asks
“Every RAG failure that worries you traces to the G. PAR removes that letter.”
Chief Data Officer
Whether it fits the stack they already run
“My team didn't need training on the retrieval layer. They needed training on the approval workflow. That took an afternoon.”
Data Scientist
Whether the method survives technical scrutiny
“Standard ANN search, nothing exotic. The unusual part is that a person put every vector in the index there on purpose. My team sponsors and reviews; the domain experts operate.”
State DOI Examiner
Whether a decision reconstructs two years later
“Why was this record classified this way?” answers in one SQL join. The examiner spends less time in your files, not more.
Nobody in that chain gets replaced. Their judgment gets a name, a timestamp, and 400,000 decisions a second.
Honest Boundaries
What PAR is not, and where the ceiling sits.
The fastest way to understand an architecture is to find out what it refuses to do.
Not a chat interface that hallucinates answers about your data
The production path generates nothing, so there is nothing to hallucinate. Every decision is the nearest pattern a person already approved, returned with its similarity score.
Not a GPT wrapper
The engine does not call an LLM to match anything. Every decision is a lookup against approved patterns, which means zero LLM calls in the production match path and zero per-record API cost.
Not a forecasting or time-series platform
PAR matches a record against patterns that already exist in your data. It does not predict what happens next quarter. If you need a forecast, that is a different tool and we will say so on the call.
Not a deep-learning training shop
PAR trains nothing. It embeds with an off-the-shelf model, clusters to surface the patterns already in your data, and indexes the ones your experts approve. No model weights, no GPU fleet, no retraining cycle.
Not a replacement for a senior data scientist on hard problems
Your data scientists sponsor the pattern library and review what ships. Your SMEs operate it, with an LLM coach helping them define each pattern and never approving one. The 20% that actually needs a data scientist stays with them.
Not a GenAI content tool
PAR writes nothing. Every output is a pattern ID, an approver, a timestamp, and a similarity score. If you need generated copy, that is a different category of tool.
The ceiling
The ceiling is XGBoost-class, and that is a design decision rather than a gap. When a problem genuinely needs a deep neural net, hire a specialist; when it needs matching that holds up in an exam two years later, that is exactly the job PAR was built for.
PAR on Public Data
No labels, no training set, and four public datasets you can re-run yourself.
These are retrospective runs on public data, not customer deployments. Coherany is pilot-stage with no closed customers, so none of this is customer data; every dataset below was published by NOAA, NASA, New York City, or CMS, and anyone can download it and re-run the work. The same PAR pipeline ran all four with no labels and no hand-written rules; only the composition template changed between them.
8 days
Before the Woolsey fire
Twenty NOAA stations, seven years of readings, zero labels. The Santa Ana drying cascade was visible in the public record eight days before ignition. Every threshold alert system missed it.
NOAA Integrated Surface Database
Read the study4 days
Before the Brooklyn outage
52,636 electrical complaints, 254 patterns discovered, no rules written by hand. The outage-day Brownsville cell matched a named, human-approved pattern at 90% similarity.
NYC Open Data 311 Service Requests (76ig-c548)
Read the study3.3×
Anomaly premium on unmatched windows
About 30% of operating windows matched none of the 140 discovered patterns. Those windows held 5.9% critical states against 1.8% in the matched bucket.
NASA C-MAPSS turbofan benchmark (simulated fleet)
Read the study3× to 6.6×
Banned-doctor concentration
294,740 doctors grouped by billing behavior with the exclusion list hidden. Four groups held already-banned doctors well above baseline. 918 more in those groups have never been investigated.
CMS Medicare DMEPOS Public Use File + OIG LEIE
Read the studyWhat a retrospective run is worthA retrospective run proves the pattern was discoverable in the data before the event; it does not prove anyone would have acted on it. None of these four ran live inside a utility, an agency, an MRO, or a payer, and what they establish is narrower and more useful than a prediction: the signal was there to be found.
The interesting part
The records that matched nothing were the most valuable ones.
On the NASA run, about 30% of operating windows fit none of the 140 discovered patterns, and that unmatched bucket carried 3.3× the concentration of critical engine states. Under PAR those records are not a failure of the pattern library; they are the seed corpus for the next discovery round. The library grows out of its own gaps, which is why it gets better the longer it runs.
Full methodology, raw counts, and the honest limits for every run: Read all four benchmark studies
The Evaluation Questions
Every evaluation lands on the same questions.
These come up on the second call, usually from whoever has to defend the decision to a regulator later.
“We can build this ourselves.”
Can we build Pattern-Approved Retrieval in-house?
Retrieval is a sprint. Your team already knows how to stand up embeddings, an HNSW index, and similarity search. Pattern-Approved Retrieval is that plus five more systems: a discovery layer that surfaces patterns in unlabeled data, an approval workflow your compliance function will actually sign, per-pattern thresholds, a feedback loop for the records that match nothing, and an audit trail that holds up under examination. Scope those five honestly and the build-versus-buy math is a data science team at roughly $1.2M to $1.8M a year against $200K to $400K for Coherany self-hosted, with the interface still to write.
“How is this different from ChatGPT?”
How is PAR different from a general-purpose language model?
A general language model writes a new answer every time you ask, and it cannot tell you which earlier decision that answer is consistent with. Pattern-Approved Retrieval does not write anything. It returns the nearest pattern a named person on your team already approved, with the similarity score, the approver, and the timestamp attached to the decision. Same record in, same pattern out, on the first run and the ten-thousandth.
“We already have RAG.”
What does a team that already runs RAG have to learn?
Then the hard infrastructure is already yours. What your team picks up is workflow, not vector math: composing a domain fingerprint instead of chunking on token boundaries, reviewing draft patterns, and setting a threshold per pattern. The people doing that work are your subject matter experts, the ones who already know what separates one case from another. Your data scientists sponsor and review.
“Isn't unsupervised clustering unreliable?”
Is unsupervised clustering reliable enough for production decisions?
Clustering does not ship anything. It proposes draft patterns, ranked by a confidence score computed on four signals, and every draft goes to the person who knows the data best. They approve it, reject it, merge it with another, or refine the wording, with an LLM coach at their shoulder proposing language and surfacing edge cases. Nothing reaches production without a name on it, which means an unreliable cluster ends its life as a rejected draft rather than as a decision in your system of record.
“What if the patterns miss something?”
What happens to records that do not match any approved pattern?
Records that match nothing are not dropped on the floor. They accumulate, cluster, and come back as draft patterns for review, so coverage expands exactly where it was thinnest. That queue is also where the unusual cases collect: on NASA's C-MAPSS turbofan dataset, records that matched no approved pattern carried a 3.3x anomaly premium.
“Our data is too specialized.”
Does PAR work on highly specialized or industry-specific data?
Specialization lives in one step. Before anything is embedded, your records are composed into a fingerprint your own experts design: which fields matter, what time window travels with the record, what counts as surrounding context. Every step after composition is identical whether the data is claims notes, sensor telemetry, or clinical documentation. The domain-specific part is the template, not the pipeline.
What does PAR stand for?
PAR stands for Pattern-Approved Retrieval. It is a retrieval architecture that discovers the patterns already present in a dataset, routes each one to a human expert for approval, then matches every new record against the approved set in production. The name marks the one substitution that defines it: where Retrieval-Augmented Generation ends with a language model writing an answer, Pattern-Approved Retrieval ends with a pattern a person signed off on.
Is PAR a replacement for RAG?
No. PAR is a descendant of RAG, built on the same embed, index, and retrieve foundation, and in most stacks the two run side by side. RAG is the right architecture when the job is to generate an answer for a person to read. PAR is the right architecture when the job is a decision you have to defend, where the same input has to produce the same output and someone's name has to be on it.
You know how PAR works. The open question is what it finds in your data.
A pilot runs the discovery pass on your own records and ends with a pattern library your experts reviewed and signed off on, plus the audit trail behind every match it made.
$10K pilot. 6 weeks. Credited to annual.
Not ready for a call? The benchmark studies show what pattern discovery surfaced on public datasets, run end to end. See the benchmark studies