Testing
AuraScore 89/100

SMT Symbolic Invariant Verification Script Synthesizer

Author automated SMT-LIB and Z3 verification scripts to formally prove computational boundary logic and algorithm soundness.

Use this template when validating complex analytical logic, rule engines, or deterministic decision pipelines. It produces production-ready formal verification scripts that prove correctness or identify exact algebraic counterexamples.

Template

Role: Principal Formal Methods and Automated Reasoning Engineer specializing in SMT-based algorithmic verification.

Context

  • Formal Specification and Logic Model: {{formal_specification}}
  • SMT Solver Framework: {{logic_solver_backend}}
  • Axiomatic Domain Assumptions: {{axiomatic_assumptions}}
  • Core Invariants to Prove: {{invariant_properties}}
  • Solver Execution Timeout: {{timeout_budget_seconds}}
  • Counterexample Output Format: {{counterexample_export_format}}

Task

Generate a complete, reproducible formal verification script using {{logic_solver_backend}} that mathematically checks the correctness of {{formal_specification}}, asserts {{axiomatic_assumptions}}, and proves or refutes {{invariant_properties}}.

Method

  1. Translate the symbolic variables and system states from {{formal_specification}} into strongly typed solver variables and sort definitions.
  2. Encode the operational transition relations and analytical constraints representing the system's execution logic.
  3. Implement {{axiomatic_assumptions}} as unassailable solver assertions restricting the search space to sound domain premises.
  4. Negate {{invariant_properties}} to construct satisfiability checks that isolate valid counterexample models.
  5. Configure solver execution parameters, tactic pipelines, logic theories (e.g., QF_NRA, QF_LIA, or QF_BV), and apply the timeout of {{timeout_budget_seconds}}.
  6. Program automated check-sat queries with model-evaluation parsing to extract structured failure witnesses according to {{counterexample_export_format}}.
  7. Implement vacuity sanity checks by ensuring the underlying premises remain satisfiable before proving theorem safety.

Constraints

  • MUST generate fully executable code targeting {{logic_solver_backend}} without incomplete assertion stubs.
  • MUST assert negated safety properties to demonstrate UNSAT results for valid theorems.
  • MUST NOT omit vacuity assertions that check whether antecedent assumptions contradict each other.
  • Provide explicit mathematical comments detailing the formal logic theory selected.

Output format

Structure the formal verification script strictly into these numbered blocks:

  1. Environment Initialization and Solver Logic Configuration
  2. Symbolic State Sorts and Constant Declarations
  3. Axioms and System Transition Constraints
  4. Vacuity Verification Assertions
  5. Theorem Invariant Assertions and Proof Solvers
  6. Counterexample Model Parser and {{counterexample_export_format}} Formatter

Self-review

  • Confirm that every property in {{invariant_properties}} has an explicit negated theorem assertion.
  • Verify that the logic theory selected in {{logic_solver_backend}} accurately matches the analytical types in {{formal_specification}}.
  • Ensure the counterexample handler serializes output strictly to {{counterexample_export_format}}.
AuraScore breakdown
89/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification14/14 · Strong

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-testing
complex-reasoning-analysis-math
smt-solver
formal-verification
z3