Structural templates: the matching layer vectors can't see
Embeddings blur exactly where caches need precision, numbers, dates, entities. Template abstraction catches what cosine similarity structurally cannot.
Embeddings have a known blind spot: they compress meaning into geometry, and small tokens with huge semantic weight, negations, identifiers, quantities, barely bend the vector. 'Invoice #4412' and 'invoice #9981' embed nearly identically, which is correct for similarity and catastrophic for a cache that might serve one customer's invoice status to another.
Crowkis's template engine attacks the problem from the structural side: numbers, dates, IDs, and entities are lifted out of the query into typed slots, and the remaining skeleton, 'status of invoice <ID>', is hashed. Two queries match structurally when their skeletons agree; their slots are then compared explicitly, where <ID>=4412 versus 9981 is an unmistakable mismatch rather than a rounding error in cosine space.
- 1incoming query
- 2intent classifier
- 3template match
- 4HNSW neighbours
- 5confidence gate
- 6trust + freshness
- 7answer · <1ms
- 8(nil) → your model
Reuse only when meaning, structure, confidence, and trust all agree.
The dual requirement is the safety story: a hit needs the vector to say 'same meaning' and the template to say 'same structure, compatible slots.' Each side covers the other's blindness, vectors catch paraphrase that templates can't, templates catch precision that vectors can't. Single-signal caches choose one blindness; we declined.
The bottom line
Templates also multiply hit rates on parametric traffic: one cached skeleton serves infinite slot variations of commands, lookups, and form-letter queries. The layer that protects you is the same layer that pays you.