Local Intent. Autonomous Execution.
AI that treats your work as yours
It runs on infrastructure you own, governed the way any other production system is governed - so it can act, and you can still answer for what it did.
The shape of the problem
Most AI arrives as somebody else's service. The model lives elsewhere, your material travels to it, and the terms are set by whoever owns the endpoint. For a great many organisations that is not a deployment option - it is a reason not to start.
So they don't start. Not because the technology doesn't work, but because the only shape it comes in is one they cannot accept.
What it is being built to do
Each of these is a design commitment, written down in advance so it can be held against the finished thing.
Work where your material already is
Contracts, source, case files, the records that are not permitted to move. It is intended to read them in place, on hardware under your control, rather than asking you to send your business somewhere else and trust the terms afterwards.
Act, not just answer
A chatbot on a workstation is private and is not operations. The intent is a system that carries a task through and produces a result you can use - not one that describes what you should do next.
Leave a record worth reading
What was done, on whose authority, and why. Not a log for a developer to grep, but an account a person who was not in the room can follow afterwards.
Ask before it exceeds its remit
Authority is granted deliberately and stays bounded. Where something falls outside what was granted, the intended behaviour is to stop and ask rather than to proceed and explain later.
Prove it can put it back
Nothing destructive should happen on the strength of an assumption that recovery will work. The principle is simple and unforgiving: demonstrate the restore before you accept the removal.
Say when it is broken
The failures that hurt are the quiet ones. Most systems are built to read silence as good news, and a system that cannot tell you it has stopped working is the one that costs you the most.
Authority is a process, not a size
There is an assumption that this kind of rigour belongs to large organisations, because only they can afford the committee. That has it backwards. Authority comes from a governed process, and a process can be small. What it cannot be is absent, improvised each time, or dependent on somebody remembering.
A small organisation running a disciplined process is more trustworthy than a large one running none. Size is not the qualification. The process is.
A refusal, not a result
The system caught its own model.
A local model was asked to produce a structured document. It invented a section that was not in the approved definition — fluent, correctly formatted, entirely plausible, and not real.
The check that runs before any output is accepted compared the result against the definition, found the invented section, refused the output and recorded the refusal. Nothing shipped. Nobody was told a thing that was not true.
Not an illustration: Fluent nothing — the incident this describes, written up in full.
That a model can be confidently wrong is ordinary; every model is. The part worth showing is what happened next: it was caught before anyone saw it, the refusal was attributed, and the record survives the session it happened in.
Writing
All posts →A gate that only read the grammar
Sixteen units of work passed verification. Ten were defective. The gate checked the syntax; a person checked the meaning.
It refused to half-upgrade
A device declined an incomplete update and stayed on the old version rather than run half-upgraded. The refusal was the feature.
Not asked is not broken
When a status signal reports failure without a question, it trains operators to ignore the signal. We updated the control logic to distinguish between silence and failure.
Fluent nothing
"AI-assisted" gets read as "worthless". That is the wrong axis. Slop comes from an empty brief, or from nobody reading the draft afterwards - never from the tool.
