Your information
The questions builders actually ask before committing a build context to an AI. Honest answers, not reassurances.
Your code
Mandaire does not store your codebase. The decision ledger records decisions: what was built, what was refused, and the stated reason. It stores architectural choices, not implementations. A ledger entry reads "added rate-limiting middleware to the payments endpoint; blocked removing it in sprint 4 because the compliance review had not cleared." It does not store the middleware itself.
References to code appear (file names, module names, function names when they clarify the decision). The code itself stays in your repository. A breach of Mandaire's infrastructure produces: decision history, taste memory, refused-paths log. Not your source code.
This is not a policy. It is how the system is built. The ledger is a record of judgment, not a mirror of your codebase.
Credentials
When a build requires credentials — deployment tokens, third-party API keys, environment secrets — they flow through your execution environment at the moment they are needed. They are not written to the decision ledger. Mandaire does not ask for them. If a build step requires a credential to execute, the pattern is: Mandaire drafts the step, you apply it with your credentials in your environment. The draft goes in the ledger. The credential does not.
The analogy that works is a good engineer who understands how authentication for a system works without being able to recite the production API key. The engineer is useful precisely because the knowledge of how it works is separable from the value of the secret.
Your customers' data
If the product you are building handles personal information — user names, emails, payments, health records — that data does not flow through Mandaire. The build context Mandaire works with is the product's schema, architecture, and stated requirements: "the users table has a PII column that requires field-level encryption." Not the PII itself.
Mandaire never deploys to production or touches live data. It makes irreversible production actions impossible without your explicit sign-off. That is the binding constraint on the .dev surface: causal-model integrity. The full account of how this works — the refusal log, the irreversible-action gate, the escalation model — is at mandaire.org.
The key model
Your decision ledger, taste memory, and refused-paths log are encrypted with a key derived from your password before they are written to disk. We do not have the key. This is the same architecture as the personal tier: an architectural constraint rather than a trust position. A government request, a hosting breach, or a Mandaire acquisition all produce the same result for the requester: encrypted blobs they cannot read.
The encryption module is open-source under AGPL. Any competent engineer can read your archive without Mandaire's involvement. The self-host path uses the same codebase as the managed surface. The sovereignty path is documented and tested.
Your Claude API key is never stored. We never see it and we never resell tokens. You bring the frontier model you already pay for; Mandaire provides the reasoning layer, the ledger, and the build environment.
Portability
Full export of your decision ledger, taste memory, refused-paths log, and intent brief history at any time. When you graduate to your own infrastructure, these go with you. The history that makes the CTO layer compound across projects is not locked to the managed hosting. You graduate the production hosting; the judgment record follows you.
No lock-in is an architectural commitment. One of the bets the system is built around is that a useful tool should not become a load-bearing dependency you cannot leave.