Audits overview

What an audit answers

An audit answers one bounded health question about one repository revision. Security asks whether the checked code and configuration expose concrete security risk. Test quality asks whether the test suite proves useful behavior. Configuration hygiene asks whether declared options are understandable, wired, and safe to operate. Each audit has its own evidence rules and scoring model, so two identical scores do not mean that the underlying work is identical.

Audits are different from base diagnostics and recon. Diagnostics establish that Guard can access and inspect the repository. Recon maps the repository so later work starts with useful context. Neither is a substitute for a scored audit.

The revision boundary

Every result belongs to the repository and commit that Guard checked. The branch may move while an audit is running, but the evidence remains tied to the captured revision. Read the target repository, branch, and commit before comparing a finding with the code you have open locally.

A newer commit does not silently rewrite an old result. Run the audit again when you need a current assessment. This makes history auditable: a score change can be interpreted alongside the actual code change instead of being a floating statement about the repository.

How Guard collects evidence

Audit runbooks define what Guard may inspect, which tools are useful, and what must remain out of scope. Guard starts with repository evidence such as source files, manifests, lockfiles, tests, configuration, documentation, and delivery workflows. An audit may use bounded read-only tooling when it adds reliable evidence. If a tool is unavailable or a surface cannot be inspected, the result records that limitation instead of filling the gap with a guess.

Repository audits are read-only. They can save report artifacts inside Guard, but they do not change the audited repository. Any later change belongs to a separate improvement workflow with its own write and review boundary.

From evidence to a score

The report should answer the main audit question before presenting a scorecard. Criteria describe the dimensions that were evaluated. Findings identify concrete problems or risks and cite representative evidence. Limitations explain what could not be established. Some audits also use deductions or evidence-backed score caps so a severe fact cannot be hidden by strong performance elsewhere.

Guard uses a shared visual interpretation for the final 0–100 score:

Score	Zone	Meaning
70–100	Green	Evidence is generally healthy, although findings can still require attention.
40–69	Yellow	Material gaps or uncertainty should be addressed.
0–39	Red	Severe, systemic, or blocking evidence controls the result.

The thresholds are shared; the formula is not. Open the audit-specific page or report before deciding what action the number warrants.

Results, history, and next actions

The repository dashboard keeps each audit metric in its own context. From a metric you can open the latest details, inspect recent history, request a rerun, configure recurring checks, or start an eligible Autofix flow. These actions keep the selected repository and audit attached to the next step.

History is most useful when you compare the checked commits and the evidence behind the scores. A higher score may reflect a real improvement, different available evidence, or a runbook change. Treat the report as the explanation and the score as the compact signal.

Choose the next page

• Use Open actions from an audit score to work from one dashboard metric.
• Use Configure recurring audits to keep an active repository checked over time.
• Open an audit in the catalog to understand its exact criteria, caps, and limitations.
• Use Improvements overview when a finding is ready for bounded remediation.