Yours, visible, and safe to fail.

You do. It lives in a repository in your organisation’s account from the first day, and the licence is assigned to you in the contract.

Where practical, production infrastructure, source repositories and service accounts are created under the client’s control. Where we must hold an account temporarily, it is listed in the account inventory and transferred at handover.

You do. We keep a credentials inventory: every system, what access it has, who holds it, and how to rotate it. Our access is personal, never shared logins, and is removed when the engagement ends.

The system runs on accounts under your control where practical, and handover includes the information required for another competent team to operate and maintain it.

Critical workflows are designed with monitoring, retries where safe, visible failure states and a documented manual fallback. Steps are designed so that a retry cannot post an invoice or send a message twice.

Yes. Every workflow has a written manual procedure. If the system is unavailable, work continues and is entered afterwards; the gap shows in the audit trail.

You get a data-flow document for your system: each source, where its data is stored, which external services it passes through, and why.

Only steps that need AI send anything, and only the fields that step needs. The data-flow document names the provider and model for each step. We use providers whose API terms do not permit training on your inputs by default.

Retention follows the provider’s API terms, which we state in writing for each provider we use. Where a provider offers shorter or zero retention for business accounts, we set it up in your account when your data warrants it.

Fields you mark as sensitive, such as personal phone numbers, bank details or patient information, are excluded or masked before any AI step. Which fields are masked is part of the data-flow document.

Every change to a record is logged with who or what made it, when, and the before and after values. Logs cannot be edited from the application.

Yes. Each person sees and changes what their role needs. Approval limits are set per role, for example quotes below margin or purchases above a value.

Consequential actions wait for a named person: prices below margin, purchase orders, quality dispositions, releasing invoices, and any message to a customer on a new basis. You decide where the lines are.

Backup and recovery are defined for each production system based on the hosting environment and operational importance of the workflow. Where the platform supports point-in-time recovery, we configure it when appropriate. The recovery procedure is documented and tested before handover.

Critical workflows are monitored. A job that stops running, or an integration that starts failing, shows a visible failure state and alerts a named person.

Yes. It covers how the system is deployed, how to restart each part, what each alert means and what to do about it, and who to call.

Where applicable: source code and repository access, credentials and account inventory, deployment and restart runbook, dependency and integration inventory, documented data flow, role and approval configuration, manual fallback procedures, backup and restore procedure, monitoring documentation, and a handover walkthrough.