Acting on the record
Machines already do a lot of work without a person checking each step. They answer questions, work through a single job over several days, and decide what happens next. We care about whether the record of that work survives in a form someone else can check: an answer that names its sources, finished work that shows the checks it passed, a decision that can be reproduced from the facts that held when it was made, and a model response that says which model, prompt and rules produced it.
Beneath the models
We don’t build models. They keep getting better and easier to swap, and the same work can run on a different model next year. The requirements around them keep moving: what a machine is allowed to do, how it does it, and how it works with the people who answer for the result. We call that the intelligence layer. It sits beneath the models and the systems built on them, and it is where we work.
Where evidence gets lost
Evidence usually goes missing at hand-offs, such as when information becomes an answer, an answer becomes work, a judgment becomes an action, or one model replaces another. Each step tends to keep its result and drop what supported it. Our products keep that connection at those points, so the source, the run, the decision state and the evaluation standard are still available later.
The factory lesson
About a century ago, factories learned that they could stop inspecting every part. They checked a sample instead, drawn at random and often enough to notice when the process started to drift, and let it decide whether the line kept running. When the sample showed a problem, the line stopped and someone looked for the cause. Most machines that act on their own today are not checked this way. They are usually checked where people already look, so the cases that go wrong without raising any flag are the ones nobody sees.
A modern example
Settling a supplier invoice by email means asking for the invoice, reading the PDF that comes back, questioning a line that does not match the order, waiting days for the reply, and booking the payment. A machine can now do all of it without a person at each step, and nobody reads every email it sends. The factory lesson still applies: each settled invoice keeps its record (the emails, the document, the checks it passed and the approval for the payment), and a regular sample of settled invoices goes to a person who checks them against that record. While the sample stays clean, the machine keeps its authority; how long it has been running is not part of that judgment. When the sample shows a problem it stops, and a person decides when it resumes.
What we hold to
We keep the material a claim was made from, and we keep it addressable, so an answer can cite its record and a decision can show the facts and conditions behind it. We are explicit about standing: a supported answer is not necessarily true, a proposed result is not complete, and a judgment is not an authorization. We treat missing and not yet as honest results rather than rounding them up. New evidence can change what a system says or does, up to stopping it. The evidence we ask for is sized to the claim, since an answer, a finished task and an automated decision need different kinds of support.
How we work
As a lab, we test what we build on everyday tasks and publish the results, including runs that did not finish. Each published figure says who produced it, what it rests on, how many runs it covers and under what conditions. We use models, rules, logs, validators and statistics where they fit, and our part is keeping the evidence attached as work moves between them.
The name
fineSample is one word with a small f and a capital S, including at the start of a sentence. It is not shortened to “Fine” or split, because “fine” on its own reads as a penalty. The name means a sample good enough to act on.