Every write is a claim: the read-back is the proof

If people take one sentence away from my Autodesk University session, I want it to be this one: every write is a claim, and the read-back is the proof.

And it is not an idea about Vault. It is an idea about any system you ask to change something.

The failure mode nobody warns you about

Under licence contention, the system returns success and does not persist the change.

Read that again, because it is worse than it looks. It is not an error you can catch. It is a success. The call comes back clean, with the right code, and the data is exactly as it was.

A naive agent reads that success and reports the work as done. And it is not lying: it is repeating what the API told it. That is the whole problem. An honest agent can state a falsehood if its only source is the response to the call.

In my specific case this is Autodesk licensing behaviour. But the shape of the problem is not specific to Vault: any API under contention can hand you a success that did not happen.

That is why there are nine gates and not one

A single control does not cover this, because the failure is not in the model's intent but in the layer underneath. In the session I name all nine and say what each one does. How any of them is built does not leave the room, and that limit is deliberate.

The first three work before the call: identity grounding requires that the name has been read earlier in that same conversation; schema injection puts the real Vault names in the prompt every turn; pre-call validation checks the arguments against the live schema.

The next three surround the write: preview and confirm, so nothing applies without a second call; hard caps, bounding how much a single operation may touch; and the read-back.

The last three are control: a grader for what the agent claims in its narration, a read-only switch over the whole surface, and authentication as the operator's own Vault user.

The gate that saves the session

The read-back is the cheapest of them all and the one that proved its worth most often. After the write, the agent re-reads the entity and compares. If they disagree, it reports the failure it found, not the success it was handed.

Twenty-three times, across two months of development, the system said yes and the re-read said no.

Every one of those twenty-three would have been a silent lie. Something somebody believed was done, and was not. And silent lies in a PDM are not discovered when they happen: they are discovered weeks later, when somebody manufactures from the wrong revision.

Grounding, in one log line

The other one I like to show is the first gate, because it fits in a single line: refused, the file was never read or searched in this conversation.

The rule is simple. A write may only name an entity this conversation has already read or searched. Not a similar name. Not a plausible name. That exact one.

And there is the deeper reason: a model forced to invent a name will invent a plausible one, and plausible is the failure you do not catch by reading the answer. In the Vault I built this against, the working state is not called "Released" or "WIP" in English: it is called whatever the customer named it years ago. No model guesses that. It has to be shown, every single turn, from the live configuration.

The numbers, and what they do not prove

I am going to Las Vegas with figures that were counted, not estimated: forty-five distinct Vault operations invoked from natural language, two hundred and forty-nine calls that reached the system, eighty writes stopped by a gate before touching anything, and those twenty-three read-backs that contradicted the API.

And on the same slide, highlighted: that is not a production success rate. It is a development log, from one instance against Vault Professional 2026, kept while the tools were still being written.

I could have removed that line. I keep it because it is exactly what I demand of anyone selling me automation, and because the number that matters is not mine: it is yours.

No baseline, no claim. If you cannot say what it cost before, you cannot say what it saves after.

MFG3731 · Vault on Autopilot. Thursday September 17, 2026, 4:30 PM, Autodesk University, Las Vegas. A 60 minute Technical Deep Dive on the Design and Manufacturing track.