The Predicate Problem: Why Most Evaluation Questions Cannot Be Answered

The anatomy of a bad evaluation question

Consider the question: "Do you have a clear value proposition?" Every founder answers yes. The question is unanswerable because it cannot be falsified. No evidence could count against it — the founder decides whether their own proposition is clear, and they always decide yes.

This is the predicate problem. It affects every evaluation framework that generates questions from general principles rather than from specific, observable behaviors. The question sounds rigorous. It produces no signal.

Bayescore's predicates are designed to be answerable in a specific way: they require observable evidence, not self-assessment. The difference is not stylistic. It determines whether the evaluation produces information or merely confirmation.

What makes a predicate answerable

An answerable predicate has three properties:

1. Specificity. It refers to a concrete, observable behavior — not a general quality. "Has the founder spoken with five target customers?" is specific. "Does the founder understand their customers?" is not.
2. Falsifiability. There must be evidence that would count against it. "Is there a measurable demand signal?" fails when there is no waitlist, no pre-order, and no letter of intent. A question that cannot fail cannot pass.
3. Independence from the evaluator's belief. The answer must not depend on whether the founder believes it is true. The evidence either exists in the document or it does not.

Every predicate in Bayescore is designed to fail when evidence is absent. This is not pessimism — it is information. A predicate that consistently passes provides no information. A predicate that fails tells you exactly where to look.

The Bayescore approach to predicate design

Each predicate in Bayescore's domain definitions is written as a specific question about an observable state, weighted by its empirical leverage on outcomes. "Customer validation" carries 18% weight — the highest single weight in the self-evaluation domain — because customer discovery is the most consistently under-evidenced area in early-stage evaluation: founders who have spoken to real potential customers produce documents with qualitatively different specificity than those who have not.

The weight is not a preference. It is a calibrated estimate of how much variance in outcome this single factor explains.

When you define a custom domain in Bayescore, the same principle applies. The DNA extraction feature helps structure your predicates around answerable questions — but the quality of the evaluation depends on the quality of the questions. A vague predicate returns a vague answer. A specific, falsifiable predicate returns evidence.

Writing predicates that work

The fastest way to test whether a predicate is answerable: try to think of a document that would fail it. If you cannot imagine what failure looks like, the predicate is not specific enough.

"Does the team have relevant experience?" fails this test — there is always some way to interpret experience as relevant. "Has any team member previously worked at a company in this industry for more than two years?" passes the test — a team of first-time founders in a new domain fails it immediately.

The goal is not to make predicates hard to pass. The goal is to make them informative. A predicate that is easy to pass with genuine evidence and impossible to pass without it is doing its job.