Snout Engine: the layer every query and every prompt goes through
There is a layer in the middle of this app that every query and every prompt passes through. It started as a couple of files doing a couple of jobs, and it has a name now: snout-engine. Here is what it is, drawn rather than described.
It decides, and it runs nothing
The easiest way to get the engine wrong is to hear the word and picture the thing that executes your query. It is the opposite of that. The engine opens no file, holds no connection, calls no model and cannot read the clock. It takes values and returns values, and other parts of the app act on what comes back.
Purity here is not a convention someone could quietly drop. A test in the ordinary unit run asserts it: the engine imports nothing impure, nothing routes around it, and anything it needs from the outside world arrives as an argument. Break either rule and the build fails, which is a more reliable reviewer than a reviewer.
One query, end to end
Press Run and the engine is consulted before a single byte reaches your database, and once more after the answer comes back.
The loop on the left is the part worth pausing on. Every attempt is written down as a verdict, and the store holding those verdicts is handed back into the engine on the next query. The engine never goes and fetches it, which is exactly why this whole path can be tested with no database anywhere near it.
So does it learn?
There are two posts on that question in our research section: persistence is not learning, and the one honest thing you can build when persistence is all you have. The engine is where that answer lives.
A memory is written only when something deterministically failed. Not when a model decides a moment was interesting, and not on a salience score. Then it comes back like this:
The last box is the finding that shaped everything above it. A note phrased as a warning changed nothing at all: a modest model read that this had failed before and re-ran the identical statement. The same note phrased as an instruction, naming the fix and forbidding the repeat, took the repeat rate from 24 of 24 to 1 of 24 on a local model, and from 27 of 27 to 5 of 27 on a served one. Same store, same retrieval, different sentence.
How it tells what it learned from what it was told
A fair objection: once it is all text in a prompt, what keeps a memory from being just another thing somebody typed? The answer is that the engine never reads a prompt, it writes one. Facts arrive on separate typed channels, and the channels differ by who is able to write them.
| what | who can write it |
|---|---|
| a remembered failure | only an executor, by recording a verdict |
| what you are looking at | the app, from real editor and grid state |
| what your tables mean | you, explicitly, in your own words |
| your question | you, and it is only ever scored for relevance |
You cannot type your way into the failure store. A record is there because a driver raised an error or the compiler refused, and for no other reason. Your question does reach the engine, but only as words to rank your schema against, so it can steer which tables get described in full and it cannot instruct anything.
Why bother naming it
Because a named boundary is one you can defend. Without one, "where does a rewrite rule go" has a dozen defensible answers and the honest one is usually "next to whatever called it". With one, there is a rule and a test behind it: if your code inspects, rewrites, guards or grounds a query or a prompt, it belongs in the engine, and it stays pure.
The payoff shows up in ordinary work. The same guard that warns you about a destructive statement while you are still typing is the one that enforces it before the statement runs, because it is one function running in three places rather than three functions that agree for now.