The terms under which we would process data on your behalf.
A draft, published before there is anything to sign, so that a security review can read it now and tell us where it is wrong. Its subprocessor annex is a separate page because that is the part that goes stale.
Who is agreeing, and under which law.
| Processor | Antifailure, trading as the legal entity named on the signed copy. |
|---|---|
| Controller | The customer organization named on the order form. |
| Governing law | Not yet chosen. A jurisdiction stated here before it is decided would be a guess in a contract. |
| Contact for data protection | No address at antifailure.dev can receive mail: the domain publishes no mail exchanger. Security reports go through GitHub private vulnerability reporting, and the contact page lists the routes that resolve today. A privacy address will be published with the signed copy. |
Four values are missing because no part of this product knows them: the registered entity entity name to be supplied, its address registered address to be supplied, the governing law and venue jurisdiction to be supplied, and the privacy contact address privacy contact to be supplied. They are left visibly blank rather than filled with a plausible default, because a plausible default in a contract is the kind of error nobody catches on a second reading.
Who controls what. Not everything here is yours, and saying so is part of the agreement.
| You control, we process | Account records, organization and repository metadata, policy configuration, run events, and audit entries for your organization. We act only on your instructions, which are the product's own documented operations. |
|---|---|
| You control, we never receive | Production snapshots, secrets, captured request bodies before redaction, and raw logs from the twin. These stay inside your cloud by architecture, not by a promise in this document. |
| We control | The account and session records signing in creates, what somebody leaves on the contact form, and our own operational records about running the service. |
| Purpose limitation | The data is used to run the service, to keep it secure, and to bill for it if there is ever billing. It is not used to train any model, and no path in this product sends it anywhere that would. |
The measures that exist, described as what the code does rather than as a category.
| Tenant isolation | Every tenant table carries a row-level security policy keyed on the organization, enforced by the database rather than by a query the application has to remember to filter. The event partitions carry the policy too, so naming one directly is isolated by the same rule. |
|---|---|
| Least privilege in the database | The application role cannot run DDL. Partition maintenance runs as a separate migration role on a connection opened for the pass and closed after it, because a role that can alter a table can drop the policies that isolate tenants. |
| Secrets | Database URLs, the sign-in client secret, and the GitHub App private key live in Azure Key Vault and are read by a managed identity. The storage account for masked dumps has shared key access disabled, so every read is attributable to an identity. |
| Model provider keys | Encrypted at rest with a key the control plane holds separately, decrypted for the length of a single request, and never written to a log. Without that key configured, the control plane refuses to store a provider key at all rather than storing it weakly. |
| Sessions | Stored as a hash, never as the token. Absolute lifetime of thirty days with no extension, and expired rows are deleted by a sweep that runs every five minutes. |
| Audit log | Hash chained, so an entry cannot be altered or removed without breaking the verification of every entry after it. |
| Transport | HTTPS only. The engine's control plane client refuses a non-HTTPS endpoint outright, and refuses to send at all unless a redactor is attached. |
| Recoverability | Thirty-five days of point-in-time recovery on the production database, with geo-redundant backup storage. Staging keeps fourteen days in one region. A restore is verified against a manifest taken at backup time and then asked, through the unprivileged role, to refuse a cross-tenant read. |
And the measures that do not exist yet.
- No SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. None is claimed anywhere on this site.
- Monitoring we will not vouch for from here. Alert rules, an availability test and runbooks are written and version controlled, and production is configured to create them (alerting_enabled is true in infra/terraform/stacks/control-plane/production.tfvars). Whether that configuration has been applied to the live subscription is not something you can check from outside this company, and it is not something this page will assert on your behalf. Ask for the evidence and it will be produced or the claim withdrawn.
- No self-service account or organization deletion. Closing an account or removing an organization is carried out by hand against the database by somebody who can reach it. Two things you can do yourself: export your audit log, which is an endpoint, and delete a stored model provider key, which is also an endpoint. There is no self-service export of anything else.
- No SLA, no support commitment, and no published uptime history. Production is deployed and answering, at app.antifailure.dev, with a separate staging deployment at app.dev.antifailure.dev. Access is invitation only. What does not exist is anything you could hold us to about how long it stays up.
The point of listing these is that a security review will find every one of them. Better it finds them here, next to the measures that are real, than in a questionnaire answer that has to be walked back. The service levels page sets out what would have to change first.
One of them had to be walked back here first. This list read “No production deployment. What exists is a staging control plane behind a sign-in allowlist,” and production was deployed and answering the whole time: app.antifailure.dev/readyz returns ready, and staging is a separate, newer deployment at app.dev.antifailure.dev serving a different commit. A reviewer checking the address our own README gives them disproves that sentence in thirty seconds, and then has cause to doubt every other line on a page whose only asset is that it can be checked. It is corrected above rather than deleted, because a page that quietly drops the item it got wrong is worth less than one that says which item it was.
What we would owe you, and how quickly the honest answer is a range.
| Subprocessors | The current list is published and dated. Thirty days written notice before a new subprocessor begins processing, with a right to object during that period. See the subprocessor page for how the notice actually reaches you today. |
|---|---|
| Breach notification | Without undue delay after becoming aware of a personal data breach. The qualifier matters and is not boilerplate: with no continuous monitoring in place, becoming aware can lag the event, and no number here can honestly say by how much. |
| Data subject requests | Assistance with access, correction, and erasure requests. Executed by hand, because there is no self-service path, so the practical turnaround is days rather than seconds. |
| Audit and information | The data plane is open source and can be read rather than described. For the control plane, the answer today is a conversation and this documentation, not an audit report. |
| Return and deletion | On termination, control plane records for the organization are deleted on request. Backups age out on their own schedule, which is set out on the retention page. |
| International transfers | Processing happens in the United States, in the Azure Central US region, which the infrastructure code enforces rather than assumes. A transfer mechanism for customers outside the United States is not yet in place. |
The transfer mechanism is the fifth missing value: transfer mechanism to be supplied. Standard contractual clauses are the usual answer and none have been executed, so this document does not claim them.
Know what happens before you deploy.
Create a disposable production twin for every risky change. Catch migration failures before they reach customers.