The green zone

The green zone is Guard’s operating outcome: current project health is strong enough that people and coding agents can continue building without knowingly stacking new work on top of the most important unresolved risks.

What the green zone means

Green describes current evidence, not a permanent certificate. The repository changes, dependencies age, tests drift, infrastructure evolves, and new features create new attack and failure surfaces. A project can enter the green zone and later leave it when a relevant audit finds new evidence.

The outcome is maintained at project level while evidence remains repository- and audit-specific. A project can have a healthy dependency result and a weak test-quality result at the same time. Guard keeps those areas visible so an overall impression does not erase a concrete red or yellow audit.

The practical benefit is not the badge itself. Coding agents inherit a healthier foundation: clearer context, stronger checks, fewer known vulnerabilities, and less unresolved structural debt competing with the feature they were asked to build.

How a project moves toward green

Guard uses a recurring loop:

1. Map the current project. Base diagnostics records repository identity, revision, structure, and representative context.
2. Run focused audits. Each audit answers one health question from repository evidence and records its own score, findings, and limitations.
3. Choose the next risk. A person reads the evidence and decides which bounded improvement is worth attempting.
4. Prepare a change. When a supported improvement applies, Guard can create an issue and may prepare a verified pull request or merge request.
5. Keep human control. A reviewer accepts, edits, or rejects the proposal. Guard never treats opening a review request as permission to merge it.
6. Rerun the affected audit. The new run checks the merged repository revision and establishes whether evidence actually improved.
7. Repeat after the code changes. Schedules and new revisions keep health from becoming a forgotten point-in-time report.

Reports, issues, comments, and review requests are artifacts inside this loop. They explain or deliver work; they are not the final product outcome.

How scores relate to green

Guard uses a shared visual scale for audit scores:

• 70-100 is green;
• 40-69 is yellow;
• 0-39 is red.

That color is a compact status for one audit result. The formula behind the number remains audit-specific. Criteria, severity reductions, score caps, confidence, skipped tools, and missing evidence can change what a score means.

Project cards may surface a subset of audit scores for quick orientation. Always open the audit report before deciding that a green number closes a risk. A green score with a stated limitation is more honest—and more useful—than an unsupported perfect score.

What green does not promise

The green zone does not prove that software contains no defects, vulnerabilities, dead code, operational gaps, or undocumented behavior. It does not replace production monitoring, incident response, threat modeling, manual review, or domain-specific testing.

Green means the current published audits produced healthy results within their declared scope and evidence. Unknown or inaccessible surfaces remain limitations. A website also needs separate active-testing authorization; repository health cannot establish the security of every live route.

Read Audits, scores, and evidence for the interpretation rules that keep the outcome honest.

Why recurrence matters

Fast agent-driven development increases the rate at which project assumptions can become stale. A new dependency, untested branch, generated configuration, or CI change can undo earlier health without obvious breakage.

Recurring audits check eligible new repository state. When a project leaves green, Guard can help focus the next improvement; after human review and merge, the next audit determines whether the project returned to a healthier state.