Sample scope of work: a plant-floor dashboard.

Example Manufacturing Co. (“the Client”) runs a packaging line, Line 3, controlled by Allen-Bradley PLCs with Rockwell FactoryTalk View SE HMIs. Line 3's counts and states are collected in the plant's AVEVA PI (OSIsoft PI) historian. Today supervisors see live status only at the HMI, and shift reports are compiled by hand from historian trends and paper downtime logs.

This project delivers a read-only web dashboard, available on the business network, that shows Line 3's current state, counts and downtime for the current and previous shifts. The goals are:

• Supervisors and the plant manager can see Line 3's state, good and reject counts, and downtime for the current shift from a browser on the business network, without walking to the HMI.
• Shift production and downtime figures come from one agreed source, the historian, instead of being re-keyed.
• Nothing built in this project can write to a PLC, an HMI, the historian or the OPC UA server.
• The Client's IT and controls teams can run, change and extend the system after handover without us.

• Collector. A service on a Client-provided host in the industrial DMZ that reads Line 3 values from the DMZ PI server through PI Web API, and live line state from the existing Kepware OPC UA server, read-only. It pushes values outbound over HTTPS to the API.
• API and database. A service in the Client's AWS account that stores the collected values and serves them to the dashboard.
• Dashboard. A web application with three screens: Line status (current state, run rate against the ideal rate, good and reject counts), Shift summary (counts, downtime events and total downtime by shift) and Downtime log (each stop with its start, end and duration, filterable by shift).
• Sign-in. Single sign-on through the Client's existing identity provider, over OpenID Connect or SAML, with two roles taken from groups the Client's IT team manages: viewer and administrator.
• Infrastructure and delivery. Infrastructure defined as code (AWS CDK), deployed through a CI/CD pipeline (GitHub Actions) into separate test and production environments.
• Monitoring. Alarms for data freshness, collector errors, API errors, sign-in failures and backups.
• Documentation and handover. Runbooks, a data dictionary, architecture and security documentation, and knowledge-transfer sessions, as set out in section 11.

• Any write to PLCs, HMIs, the historian or the OPC UA server, including setpoints, alarm acknowledgements and recipe changes.
• Changes to PLC logic, HMI screens, historian configuration or tag naming. Where a new tag is needed, the Client's controls team creates it.
• Operator entry of downtime reasons. A candidate for a later phase, quoted separately.
• An OEE figure. The dashboard shows the inputs (state, counts, downtime); an agreed OEE calculation can be added later as a change.
• Lines other than Line 3. The design allows more lines to be added (see the “Add a tag or a line” runbook), but configuring them is a separate change.
• Mobile apps, offline use, and access from outside the Client's network.
• Integration with any other business system.
• Hardware, network changes and software licenses. We specify what is needed; the Client's teams make the changes and hold the licenses.
• Support, maintenance or new features after handover. Available as separately quoted work.

• The Client provides the access in section 4 before the build phase starts. If access arrives later, the schedule moves with it; the price changes only if the scope does.
• The Client's controls team reviews and signs off the data-flow design (phase 1) before any software connects to the OPC UA server or the historian.
• A PI server replica, or another read-only historian endpoint, is available in the DMZ. If it isn't, sections 4 and 13 are revisited before the build starts.
• The Client's network team opens the firewall rules listed in the design document. We don't change network equipment.
• A site-to-site VPN (or AWS Direct Connect) links the business network to the Client's AWS account, set up by the Client's network team.
• The Client names one product owner who can answer questions and accept deliverables, and one controls engineer for tag questions.
• The historian is the source of truth. Where the dashboard and the historian disagree, the dashboard is treated as wrong and, before acceptance, is fixed under this scope.
• The test environment reads the same historian points as production. No plant simulator is built.
• Hosting, license and other third-party costs are billed to the Client's own accounts.

• Source code for the collector, API and dashboard, with automated tests, in the Client's repositories.
• Infrastructure as code (AWS CDK) for the test and production environments.
• A CI/CD pipeline (GitHub Actions) that tests, builds and deploys every change, authenticating to AWS with OIDC so no AWS keys are stored.
• An architecture and data-flow document for the Client's security review, including every firewall rule with its source, destination, port and purpose.
• A data dictionary covering every tag and field the dashboard uses.
• Runbooks: deploy, roll back, rotate credentials, add a tag or a line, and respond to each alert.
• Knowledge-transfer sessions, listed in section 11.

The system is accepted when every criterion below passes in production. Each one is checked together with the Client's product owner.

Acceptance is judged against these criteria only. Anything not listed here is not a reason to withhold acceptance, and is not in the price; it can be raised as a change (section 9).

Work runs in five phases. Each phase ends on a written exit criterion, and working software is reviewed with the Client in the test environment throughout phases 2 and 3.

Milestone dates: stated here in the real document, agreed with the Client before work starts.

1. Either party raises a change in writing: what is needed and why.
2. We reply in writing with its effect on scope, price and schedule, or confirm that it has none.
3. Nothing changes until the Client's product owner approves it in writing. Approved changes are added to this document as numbered amendments.
4. A change that isn't approved isn't built, and the original scope and price stand.

Until the system is accepted, fixing something that fails an acceptance criterion in section 7 is not a change. It is covered by the fixed price.

The following are prepared for the Client's IT, controls and security teams during phase 1, before any connection to plant systems:

• A data-flow diagram showing every connection, its direction and the zone boundary it crosses. Nothing in AWS or on the business network opens a connection into the OT network. The only connection into the OT network is the collector's read-only OPC UA session to the Kepware server, opened from the DMZ on a single firewall rule the Client's network team controls.
• A firewall rule list: source, destination, port, protocol and purpose for each rule.
• Service accounts: one per system, read-only, named and documented. No shared or personal credentials in the running system.
• OPC UA security: SignAndEncrypt mode, with certificate trust set up by the Client's controls team.
• Secrets kept in AWS Secrets Manager (and, for the collector, the DMZ host's protected store), never in code, configuration files, tickets or email.
• Sign-in only through the Client's identity provider. The dashboard is reachable only from the Client's network addresses.
• Encryption in transit on every connection, and at rest for stored data and backups.
• Logging of sign-ins, deployments and collector errors to CloudWatch, retained according to the Client's policy.
• Dependency scanning in the pipeline, with findings reported to the Client before each release.
• Data classification: production values and user sign-in names only. No other personal data is stored.
• Answers to the Client's security questionnaire, and an architecture walkthrough for the security team.

Handover is part of the fixed price. It is complete when the Client's team has deployed a change, rolled it back and responded to a test alert themselves, using only the documentation. It includes:

• Everything in section 6, confirmed in the Client's repositories and accounts.
• Knowledge-transfer sessions: architecture walkthrough, code tour, supervised deployment, rollback and recovery, and a test incident.
• Access and credentials: every account confirmed as the Client's, secrets rotated, and our access removed or reduced to whatever support is agreed.

The full contents are shown in the sample handover package for this same illustrative project.

• The Client owns all code, infrastructure definitions, documentation and data produced under this scope. There is no license fee and no lock-in.
• Everything is built in the Client's repositories and AWS account. Nothing runs in accounts we control.
• Open-source components remain under their own licenses, which are listed in each repository.
• Confidentiality is covered by the NDA signed before this engagement.

Fixed price: stated here in the real document.

The fixed price covers everything in sections 2, 6, 7 and 11: design, build, testing, deployment to test and production, documentation, knowledge transfer, handover, and fixing anything that fails an acceptance criterion before acceptance.

It does not cover:

• Anything listed as out of scope in section 3.
• Approved changes under section 9, each priced before it starts.
• Hosting, software licenses and other third-party costs, billed directly to the Client's accounts.
• Support, maintenance or new features after handover, quoted separately if wanted.

Invoicing schedule and payment terms: stated here in the real document.

Nothing is built until this scope is accepted. Signing below accepts the scope and the fixed price stated in section 13.