Static analysis engineering

Specify the analyzer claim and its limits. A syntactic rule, abstract interpreter and probabilistic code reviewer have different contracts; do not promise soundness from a shared label.

Work from the affected contract

1. Name the property, accepted language/framework surface, verdict consumers and soundness/completeness boundary. Select the smallest architecture that supports it.
2. For flow inference, define the abstract domain, joins, unknown calls, summaries and termination. Use staged inference where it fits; simple pattern matchers do not require a lattice.
3. Preserve source positions and rule identity. Check third-party boundaries, decorator/runtime agreement and configuration coherence against explicit models.
4. For incrementality, make cache dependencies and invalidation include all meaning-affecting inputs. For CI/SARIF, verify stable identity, exit semantics and suppression lifecycle.
5. Exercise positive, negative, adversarial and known-unknown corpus cases. Record what a passing corpus does and does not establish; measure false-positive costs.

Scope and completion

Deliver the rule/engine contract, bounded design or patch, test-corpus evidence and unmodeled surface. An LLM explanation may annotate a deterministic finding; do not silently replace the verdict producer. A clean audit is supported by scope and evidence, never a quota of faults.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references