--- title: "Trust Center: code ownership, data and continuity" description: "The answers you need before signing: who owns the code, where the data sits, how we govern AI on critical processes, and what happens if you change supplier." url: "https://volcanicminds.com/en/trust" lang: "en" type: "first_level_page" updated: "2026-09-04" alternate: "https://volcanicminds.com/trust" --- # Trust Center the answers before the questions Who owns the code, where the data sits, who touches it, and what happens if you change supplier one day. Written down here, not asked for in a call. ## Why this page exists The same questions come up in every serious evaluation of a software supplier, and they nearly always arrive late: halfway through a technical call, when a proposal is already on the table and the person who has to sign off was not in the earlier meetings. They are fair questions and the answers do not change depending on who is asking, so they may as well be written down**. Here is how we treat code, data, arti**ficial intelligence on the processes that matter, and the way out of a supplier relationship. ## The fixed points Commitments that hold on every project, not concessions negotiated case by case ### The code is 100% yours No licence fee on the software we build, no vendor lock-in. The source code belongs to the client. Unless agreed otherwise, we retain the moral rights of authorship over the software. ### Your data does not train models We select enterprise cloud services that exclude it contractually, in line with GDPR and SOC 2. Where more is needed, a private AI infrastructure is considered. ### AI does not decide on its own An LLM is never wired straight to a database. Guardrails, strict schema validation, and human approval on write and high-risk operations. ### Every decision leaves a trace For each agent operation we keep the context read, the data extracted, the steps taken and the token cost. Reconstructing an error is a query, not an investigation. ### Standard technologies, never proprietary No in-house frameworks only we know how to maintain, with closed licences and future exploitation costs. Documented, widely used stacks, because another team has to be able to take over without rewriting. ### WCAG 2.2 AA accessibility Contrast, keyboard navigation, roles and states exposed to assistive technology. Not a badge at the end of a project: a design constraint from the start. ## What we hand over, and what happens if we leave **Code ownership means little if you cannot use it.** That is why handover includes the repository with its full history, API documentation in Swagger/OAS format, access to the services, and a proper handoff to your team or to whoever replaces us. The uncomfortable question is the next one: what happens if Volcanic Minds is no longer around tomorrow, or if you decide to change supplier. The answer cannot be reassurance, **it has to be a consequence of the architecture**. The code is already yours and already in your hands; it runs on technologies any competent team knows; the data sits in standard databases you can export without our permission; and the business logic is not tied to a single AI model vendor, so that part stays replaceable too. _A project done well is a project you can walk away from._ If leaving us required a rewrite, the fault would be ours. ## The direct questions The ones that come up during evaluation, answered in full ### Who owns the source code? The client, entirely. It is a no vendor lock-in policy applied every time: standard, documented technologies, handover of access credentials, API documentation in Swagger/OAS and the repository. We do not hold back parts of the system as commercial leverage. ### Is company data used to train AI models? No. We select enterprise cloud services that contractually guarantee the opposite, in line with GDPR and SOC 2. Where data is particularly sensitive or the sector demands it, a private AI infrastructure is considered, on-premise included, so nothing leaves the client's perimeter. ### Where does the data sit, and with which providers? Wherever it needs to. We are not tied to a single cloud: we work routinely with OVH, AWS, Hetzner, DigitalOcean, Seeweb, Aruba and Azure, and just as often on the client's own infrastructure, with Kubernetes or Linux machines (Debian and Ubuntu). The choice is made at the start based on your regulatory, contractual and budget constraints, not on our convenience: if the requirement is that data stays on your servers, we design for that. ### How do you handle authentication in the systems you build? It depends on the context and is decided together: credential-based authentication, Single Sign-On against the corporate identity provider, multi-factor authentication (MFA), and one-time OTP codes sent to the corporate email address. On enterprise web apps, **session tokens live in HttpOnly cookies rather than localStorage**, so an XSS attack cannot read them. ### Who on your side accesses our systems, and how do we control it? The model is that the client creates the accounts. We do not create standalone users on your environments: we ask to be authorised on accounts that already exist, or to be added to your working team with named users. The consequence is the one that matters to you: **you can review or revoke our access at any time, without going through us** and without the system breaking. This applies to infrastructure, backups and DevOps pipelines. ### How do you make AI reliable on critical processes? An LLM is never wired straight to a database. We build agentic systems with guardrails and strict data-schema validation, and for write or high-risk operations we use human-in-the-loop flows, where a person approves before the action takes effect. Automation reaches as far as the cost of a mistake stays acceptable. ### How are AI decisions traced? Through AI observability: every agent operation leaves an immutable record of the context read, the data extracted, the reasoning steps followed and the token cost. It exists so that what happened can be reconstructed months later, which is what any audit asks for. ### What happens if we change supplier, or if you disappear? The code is already yours and already delivered, there is nothing to recover. It runs on widely used technologies another team can pick up, the data sits in standard databases you can export without going through us, and the business logic is not tied to a single model vendor. Continuity is a consequence of the architecture, not a contractual promise. ### How are backups, restore, RTO and RPO handled? Backup, RTO and RPO have no standard value: they are sized against the damage an outage would cause in your case, and agreed before going to production. Alongside the backup we hand over documented restore procedures and the means to obtain copies of the backups and move them onto your own servers or machines. **A backup only the supplier knows how to restore is not a backup, it is another point of dependency.** ### Do you offer source code escrow? Yes, but not on every project: it makes sense on large-scale initiatives, where the financial investment and operational impact make continuity a risk worth covering formally. In those cases terms, escrow agent and release conditions are settled in the contract. It is worth saying, though, that escrow mainly protects clients whose supplier does not hand over the code: **here the source is already yours and already in your hands from the first commit**, so escrow covers a residual risk, not the main one. ### Are you insured? Yes. Volcanic Minds carries professional indemnity insurance and a cyber policy, which covers damages and cyber attacks. It is a question that almost always comes from procurement or legal: policy details are provided on request during contract negotiation. ### What happens after go-live? Release is the beginning, not the final delivery. We work with corrective and evolutionary maintenance contracts with explicit SLAs, and a clear line between bugs (under warranty) and new features. Training and handover to the client's team are part of it. ### How are changing requirements handled? Through a transparent Change Request process: we assess the impact on time and cost together and decide whether to build now, replan or postpone. Nothing is implemented without the client's approval, and nothing is invoiced by surprise. ### Is the software you build accessible? Yes, we design to WCAG 2.2 level AA: adequate contrast, full keyboard navigation, roles and states exposed to assistive technology. Accessibility enters the requirements at the start, because bolting it on at the end costs far more and works worse. ### How are payments split? The payment split is flexible and calibrated on the complexity of the project and the clarity of the requirements. Generally, for a standard project running around four months, we apply a milestone structure like this one: **Deposit**: an upfront share from 25% (for long-standing clients we have worked with for years) up to 35% (for unusual projects, highly complex or with strongly evolving requirements). **Intermediate milestones**: later payments are spread across the stages of the project. We always place a key milestone at the end of development, right before QA and testing begin. **Balance**: paid on project close and final release. ### How does the acceptance ceremony work? We ask for your presence throughout the project, with regular meetings (roughly once a week) where the project and its progress are discussed and where either side raises issues or needs. Then comes a pre-release QA phase that actively involves both sides for checks and reports. This phase genuinely matters and has to be done together. It exists to take the surprise out of release, during which we run an exhaustive pass over the whole system. Once the ceremony is over we do not send the closing invoice straight away: we leave a few days for you to think it over behind closed doors, and only then issue the final invoice. In the month that follows, our presence for fixing blocking issues and minor work is included. ### Can we see one of your contracts? Are you willing to sign an NDA? Yes to both. We are glad to show you a sample contract so you can see our transparency and attention to detail first hand. The text is flexible and we are open to changes justified by the specifics of the project. On protecting information (NDA), we have our own template, fully bilateral and balanced. We are equally open to reviewing and signing the document your legal team proposes, provided it respects fairness and transparency and creates no asymmetry between the parties. Since this is legal and confidential material, we share these documents right after a first introductory call. ## What we do not claim A Trust Center is worth little if it only lists what goes well. Volcanic Minds was founded in September 2022: **we are not yet ISO 9001 or ISO 27001 certified, and we do not claim certifications we do not ho**ld. We design against recognised practices and well-built standards, and we rely on cloud providers that do hold those certifications, but that is a different thing and it should be said. We are willing to start certification programmes for projects and clients that genuinely need them. If your procurement process requires a formal certification, it is better to know at the first call than at due diligence. If instead it requires understanding how we actually work, this page is the starting point and specific questions are welcome. [All frequently asked questions] ## Ask us the question that is missing Questions are the best way to get to know us. We have always offered transparency and total quality: your project becomes our objective, and to hit it we have to be perfectly aligned from the starting line.