How Phylax scores artifacts

Every verification returns the same shape whatever you asked about: a verdict to act on, a measure of how much analysis stood behind it, and the findings that explain it. This page describes what those fields mean so you can gate on them correctly.

The verdict

Verdict	Meaning	What to do
ALLOW	Nothing was found that warrants blocking	Proceed
WARN	Something deserves a look, but it is not disqualifying	Proceed, review when convenient
BLOCK	This should not ship	Stop

Anything unrecognised is treated as BLOCK, not as ALLOW. If a response is malformed, truncated or from a version that predates a verdict your client knows, the safe reading is refusal. Every Phylax client does this, and yours should too.

WARN does not fail a build by default

New findings land against dependencies you did not change. A pipeline that fails on every warning fails on quiet days and gets switched off, which leaves you with nothing. Start on the default and add --strict once your baseline is clean.

Coverage

Coverage tells you how much analysis is behind the verdict. It is not a confidence score, it is a statement about depth.

Coverage	Meaning
network	Analysed by the network, the deepest result available
cached	A previous network result for this exact artifact, still current
static	Screened, but not yet analysed in depth
none	Nothing is known about this artifact

none is the one to watch. It is not a clean bill of health, it means the question has not been answered. Treat an unknown dependency as unreviewed rather than as safe.

Risk score and bands

risk_score is a number, risk_band groups it into low, medium, high and critical. Bands are what policies should key on. The number can move as analysis improves without the band changing, so a rule written against a band is stable where a rule written against a threshold is not.

Findings

finding_counts summarises what was found by severity, and findings carries the detail when your plan includes it.

{
  "verdict": "WARN",
  "coverage": "network",
  "risk_band": "medium",
  "finding_counts": { "critical": 0, "high": 1, "medium": 2, "low": 4 }
}

Counting findings is not the same as reading the verdict. A single critical finding outranks a dozen low ones, and the verdict already accounts for that. Gate on verdict, and use counts to decide how urgently to look.

Cache and freshness

Results are content addressed, so the same artifact bytes resolve to the same record rather than being re-analysed on every request. last_evaluated_at tells you when the underlying analysis ran. When analysis changes, affected results stop being served from cache rather than going stale quietly.

What a verdict does not claim

ALLOW means nothing warranting a block was found within the analysis that ran. It is not a manual audit, not a guarantee, and not a statement about code paths that were never reached. It is a strong signal, and it is the reason attestations exist: they record what was known, when, so a later surprise can be traced rather than argued about.

Related

• Attestations for the signed record of a verdict
• The platform for how a verdict is produced
• Best practices for turning verdicts into policy