If the proposal and these terms ever say different things, we will resolve it in writing before we proceed so there is one version of the plan that both teams can run with.
What you get
We will set up the MLOps pipeline setup as a project, focused on getting a repeatable training and deployment path that works with your operational data and your delivery constraints. The deliverables for this project are listed below, and we will treat that list as the definition of “done” for handover.
We will work inside your approved tools and access rules, and we will ask for what we need early, including data access and a schema walk-through. If access is delayed or the upstream data changes in a way that breaks the assumptions we built on, we will pause, document what changed, and shift the timeline to match.
* Data checks in code * Reproducible training pipeline * Model registry setup * Deployment path (API or batch) * Monitoring and drift alerts * Handover and runbook
Payment
To book the work, we invoice 30% of the price when you sign the proposal. We start scheduling the team and setting up access once that booking invoice is paid. We invoice the remaining 70% when we hand over the finished pipeline and runbook, including the agreed deliverables and the handover session.
Each invoice is payable within 14 days of its date. If an invoice goes past due, we will tell you what is outstanding and pause project work until it is brought up to date. Pausing means we stop running training jobs, deployments, and changes in your environment, and we move delivery dates by the same amount of time the project is paused.
Changes
A revision round is one cycle where you review what we delivered, we collect feedback in one place, and we apply that feedback as a single set of updates. For this project we include two revision rounds: one around the agreed baseline and metric setup, and one around the near-final pipeline and runbook before handover.
If you want changes beyond those rounds, or if the success metric changes after we lock it, we treat that as a scope change. We will write up the change with options, impact on timeline, and any cost change. We only continue on the changed scope after you approve it in writing.
Who owns what
Once the final invoice is paid, you own the code we write for your pipeline, including data checks, the reproducible training workflow, registry setup, deployment path, and monitoring and drift alert configuration. You also own the project-specific documentation we deliver, including the runbook and handover notes.
We keep ownership of our reusable internal templates, boilerplate, and tools that we use across projects, even if they appear inside the repo as scaffolding or helpers. If we use any third-party libraries or managed services, they stay under their own licences and terms. If you need us to assign access, move repos, or rotate credentials at handover, we will do that as part of the handover checklist.
Portfolio
We may show the finished work as a portfolio example of the kind of MLOps pipeline setup we build, because it helps future clients understand what “production-ready” looks like in practice. We do not share your raw data, credentials, internal documents, or anything that would expose your security posture.
If you want the whole project kept private, tell us in writing before we start, or any time before we publish. If you ask for privacy after we have already prepared materials, we will stop and we will not publish, but we may keep private internal notes so we can support you and learn from the build. We can also agree a redacted version if that is useful for you.
Limits
We are responsible for delivering the agreed deliverables and for doing the work with care, using the metric we agree and the data access you provide. We are not responsible for model performance changes caused by upstream data shifts, label changes, new business rules, or production constraints that are outside the pipeline we are building.
We do not take responsibility for outages, incidents, or losses caused by access changes, misconfigured permissions, or changes made by other teams in your environment during the project. We will flag risks when we see them, and we will build monitoring and drift alerts as part of the work, but alerts are not the same as prevention. Retraining, new labels, or new features after launch are follow-on work we scope with you.
Ending the project
Either of us can end the project by telling the other in writing. We will agree the notice period with you in writing, because the right timeline depends on what environments we are in and what needs to be made safe before we step away.
If the project ends, you pay for the work done up to the end date, including any committed costs we cannot cancel. We will then hand over what is complete and usable at that point, along with the current runbook notes and the information your team needs to take over safely. If access has been delayed or blocked in a way that prevents progress, we may also end the project and invoice for time spent and work completed up to that point.
Signature
