A proving ground, not a guarantee.
The product reports whether a deployment is safe to ship under the conditions it could observe and reproduce. It does not mathematically guarantee that a deployment cannot fail.
Evidence, with its limits stated. You remain responsible for the permissions you grant.
| The promise | Reproduce the highest-risk production conditions we can observe, measure how the proposed system behaves, and expose dangerous differences with concrete evidence. |
|---|---|
| Your cloud | You remain responsible for the cloud permissions you grant the agent, the policies you approve, and the production systems those permissions can reach. |
| Accounts | Anybody can create one. Signing in with GitHub creates an organization on the free plan, owned by that account, and installing the GitHub App creates or adopts one the same way. The free plan's limits are enforced against it: reaching one refuses the next creation and tears nothing down. |
| Paying | A paid plan is bought through Stripe's own hosted checkout and managed in Stripe's customer portal. No card ever reaches this product. These terms are not a paid-service agreement: the contracting entity, the governing law and the liability cap are all still blank below, and a contract with no party to it is not one. A purchase is governed by whatever is agreed in writing at the time. |
| The enterprise edition | The source under ee/ is public to read and audit. Running it in production requires a written agreement with Antifailure and a valid licence, which is arranged through the contact form. Its licence used to accept this page as that agreement; it no longer names it, because this page says it is not one. |
| Availability | Nothing here is a service level commitment. There is none, and the reasons are set out on the service levels page rather than left for a customer to discover. |
What these terms do not say.
- Zero rollback. No deployment can ever fail.
- Perfect clones of every cloud topology.
- Open source as a substitute for compliance.
- A generally available production control plane.
What the software is allowed to touch, and what decides that.
The honest version of a liability section starts here rather than at a cap, because what the software can reach is a fact about the code and a cap is a guess about a court. Each row below is a limit the engine enforces, not a promise it intends to keep.
| Your production database | Named by the variable in source_url_env and read, never written. The golden refresh reaches it only through pg_dump, and the subsetting path opens it inside a transaction Postgres has marked read only, so a connection string with more rights than it needs still cannot be written through. |
|---|---|
| Your cloud permissions | You remain responsible for the credentials you give the agent and for everything those credentials can reach. Nothing here can narrow a permission you granted. |
| Containers and branches | Teardown removes only resources carrying Antifailure's own labels, and refuses anything else by name. A database branch is created and destroyed through the provider's API under a reserved prefix. |
| Masking | Runs on every golden. There is no setting that disables it, and a project with no rules file still gets the built-in set. A golden whose verification scan finds real data is never published, so it can never be branched. |
The limit worth stating next to that last row, because a reader would otherwise assume more than is true: the verification scan reads the column types that can hold a sentence, and samples rows rather than reading every row. It is a check that a masking rule missed a column entirely, which is the failure it is built for. It is not a proof that no personal data survives anywhere in a schema, and it is not offered as one.
The software is provided as it is. A pass is evidence, not insurance.
To the extent the law allows, the software is provided without warranty of any kind, express or implied, including any implied warranty of merchantability, fitness for a particular purpose, or non infringement. A run reports what it could observe and reproduce under the conditions it created. It does not certify that a deployment is correct, and a passing report is not a representation that production will not fail.
Some of that exclusion is unenforceable in some places, and against consumers it is unenforceable in most. Which parts survive where is a question for counsel and is marked as such below rather than asserted here.
The shape of the cap, with the numbers left out.
Four values decide this section and none of them exists yet, so they are left visibly blank rather than filled with something that reads as settled: the contracting entity entity name to be supplied, its registered address registered address to be supplied, the governing law and venue jurisdiction to be supplied, and the figure the cap is set at liability cap to be supplied. A cap written before a lawyer has chosen the jurisdiction it will be read in is a number, not a protection.
| Excluded, intended | Indirect, incidental, special and consequential loss, and loss of profit, revenue, goodwill or data, to the extent the law allows. |
|---|---|
| Capped, intended | Everything else, at a figure tied to what was paid over a stated period. Both the figure and the period are unset. |
| Never excluded | Death or personal injury caused by negligence, fraud and fraudulent misrepresentation, and anything else a governing law refuses to let a contract exclude. This carve out is not a courtesy and cannot be drafted away. |
| Not addressed here | Whether any of the above is enforceable against a given customer in a given place, which depends on the jurisdiction, on whether the customer is a business or a consumer, and on whether the harm was caused by our own negligence. |
When a hosted control plane is generally available, these pages will be replaced with dated legal documents that name a contracting entity and a governing law. The acceptable use policy and the developer policy are drafted already, because both describe what the software does rather than what a company has decided. Until then, treat every safety report as evidence about the conditions the run actually reproduced, a pass or a fail, not as insurance.
Know what happens before you deploy.
Create a disposable production twin for every risky change. Catch migration failures before they reach customers.