Questions about Fidelity Horizon
The build-vs-buy question, what counts as an error, what happens when things change, and what it costs.
Can't we build this ourselves — isn't it just rules?
Your standard defines what an error is, after the fact, with the answer key in hand. You can write that yourselves. The hard part is the promise about the future: choosing, in advance, across ten thousand unseen cases, which ones to release so that at most 5% of the released turn out to violate the standard, per case type, on limited data, self-monitoring as the world drifts. A rule engine answers “does this text contain X?” We answer “how much future error does this limit let through — and how does the promise hold when something changes?”
The do-it-yourself pitfalls are measured: fixed thresholds drove false alarms toward 50% when the world shifted; check-every-time monitoring false-alarms on up to 57% of clean flows; the obvious way to combine two guarantees broke the promise ~10,000-fold.
And even for those who could build it: a certificate you issue to yourself is not a certificate. The auditor has to be external. Independence is what makes the receipt worth anything to your auditor, your insurer, your customer. A breathalyzer is “just” a sensor and a threshold; what the court trusts is the metrology: the calibration certificate, the traceability, the recalibration regime. That is what we are: metrology for AI decisions.
What counts as an error?
You decide. An error is an answer your own standard would have stopped: a wrong amount, an invented source, a promise you're not allowed to make, personal data in the wrong place.
During onboarding your reviewers' decisions become the ground truth; the definition is written in plain language, split into severity classes with separate caps, and versioned. Every receipt states which version applied.
And the line is clear: we never promise the AI is right about the world. We promise the share of violations of YOUR standard stays under the cap, provably, after the fact.
Do you replace our existing guardrails?
No. They stay; their scores become our inputs. We add the layer that turns measurements into held promises, decisions and receipts.
What happens when the model changes?
The system alarms, steps itself down and demands recalibration.[F3] Silent drift without ground truth is the meter's job: the same engine's insurance bridge, see For insurers & brokers.
What does it cost — and who is liable if the promise breaks?
A promise costs more than a score. That's the point. Price follows the risk level: the tighter the cap, the higher the price; the error-cap dial is the price list, confirmed across a twenty-fold span.[F2]
The receipts are included from day one, not a compliance add-on you buy later. The EU's dates (transparency duties from August 2026, full high-risk evidence duties by December 2027 at the latest[F8]) only mature their value: when the requirement lands, the record already exists.
Our liability is scoped like an auditor's: we answer for the method being correctly executed, monitored and receipted. The assumptions are machine-readable in every receipt. If our process fails, that is professional liability, insurable as it is for auditors and test institutes. If the world moves faster than the detection window, agreed remedies apply: recalibration and service credits (SLA logic, not unlimited damages). And the promise itself can be reinsured: the market that backs AI performance warranties already exists.[F9]
An error will eventually get through. Then what?
Yes: a 5% cap means up to 5 in 100 released cases may violate your standard. That is the deal: priced, chosen by you, and set tighter for the severity classes where errors hurt more.
What changes is what happens next: the receipt shows the decision was made correctly under the approved policy and cap; every confirmed error feeds the meter, so a promise that starts slipping is caught within a measured number of outcomes; and if our process itself failed, that is on us: professional liability, with agreed remedies.
Do we need labeled data?
For calibration, yes, but not a labeling project. During silent onboarding your reviewers' ordinary decisions become the ground truth: your normal review IS the labeling. In production, sparse feedback is enough: the meter is built for the reality where only 5–25% of cases ever get a confirmed outcome.
Which models and tools do you work with?
Any model you can call over an API (commercial or open, hosted or your own) and any guardrail or eval tool you already run: their scores become our inputs. The decision itself is a lightweight computation, orders of magnitude cheaper than the model call it governs; exact overhead is measured in your pilot.
Where does our data go?
The decision layer sits in your request path; the receipts are decision records (identifiers, hashes, policy version, cap) designed so a third party can verify the decision without seeing the content behind it, and without access to us. Deployment (your cloud, EU region, on-prem) is scoped in the pilot.
Why now?
Three clocks struck at once. The EU set its dates: transparency duties from August 2026, full high-risk evidence duties by December 2027 at the latest.[F8] Insurance arrived: specialist programs now write AI liability, and underwriting demands continuous evidence.[F9] And the review model broke: regulators themselves are moving from “review everything” to risk-based selection, because AI volume made full review unmanageable.[F1] Selection without a held error cap is guesswork. That is the product.
Question not answered?
We're happy to answer anything about the product, the math, or the company.