Architecture Finding Verifier

Verify architecture findings

Act as a skeptical second pass. The objective is not to defend the audit; it is to determine which claims survive direct inspection.

Load the contract

Read these files completely:

• ../../resources/references/review-contract.md;
• ../../resources/references/evidence-provider-contract.md.

Load the candidate review and the repository Profile, constraints, policy, and configured Evidence Providers when present. For Review 1.2, also load and verify the bound repository-facts and knowledge-selection artifacts before inspecting any conclusion.

Verification procedure

1. Record the candidate review ID, reviewed commit, current commit, scope, and evidence freshness. Generate repository, Profile, Rule Pack, candidate, and Finding bindings:

   python3 ../../resources/scripts/architecture_tool.py review-bindings \
     --project <repo> --candidate <candidate-review.yaml>
   

2. If the code has moved, relocate evidence by symbol and history. Mark the finding needs-evidence when it cannot be tied to current code.

3. For every candidate, read the cited source and the smallest sufficient set of callers, callees, schemas, tests, configuration, history, or runtime evidence.

4. State the claimed invariant and attempt the strongest counter-hypothesis.

5. Confirm that the evidence proves an architecture relationship or failure mode rather than a stylistic preference.

6. Check the owning boundary, affected components, severity, confidence, and rule ID. Recompute the evidence fingerprint and preserve the candidate's facts, inferences, unknowns, applicability, Rule Pack version, and selected Knowledge bindings unless new evidence explicitly changes them.

7. Merge genuine duplicates while retaining all original IDs and contributing reviewers.

8. Assign the honest verification level:

   • V0: same-run self-check;
   • V1: fresh context with the same model;
   • V2: different model or independent agent;
   • V3: human review;
   • V4: human review plus deterministic evidence;
   • V5: controlled, signed approval and audit chain. V3–V5 require a human verifier. V4–V5 require a passed deterministic Evidence Provider run. V5 additionally requires a detached SSH signature whose identity is authorized by project policy.

9. Set exactly one status:

   • confirmed: direct evidence supports the claim and impact;
   • rejected: evidence contradicts the claim or shows an intentional, safe pattern;
   • needs-evidence: the claim remains plausible but cannot be proved.

Do not use cross-reviewer agreement as proof; treat it only as a reason to inspect more carefully.

Mandatory false-positive checks

Reject or downgrade claims supported only by:

• line count, file count, import count, fan-out, or cyclomatic complexity;
• names such as utils, manager, service, or singleton;
• use of SQLite, PostgreSQL, Redis, Neo4j, a global instance, or a framework;
• theoretical scale, security, or availability requirements absent from the profile;
• a document that contradicts current executable behavior;
• a missing pattern that is not applicable to the system.

Metrics and conventions may locate evidence, but cannot be the evidence.

Output

Never overwrite the candidate artifact. Write:

• .architecture/reviews/<timestamp>-<kind>-verified.yaml and .architecture/reviews/<timestamp>-<kind>-report.md, or
• .architecture-portfolio/reviews/<timestamp>-portfolio-verified.yaml and .architecture-portfolio/reviews/<timestamp>-portfolio-report.md.

Retain rejected and needs-evidence items in YAML, but include only confirmed risks and strengths in the human report. Record the verification rationale, level, structured verifier identity, run ID, time, candidate hash, and calculated Finding fingerprint for every verified item. Set coverage_complete: true only after every loaded Rule Pack rule appears exactly once and every declared critical flow is assessed or explicitly not-applicable. A verified 1.2 Review may not leave a critical flow not_assessed.

Preserve the source review structure defined by ../../resources/templates/review.yaml or ../../resources/templates/portfolio-review.yaml.

Validate the result:

python3 ../../resources/scripts/architecture_tool.py validate-review \
  <verified-review.yaml> --project <repo>
python3 ../../resources/scripts/architecture_tool.py validate-coverage \
  --project <repo> --review <verified-review.yaml>
python3 ../../resources/scripts/architecture_tool.py verify-evidence \
  --repo <repo> --review <verified-review.yaml>
python3 ../../resources/scripts/architecture_tool.py verify-review-signature \
  --project <repo> --review <verified-review.yaml>

Run the signature command when policy or verification level requires it. Respect policy role separation: an unauthorized or overlapping verifier cannot be repaired by changing the artifact identity. Do not propose remediation or modify product code.