Why this blog exists

This blog is about running AI you actually control. Not AI you rent access to and hope stays available on the terms you signed up for.

What you will find here

We write for the person who has to answer for the decision. That means the posts are organised around six questions a buyer eventually has to ask about any AI system they depend on:

Where does your data go, and where does it not. Whether you can swap the model provider without rebuilding. What happens when the provider has an outage. Whether you can reconstruct what the system did after the fact. Whether the rules are enforced by software you can inspect or by hoping the model behaves. And what "managed" actually means, what it costs, and what you own at the end of it.

Those six are the tags on every post. If an article does not answer one of them, it does not belong here.

Why the posts live in this repository

Until this post, the blog read its content from a database over the network at build time. That arrangement had a specific failure mode: if the API was briefly unreachable while the site was being built, the build would quietly bake a 404 into a page for an article that existed. A real reader would then be told the post was not there.

Now every post is a file in the same repository as the code that renders it. The site builds with no network access to any content service. A post that exists on disk cannot fail to be there, and the version of an article is the version in the commit history, reviewable like any other change.

This is a small example of the thing the blog is about. The question is not whether the database was good. It is whether an outage somewhere else can decide what your readers see.

What to expect

Posts are written from the buyer's problem rather than from the technology. Where a claim comes from published research, it will say so and link to it. Where something is our opinion, it will read like one.

If you want to talk about any of it, the contact page is the fastest route.