Methodology

How the evidence score is calculated.

Each requirement from the AdventHealth Product Engineer posting is matched against evidence-backed claims, skills, projects, education, language, and credential records. The score is a ranking aid for interview review, not an automatic credential assertion. The numeric weights are local policy for this run; the scoring dimensions are tied to the research basis below.

43

Requirement rows scored

72%

Strong threshold

50%

Supported threshold

244

Reviewable claims

Formula

Weighted evidence fit

Total score

The system scores candidate evidence for each requirement, keeps the strongest support, and assigns a status from that best score.

total = sum(component_score * component_weight)

Status rules

strong

Score is at least 72%.

supported

Score is at least 50% and below strong.

weak

Some evidence exists, but the best score is below 50%.

blocked

The graph should not claim it without verified evidence, usually credentials.

Weights

What moves the score

These values are read from the generated evidence-map artifact for this run.

Requirement and evidence overlap

Measures how directly the selected evidence text matches the language of the requirement.

Deterministic token overlap in this evidence map; BM25 is implemented in the broader ranking layer for lexical retrieval.
28%
Evidence strength

Rewards evidence that is source-backed and marked usable in the graph instead of loose wording.

Local provenance scoring over graph evidence levels.
26%
Source backing

Rewards claims tied to a concrete experience, project, education, language, or credential record.

Local graph-lineage rule inspired by evidence-first fact verification.
16%
Domain match

Rewards matched domain concepts when the requirement calls for a specific environment or specialty.

Deterministic taxonomy and normalized-skill matching.
10%
Inspectable public source

Rewards evidence with a public URL such as a project page, GitHub artifact, or public demo.

Local provenance bonus for inspectable public artifacts.
10%
Curated claim

Rewards evidence that has been promoted from raw facts into a reviewed claim record.

Local claim-review policy; generated or raw facts do not get the same trust as reviewed claims.
6%
Deterministic match

Rewards direct structured matches such as explicit education, language, or credential facts.

Exact structured-field matching for fields that should not be inferred from work claims.
4%

Research Basis

Algorithms and papers behind the rubric

The papers justify the retrieval, similarity, diversity, and evidence-support methods. They do not set the local weights.

Semantic similarity

Sentence embeddings with cosine similarity

The code has an embedding-provider boundary, but this artifact uses the deterministic fallback rather than a live embedding model.

Domain matchFuture semantic provider
Reimers and Gurevych, Sentence-BERT, 2019

Interpretation

How to read the score

Strong and supported rows are interview anchors: they identify claims worth discussing first.

Weak rows are honest edges: they may be true, but the graph needs cleaner wording or better lineage.

Blocked rows are intentionally conservative and should not be presented as claims.

Limits

What the score does not prove

It does not replace a reference check, credential verification, or code review.

It does not expose private corporate files; sensitive evidence is summarized.

It ranks fit against this posting, so another posting can produce different scores.