Research-engineering delivery should not consist of a demonstration or one report file. A maintainable and reproducible project normally includes source code, model configurations, data records, runtime definitions, test evidence, software or device material, technical documentation and knowledge transfer. The exact checklist should be agreed at kickoff, not reconstructed at the end.
Organize acceptance by deliverable type
| Type | Recommended deliverables | Acceptance evidence |
|---|---|---|
| Source code | Repository structure, dependencies, build scripts, interfaces and licenses | Build and run from a clean environment |
| Algorithms and models | Configuration, weights, training records, inference code and versions | Reproduce metrics on the agreed samples |
| Data | Dictionary, source, processing records, versions and authorization boundary | Sample-check fields, counts and processing lineage |
| Experiments | Test set, metric formulas, baseline, logs and error analysis | Run the evaluation script independently |
| Software and APIs | Package, interface docs, access control, logging and exception handling | Execute user-flow test cases |
| Robotics and devices | Calibration, wiring, communications, maps, parameters and procedures | Execute tests under agreed conditions |
| Deployment | Environment, scripts, backup, monitoring and recovery instructions | Deploy and exercise recovery in the target environment |
| Project records | Requirements, design, milestones, changes, tests and acceptance logs | Records match final code and configuration |
Reproduction is stronger than a live demonstration
A live demo proves one run in one environment. Reproduction acceptance asks the organization or a designated reviewer to follow the documentation, run from input to output in the agreed environment, and verify versions, parameters, logs and metrics. A stochastic training process may also need an agreed repetition count and acceptable variation.
If only the original developer can execute a step, the knowledge has not been transferred. Hidden dependencies, manual operations, account permissions and external services belong in the environment and operating instructions. A screenshot is not a substitute for an executable reproduction record.
Test evidence must match the intended scenario
A metric applies only to the recorded samples, environment and version. Extending a controlled-test result to every field condition overstates the evidence. The acceptance report should distinguish passed, conditionally passed, failed and not-verified items.
- Record the source, version, scope and exclusions of test samples.
- Define metric formulas, thresholds, baseline and statistical scope.
- Retain failed samples, exception logs and cause categories.
- Separate offline, simulation, bench, prototype and field results.
- Identify untested devices, environments, data and performance ranges.
Licensing and third-party dependencies are acceptance items
Identify project-created code, pre-existing organization material, open-source components, commercial software, pretrained models and datasets. Source delivery does not automatically transfer third-party rights. Copying, modification and deployment are governed by the relevant license and contract.
Accounts, keys, certificates and device authorizations should not be embedded in source or public documents. Transfer them through a controlled channel and record replacement, revocation and custody. If an external service cannot be transferred, document alternatives and continuing cost.
Complete knowledge transfer after technical acceptance
The support boundary should distinguish an original-scope defect, a new requirement, an environment change and a third-party upgrade. This allows the organization to operate after personnel changes instead of depending on one developer's workstation.
- Explain project structure, major design decisions and known limitations.
- Demonstrate common runs, configuration, data updates and troubleshooting.
- Identify maintenance permissions, backups, monitoring and log locations.
- Define defect correction, change requests and support duration.
- Record final versions, hashes, inventory and receipt confirmation.
Frequently Asked Questions
Is source-code delivery sufficient?
Usually not. Dependencies, environment, configuration, data records, tests and operating documentation are also needed for building, reproducing and maintaining the result.
When should acceptance metrics be defined?
Define them before development or immediately after feasibility work. Defining them at the end creates disputes over samples, scope and responsibility.
How can confidential data be used in acceptance?
Run the evaluation in an authorized controlled environment and retain hashes, summaries, scripts, logs and signed records without publishing the raw data.
Next step
Use this checklist at kickoff to define the delivery directory, reproduction steps and acceptance evidence, or apply it to an existing project as a delivery-gap review.