Forall

The deciding trait is that your language decides how much of this product you get. TypeScript reaches every rung on offer. Rust, Java and C get as far as proofs. Python stops at contracts, which is useful and is not what the front page put in your head.

So the recommendation is conditional in a way that most are not. Check your language first, then decide whether the ceremony buys anything on the code you actually write. Pick it if the answer is yes and you already care about correctness. Skip it if you were shopping for speed.

The circularity is the failure mode. A proof establishes that an implementation satisfies a specification, and it says nothing whatever about whether the specification was the one you wanted. When both come out of the same session, a green mark can mean the tool was consistently wrong rather than right.

Nothing documented describes how a human reviews that specification before a proof gets built on top of it, and that review is the load-bearing step. What it does right is grading each requirement separately rather than the change as a whole, so a weak spot stays visible instead of averaged away.

1. Most tools collapse verification into a boolean, losing the distinction between a test that ran and a property that holds. Naming four levels and reporting the highest one reached keeps that distinction where a reader can see it. 2. The levels are ordered by strength, and the ordering is defensible rather than arbitrary.

2. What is absent is any measurement of how often the top level is reached in practice. A scheme capable of reporting the strongest grade is not a scheme that usually does, and the distance between those two facts is the only number that would matter. It is not published anywhere.

The business model is legible even where the pricing is not. An open repository draws developers, the binary requires an account, and the account is where a number eventually appears. That is a reasonable design, and it means the published licence tells you nothing about what this costs next year.

Moat: verification tooling is genuinely hard to build, which is a better defence than most products on this board have. Likely acquirer is a static-analysis or developer-security vendor that wants the proof engine and not the chat around it. Position: worth a trial, and get the price in writing first.

The identity story runs backwards. Every seat signs in through a browser to a vendor account, which is sixty individual identities I did not create, cannot revoke centrally and cannot see. No directory integration or provisioning is documented, so offboarding an engineer becomes a spreadsheet somebody forgets.

Platform coverage rules out part of my organisation before we begin, and nothing here executes as a delivery step, so I cannot pilot it as a gate on the pull requests where it would earn its keep. Not yet. Bring me single sign-on and a headless mode and this becomes an interesting conversation.

The verify-only mode is the interesting shape. Rather than making me switch agents, it publishes a server my existing one calls as a tool, configured with a small block of JSON I keep in version control alongside everything else. That is the right way to ship a capability: as something other software can call.

The licence on the code is permissive and my own provider key is accepted, so the choice of model is not taken away from me. Grudging respect: I would rather the whole thing were a library, and a verifier I can point another agent at is closer than most vendors get.