What Is Evaluation DNA?

The observation

Before you write a grant proposal, there exists a set of questions that reviewers will ask: Is the problem significant? Is the approach feasible? Does the team have the expertise to execute? Is the budget justified? These questions are not invented by the reviewers. They are implied by the form. A grant proposal, as a class of document, already implies its own evaluation criteria.

The same is true for every structured document that is trying to make a case. A pitch deck implies IS(startup, fundable). A product README implies IS(project, adoptable). A hiring cover letter implies IS(candidate, hireable). A research paper implies IS(study, publication_ready). The document genre contains the evaluation structure. It was always there.

Evaluation DNA is the name for that structure — made explicit. Not invented. Extracted.

What extraction produces

When Bayescore extracts evaluation DNA from a document, it produces three things:

1. A root hypothesis in IS notation. The single falsifiable question the evaluation answers: IS(subject, criterion). For a startup pitch, this is IS(pitch, fundable). For a grant application, IS(application, approved). For a product spec, IS(spec, shippable). IS(subject, criterion) is Bayescore's own evaluation primitive — a binary node at the root of a weighted evidence graph, structurally informed by Pearl's Bayesian network theory (1988) but expressed in Bayescore's notation.
2. A set of predicates. Each predicate is a specific, observable question that bears on the root hypothesis. "Has the founder spoken with five or more target customers?" is a predicate. "Is there a measurable demand signal — a waitlist, pre-order, or letter of intent?" is a predicate. They are binary: the evidence is present in the document, or it is not.
3. Weights. Each predicate carries a weight that reflects its empirical importance to the root hypothesis. The weights sum to 1. A predicate carrying 18% weight moves the score three times more than one carrying 6% weight. The weights are not opinions — they are calibrated estimates of how much variance in outcomes that single factor explains.

Why temperature 0

Every pass in a Bayescore evaluation — extraction, supportive review, adversarial review — runs at temperature 0. This is a non-negotiable design constraint, not a tunable parameter. The goal is deterministic pattern recognition: the same document class must produce the same evaluation structure on every run. Any sampling variance introduced by a non-zero temperature would make scores non-repeatable and the formula meaningless.

A pitch deck belongs to a class of documents — pitches — that shares a stable evaluation structure: problem, solution, market, traction, team, ask. DNA extraction identifies which class the artifact belongs to and extracts that class's stable predicate pattern. Temperature 0 ensures this identification is consistent across runs, across users, and across time.

The practical consequence: a domain extracted from one grant proposal works reliably on all grant proposals of the same type. The individual document instantiates the class. The class defines the predicate structure. Once extracted, the domain is reusable without re-extraction.

The document is both source and subject

The most important property of evaluation DNA extraction is this: the document being scored is also the source of the evaluation criteria. There is no external rubric, no predefined template, no evaluator who brings their own framework. The criteria emerge from the artifact itself.

This means the evaluation cannot be gamed by choosing a favorable framework. The criteria are implied by the document's own structure. A pitch deck that omits customer discovery cannot escape the customer_validation predicate — because customer validation is what pitch decks are supposed to address. The document's own genre creates the obligation.

It also means the DNA generalizes. Drop any structured artifact — not just startups, not just grants — and Bayescore reads the evaluation structure that artifact already implies. The method is domain-general. The extraction is domain-specific. Both at once.

Reviewing the extracted DNA

Extraction is a strong first draft, not a finished artifact. Before saving a domain, review each predicate and ask: can I imagine a document that would fail this? If you cannot think of a failing case, the predicate is too vague to be useful. "Has the team demonstrated relevant expertise?" fails this test — some expertise is always interpretable as relevant. "Has any team member previously led a product in this specific vertical?" passes it — a first-time founder in a new vertical fails immediately.

For high-stakes evaluations — hiring pipelines, grant review cycles, product launch checklists — treat the extraction as a starting point and adjust predicate wording where the specificity is insufficient. The quality of the evaluation depends on the quality of the predicates, and the quality of the predicates depends on the quality of the specificity check.