The most useful output of an attribution engine is sometimes "not enough evidence."
When physical evidence arrives and someone has to say what it is and where it came from, the failure mode that matters is not ignorance. It is a confident answer assembled from thin evidence. I built a five-axis attribution engine that treats the analysis as belief revision: it starts uncertain, updates on instrument data, and refuses to declare an analysis complete until the evidence clears a bar it states up front.
6,222 lines of Python, 64 test functions. Five attribution axes, each weighted by how much the analytical-instrument data actually supports it, and a completeness gate that requires three resolved axes before an analysis can close.
Assessment software. It grades what the evidence is consistent with; a qualified examiner reads the output and owns the conclusion.
The friction
Attributing an unknown sample is a chain of measurements, each narrowing the possibilities along some axes and saying nothing about the rest. What feedstock is it consistent with. What organism. What production route and what equipment class. Whether the material is biogenic or petrochemical in origin. Each new result should move some of those questions and leave the others exactly as uncertain as they were.
Software that answers, and analysts using it, tend to terminate in a conclusion regardless. The output reads decisive even when two of the five questions were never really addressed. A wrong but decisive-sounding attribution propagates downstream: it directs the next sample, the next interview, the next line of inquiry, and the error compounds quietly.
An honest "not yet" is more useful and much rarer. Getting it out of a tool takes architecture, not a disclaimer, because the refusal has to survive an operator who wants closure.
What I built
An attribution engine built around disciplined belief revision. Three pieces carry the design.
A five-axis hypothesis space
An attribution starts as five independent questions: what feedstock the sample is consistent with, what chassis organism, what biosynthetic pathway, what production equipment class, and whether the material is biogenic or petrochemical in origin. Each axis holds a probability distribution over its candidate classes rather than a single guess, so partial evidence produces partial movement instead of a premature commitment.
Bayesian updating from instrument data
Analytical-instrument data updates the distributions axis by axis. Confidence-weighted likelihoods accumulate into posterior probabilities for each candidate class, and the same inputs always produce the same posteriors, run after run. Each axis reports its own confidence, so a strong result on one axis cannot mask a weak one on another.
A completeness gate and a next-test recommender
An analysis is only allowed to complete when at least three of the five axes clear 70 percent confidence, and the origin axis is required every time. If the gate is not met, the engine says so, names which axes remain unresolved, and recommends the single most discriminating next measurement for reducing the uncertainty. "Not enough evidence" is a surfaced outcome with a path forward, not an error.
What exists today
The engine runs, with 6,222 lines of Python behind it and 64 test functions covering the update math, the gate, and the recommender. It was built and delivered for a client, run on the client's own analytical-instrument data. Client identity and case details are withheld.
How it's built
Two design choices do the work. Belief revision is the whole architecture: the engine starts from stated priors and moves only as evidence arrives, so every posterior can be traced to the measurements that produced it. And the refusal is structural. The completeness gate is not a warning an operator can click through; an unresolved analysis stays open, and the reason it stays open is part of the output. Computation is deterministic throughout, so an examiner reviewing a result can retrace the path from data to posteriors.
What it does not do
It does not make the final call. The engine grades confidence and recommends the next measurement; a qualified examiner reads the posteriors, weighs them, and owns the conclusion. Deployment inside a working laboratory, with everything that entails for evidence handling and examiner workflow, is a separate production-build conversation.
What a client engagement would deliver
The pattern transfers to any decision made from physical evidence: state the hypotheses up front, grade each against the data, set the bar before the analysis starts, and build the refusal into the structure. A pilot applies that to one of your evidence problems, with your confidence bar and your review step in place. A production build adds the laboratory workflow on top.
How to engage
Three ways to engage, in order:
- Scoping call (free, 30 minutes). Talk through the decision your organization makes from physical evidence and decide together whether a pilot is worth it.
- Pilot. One evidence problem, your confidence bar, your reviewer in the loop, scoped before it starts.
- Production build. Scoped after the pilot. The engine becomes tooling your examiners operate under your normal review workflow.
All engagement is on standard McIntosh Consulting LLC terms.