Audits, scores, and evidence

An audit answers one bounded health question about one repository revision. Its score is a summary of that audit’s current evidence—not a substitute for the evidence, criteria, and limitations that produced it.

Orientation and audits have different jobs

Base diagnostics and recon maps repository identity, structure, stack, and representative signals. It gives later work context and does not publish another score-bearing health area.

A published audit goes deeper on one question: for example, whether dependencies are controlled, tests provide reliable protection, CI/CD enforces a usable delivery path, or the repository is ready for coding agents. The audit runbook defines its evidence, criteria, scoring, caps, output, and non-goals.

Both kinds of result must identify the exact repository target and current revision. Neither should turn missing access into a successful result.

What an audit report contains

A completed audit can contain:

• the repository and audited commit;
• the question and scope of the audit;
• tools and repository evidence used;
• an integer score from 0 to 100, or an explicit non-scored outcome;
• a status summary and finding counts;
• audit-specific criterion scores;
• normalized, deduplicated findings with severity or confidence;
• score reductions, caps, and a plain-language calculation;
• skipped tools, exclusions, unknowns, and coverage limits;
• a previous completed result when comparison is supported;
• improvement candidates that remain separate from the audit run itself.

Not every audit uses every row or chart. The stable contract is explanatory: a reader should be able to see what was inspected, why the result has its current status, and what remains uncertain.

How to read a score

Guard uses a shared visual scale:

Score	Visual state	Interpretation
70-100	Green	Current evidence is healthy within the audit’s declared scope.
40-69	Yellow	Evidence is mixed, incomplete, or needs attention.
0-39	Red	Current evidence contains serious problems or is too weak for a healthy conclusion.

The color helps prioritize attention; it does not define the formula. Open the report and ask:

1. Which criteria earned or lost points?
2. Which findings reduced the score?
3. Did a critical condition or evidence gap cap the maximum?
4. Which tools or surfaces were unavailable?
5. Does the result describe the current commit?

A score can improve because code improved, evidence became available, or the audit contract changed. It can fall for the same reasons in reverse.

Criteria, caps, and unknowns

Criteria belong to the audit. Dependency hygiene, for example, scores evidence such as dependency inventory, reproducible installation, vulnerability posture, acquisition paths, lifecycle scripts, and evidence quality. It then applies separate reductions for confirmed risks and current control gaps before enforcing applicable caps.

Other audits use different criteria and arithmetic. Do not transfer a formula, severity weight, or cap from one audit to another.

A cap limits the final score when a healthy number would contradict important evidence. Examples include a critical finding, an unreproducible primary install path, or material scanner coverage gaps. The report should name the cap and the evidence that triggered it.

Unknown evidence is not a pass. Unsupported tooling, inaccessible private registries, incomplete history, a missing runtime surface, or ambiguous generated code belongs in limitations unless the runbook defines a specific evidence-quality penalty or cap. Low-confidence candidates should not be promoted into confirmed findings merely to make the score feel decisive.

Findings and improvements

A finding is a supported current-state problem or control gap. It should connect evidence to an understandable impact and a bounded recommendation.

The audit itself remains read-only. A finding can have:

• no automatic improvement because the required decision is architectural or unsafe to automate;
• an issue-only path that records work for a person;
• a supported improvement that can prepare a reviewable change after separate eligibility and verification checks.

Opening an issue or review request does not resolve the finding. A human must review and merge an acceptable change, then a new audit must evaluate the resulting revision. Read Autofix and human review for that boundary.

Compare runs carefully

Audit history is most useful when you know what changed between runs. Compare:

• repository and audited commit;
• audit or runbook version when visible;
• available tools and evidence surfaces;
• accepted risks and exclusions;
• scoring criteria and caps;
• completion state.

A score delta is orientation, not root-cause analysis. Open both reports when an unexpected change matters. Activity timeline helps locate the relevant runs, while the run reports explain why their outcomes differ.