How we write here
The Knowledge Center exists to teach the discipline of operating autonomous AI. This page states what we commit to, how the library is organized, and the one boundary we hold on every page. For a company whose product is assurance, publishing our own standard is part of the point.
What this library is for
Most of what you will read here is not about Provy. It is about a problem: enterprises can build autonomous AI faster than they can trust it, and closing that gap is a discipline with its own ideas, trade-offs, and hard questions. Our goal is that you finish each page understanding the field better, whether or not you ever become a customer. If a page only makes sense as a reason to buy something, it does not belong here.
What we commit to
Three promises govern everything published under this banner.
Every page answers a real question an enterprise asks: what a concept is, why it matters, and when to apply it. Product references stay at the edges. If we cannot explain an idea without selling, we have not understood it well enough to publish it.
We argue carefully and stay fair to the tools and approaches we compare ourselves against. Observability, evaluation, and governance each do a real job; we say so plainly before we explain what they do not do. We would rather be precise than impressive.
Plain English, short where we can be, no jargon for its own sake, no field names or internal terms a reader would have to work to decode. Every important idea has a one-sentence version you can quote.
One boundary: we teach the what, not the how
There is a line the Knowledge Center does not cross, and this is the one page that states it in full. Individual pages no longer each carry their own scope note; they rely on this one. We explain what these ideas are, why they matter, and when to use them. We do not explain how Provy is built.
That is a deliberate choice, and it is worth being open about. The methods behind measuring an outcome, scoring reliability, or separating an agent's mistake from bad luck are where our engineering and our research live. Publishing them would not make you better at the discipline. It would only hand a blueprint to someone rebuilding our product. So we teach the mental models in full and stop at the mechanics. When a concept can only be explained by revealing method, we give you the model instead and say so.
Concretely, that means we will name a hard question the discipline cares about, for example whether a wrong result was the agent's mistake or the world moving underneath it, and we will not describe how it is answered. We name the question. We do not publish the technique.
On the rare page where a reader would genuinely ask "how," you will see a short boundary note like this one, marking that we are describing the discipline rather than a specific implementation of it. It is not evasion. It is the same line any serious assurance company draws between what it will teach and what it will only do.
How the library is organized
Four kinds of writing, each doing a different job.
- Start Here is the front door: the learning path that lays out the discipline in order, from the problem to what closes it. Begin here if the field is new.
- Research is the authority layer. Long-form, evergreen papers and frameworks that define each idea in full, with citations and references.
- Concepts define one idea per page, plainly and precisely, so every term has an exact place to point to and link from.
- Insights are shorter essays that take a single point of view on what operating autonomous AI actually teaches you.
The library is deliberately small. We would rather publish a handful of pages an enterprise architect trusts than a hundred that pad a content calendar. It will grow, slowly, as new ideas earn a place.
Start with the anchor paper
The Enterprise Confidence Gap is the piece everything else ladders up to. It defines the problem this whole library exists to address.
Read it