A number without a source is a guess wearing a costume. Here is the plumbing underneath every ScoringFactory score, and why we built it before we built almost anything else.
Every scoring product eventually gets asked the same question: where did that number come from? Most of them do not have a good answer, because the answer is "a model looked at some inputs and produced an output." That is not evidence. That is a guess with more decimal places.
An opinion with a number attached
A score by itself is a claim, not a fact. If I tell a partner a founder rates a 7.4 on technical depth, I have told them nothing they can act on unless I can also tell them what earned the 7.4. Otherwise the number is just my opinion, laundered through enough math to look objective. That is the trap most AI scoring tools fall into, and it is the reason so many of them get quietly ignored the first time someone with real judgment pushes back on a result.
This is not a niche worry anymore. Grant Thornton's 2026 AI Impact Survey found that 78 percent of business executives lack strong confidence they could pass an independent AI governance audit within 90 days. That gap exists because most organizations built the scoring first and the evidence trail never got attached at all. We built ScoringFactory in the opposite order.
A score you can't trace is an opinion wearing a costume.
One point, one pointer
Our rubric is not a set of prompts that ask a model to guess a number. It is a set of discrete, named criteria, and every criterion has a required field we call the evidence pointer. Before the model is allowed to assign a point value, it has to resolve that pointer to something concrete: a commit hash and diff line, a specific paragraph in a due diligence memo, a timestamped moment in a reference call transcript, a row in an applicant's work history. If the pointer does not resolve, the point does not get assigned. No exceptions, no "the model was pretty sure."
The harder engineering problem turned out to be permanence. GitHub commits get rebased. Google Docs get edited after the fact. Slack threads get deleted when someone leaves a workspace. So every evidence pointer is paired with an immutable snapshot taken at scoring time, stored separately from the live source. Six months later, when someone reopens a score, they are looking at exactly what the model looked at, not whatever that document has since become.
In the product, every score is clickable down to that snapshot. Click the 7.4 and you land on the actual diff, the actual quote, the actual row. This is what we mean when we talk about evidence-based scoring: not a nicer word for AI scoring, but a hard constraint on what the system is allowed to output at all.
The moment it has to hold up
The real test is not a demo. It is a partner meeting, three weeks later, where someone who was not in the room for the original scoring session looks at a number and says "why an 8 and not a 6." If the answer requires re-litigating a vibe, you have already lost the room. If the answer is one click to the exact evidence, the conversation moves to whether the evidence itself was fairly weighted, which is a much better argument to be having. This is the whole point of auditability: it does not make the score correct, it makes the score defensible, and it moves disagreements to the place where they actually belong.
We wrote about the flip side of this in same bar, every partner: killing score drift. A traceable score is also how you catch two partners quietly grading the same criterion differently. You cannot fix drift you cannot see, and you cannot see it without a record of what each score was actually built on.
This is showing up outside VC too. Recent reporting on explainable match scores in hiring makes the same point from the candidate side: an applicant who gets rejected by an opaque score has no way to contest it, and a hiring team that cannot show its work has no way to defend it if challenged. The mechanics are the same whether you are scoring a founder, a candidate, or a portfolio company. A number without a source satisfies nobody once it is questioned.
What this ruled out early
Committing to this early cut off some product paths that would have shipped faster. We could not let the model write a persuasive rationale after the fact and call that evidence, a pattern we caught in our own prototypes in the first month, where the model would generate a fluent paragraph justifying a score it had actually produced from something else entirely. So we flipped the order: evidence retrieval happens first, scoring happens second, and the score is a function of the evidence that was actually found, not a number the model reverse engineers a story for. It is slower per score. It is also the only version of this we would put our name on.
It also meant we could not score anything without a retrievable source in the first place. No source, no score, even when a partner really wants a number today. That constraint is annoying in the moment and it is the reason the numbers hold up three weeks later, which is the only time it actually matters.