Acceptance test: someone on your side should be able to find the code, deploy the system, inspect its data flow, rotate its credentials and respond to a failure without depending on the original vendor.

Receiving a repository is not the same as receiving an operable product. AI systems also depend on prompts, model settings, evaluation data, provider accounts, scheduled jobs and source documents. If those pieces stay in an agency account or in one engineer's memory, the business does not control the system yet.

Use this checklist before the final invoice or acceptance milestone. Put each item in the statement of work at the start, then verify it with the people who will operate the product.

1. Source code and repository ownership

  • The repository sits inside an organization your company controls.
  • The full commit history, active branches, releases and issue history are present.
  • Your team has owner or administrator access and the vendor's access can be removed.
  • The repository includes the application, infrastructure configuration, migrations and deployment automation needed to rebuild the system.
  • Third-party or open-source components and their licences are documented.

If work began in a vendor-owned repository, transfer it rather than delivering a ZIP file. GitHub documents repository transfers and the permissions required to place a repository under a new owner.

2. Cloud, domains and vendor accounts

  • Your company owns the production cloud account, domain and DNS records.
  • Billing contacts and payment methods belong to your company.
  • AI model, email, storage, monitoring and other provider accounts are inventoried.
  • Production and test environments are clearly separated.
  • A named owner exists for each account and renewal.

Ask for a one-page dependency register with the provider, purpose, owner, renewal method and expected running cost. A code handover cannot remove a dependency you did not know existed.

3. Data, prompts and AI-specific assets

  • Database schema, migrations, retention rules and backup procedure are documented.
  • The company owns the source documents, prompt templates, tool definitions and configuration used in production.
  • Evaluation questions, expected answers and scoring rules are stored with version history.
  • The system records which model and configuration produced an output when that history matters.
  • There is a process for removing outdated documents and rebuilding indexes or caches.

An AI assistant cannot be maintained from application code alone. The source set and evaluation set are part of the product. See our guide to testing an AI system with real examples.

4. Secrets and access

  • No production password, API key or private key is committed to the repository.
  • Secrets are stored in a system your company controls, with access limited by role.
  • Every production credential is inventoried without copying its value into the handover document.
  • Vendor credentials are revoked or rotated after the transfer.
  • Emergency access and recovery ownership are defined.

The OWASP secrets-management guidance covers access control, auditing, rotation and revocation. Handover should reduce access deliberately, not copy a shared password into another chat.

5. Deployment and rollback

  • A clean environment can be deployed from the documented process.
  • Database migrations and required setup steps are repeatable.
  • Health checks and smoke tests show whether the release is working.
  • The runbook explains how to roll back a failed release.
  • Someone from your company performs one deployment while the vendor observes.

This last step is the strongest acceptance test. If only the vendor can deploy, the documentation is incomplete. AWS's operational guidance similarly recommends runbooks for routine procedures and validation that the team can operate the workload.

6. Monitoring, failures and support

  • Alerts go to a company-controlled address or incident channel.
  • The runbook names likely failures, the first diagnostic step and the escalation path.
  • Scheduled jobs expose their last successful run and failures.
  • Backups have a restore test, not only a promise that backups exist.
  • The acceptance window, defect process and post-launch support terms are written down.

A useful runbook has a desired outcome, required access, ordered steps and what to do when a step fails. The AWS operational-readiness checklist is a useful reference even when the product runs elsewhere.

7. The final acceptance drill

  1. Invite a technical owner who did not build the product.
  2. Start with the repository and runbook, without the vendor driving the keyboard.
  3. Deploy a safe change to the test environment.
  4. Run the evaluation and smoke-test suite.
  5. Locate an application log and trace one failed request or job.
  6. Restore a test backup or show the most recent recorded restore test.
  7. Rotate one non-production credential and verify the application still works.
  8. Record every missing instruction, fix the runbook and repeat the blocked steps.

Accept the handover when the drill works. A folder of documents that nobody has followed is still an assumption.

Copy this into your statement of work

At acceptance, the client will own the source repository and production accounts; receive application, infrastructure and data documentation; receive prompt and evaluation assets; and complete a deployment and operating walkthrough. Vendor access and credentials will be revoked or rotated after successful transfer.

How Kortex Labs handles ownership

Kortex Labs uses fixed scopes and includes source-code and IP ownership, deployment documentation and a runbook at handover. The exact account, data and support responsibilities are agreed before work starts. Read the questions to ask an AI development agency, or bring your existing proposal to a scoping call.

Review your project scope →