I watched a synthetic SystemVerilog assertion board arrive 8/8 PROVEN and leave the same audit with only 5/8 proofs I would certify for review. That reversal is the reason I built Proof Firewall: when AI can help author assertions, a green result needs inspection before it becomes tape-out evidence.
I am not saying this synthetic board resembles a customer design, and the result is not a commercial-engine comparison. I built it to make one uncomfortable fact visible: an implication can be proven while its antecedent never fires, and a property can survive a broken design because it says almost nothing.
The green board that changed what I meant by PROVEN
I began with eight fixture-authored “LLM-authored” SVA properties across a synthetic arbiter, a two-stage pipeline, and a CDC crossing. In the bare-flow view, every one was green. I remember seeing 8/8 PROVEN and realizing that the display had answered a narrower question than a sign-off review needs answered.
I wanted the next step to be mechanical rather than a second model giving an opinion about the first model's work. So I made the gate check whether an antecedent is reachable, whether a property kills relevant single-point mutations, and whether it has a meaningful cone of influence (COI). The explicit-state model checker evaluates the finite synthetic transition-system IR; the demo also labels its bounded-depth fallback as bounded.
I chose these checks because each one tests a different way a reassuring proof can fail to provide usable evidence. The policy then routes the outcome to TRUSTWORTHY, VACUOUS, WEAK, DEAD, BOUNDED-PROVEN, or VIOLATED, with a reason rather than a second shade of green.
I took that standard seriously because the cost of accepting green at face value is not abstract. The 2024 Wilson Research Group / Siemens EDA study, cited in the demo specification, reported 14% first-silicon success. That is market context, not a Veriprajna measurement, but it is enough to make a defensible proof package worth designing for.

Proof Firewall's audit screen compares the synthetic 8/8 bare-flow result with the 5/8 TRUSTWORTHY result and shows the properties withheld by the governance gate.
The arbiter line I could not defend
I stopped treating ARB3 as a harmless edge case when I read the assertion in the synthetic arbiter: assert (g0 && g1) |-> (turn == 0). The implication carried a green result, but g0 && g1 is unreachable in that fixture. Nothing in a sign-off folder should gain credibility from a condition the design cannot enter.
I made that moment visible in the board because it changed the review question for me. Instead of asking only whether the engine returned PROVEN, I ask whether the proof constrains a reachable behavior. ARB3 is therefore marked VACUOUS, and the gate withholds its signed demonstration certificate.
I find this more useful than pretending the green label is wrong. The formal result is doing what the assertion permits. The governance layer is asking whether that assertion is evidence worth filing.

In the arbiter view, ARB3 is shown as VACUOUS; the displayed condition g0 && g1 is unreachable in the synthetic fixture.
The pipeline assertion that survived its own test
I had a different reaction to PIPE3 because its failure was more familiar: assert v2 |-> (s2 == s2) looks like an assertion, yet its consequent is tautological. I ran relevant injected mutations against the synthetic pipeline case and watched the property record a 0/6 mutation-kill result. It survived the variants that should have made a meaningful property fail.
I did not want the audit to merely label that result "weak" and leave the reviewer guessing. The screen records the mutation outcome and the property is routed to WEAK, which makes the reason inspectable. That matters when an optional SVA author is allowed to propose a property but must not get to decide the proof's filing status.
I kept the mechanism deterministic because this boundary needs repeatable behavior. Agents advise, code decides. A reviewer can rerun the same synthetic input and see the same reachability, mutation, COI, and policy results.

The pipeline panel identifies PIPE3 as WEAK and shows the tautological consequent that fails the synthetic mutation check.
The evidence boundary I wanted before a proof reached review
I designed the final boundary around a simple operational consequence: a proof that is vacuous, weak, dead, bounded-only, or violated should not be dressed up as a clean sign-off artifact. Only a TRUSTWORTHY result receives the signed demonstration certificate. The export includes per-property verdicts, reachability, mutation results, COI, counterexample records when present, and a SHA-256 field.
I also included the strengthened synthetic CDC property because it makes abstention concrete. The weak CDC assertion is WEAK; strengthening it to require req on the next cycle produces a VIOLATED result and a counterexample waveform for the synthetic lost-transaction / CDC failure class. That is not evidence about a real chip. It is a reminder that a requirement can become meaningful only when the design is given a chance to contradict it.

The CDC panel records a VIOLATED strengthened property and renders its synthetic counterexample waveform.
I made the runnable Proof Firewall demo so the board, checks, and certificate can be inspected rather than taken on my word. Its local labeled synthetic benchmark reports 18/18 classification agreement and six proofs that its own ungated bare-flow baseline would have rubber-stamped. Those are fixed demo results, not production or open-world claims.
I keep coming back to the first screen: 8/8 PROVEN was a real result, and it was still insufficient evidence for three properties. A green word on a dashboard should never be the final witness in a tape-out review.