PoC handover reference: acceptance, runtime boundaries and operations
Use the handover checklists in this article to record acceptance evidence, permissions, exceptions, updates and takeover ownership before deciding readiness for live use.
By
Tenten AI FDE Team
Implementation Methods
Published
Updated
Read time
4 min
A PoC demonstration shows how a task can run. Handover also needs the receiving team to know which results are acceptable, what the system may do and who handles changes to data or services.
This article provides reference tables for acceptance, runtime boundaries and operations. Add task-specific evidence and owners to project documentation before deciding readiness for live use.
Acceptance: define completion before testing
Record:
- Completion: inputs, outputs, applicable scope, information to retain and content the system must not infer.
- Cases: approved representative data, normal work, omissions, conflicts, unauthorized requests and failures.
- Criteria: consequential errors, review, time and cost constraints, and the person judging results.
- Evidence: data, versions, tools, settings, actual outputs, revisions and open issues.
For an illustrative internal summary draft, require sources for significant statements, missing-information flags and a designated reviewer. If external sending is outside scope, do not provide that permission. This is a planning example, not a measured outcome.
Anthropic's January 9, 2026 evaluation guide distinguishes tasks, trials and outcomes, noting that outputs can vary between runs. Use suitable assessments without importing one universal accuracy, test-count or latency threshold.
Acceptance evidence identifies assessed behavior; operating monitoring helps detect incidents and changes. Both need defined scope and owners.
Runtime boundaries: enforce permissions in services
Prompts can describe expected behavior but cannot replace access or action authorization. At handover, confirm where restrictions are enforced and test refusal and approval paths.
| Boundary | Configuration to record | Exception handling and ownership |
|---|---|---|
| Input and data | Users, data scope, retrieval and tool authorization | Refuse, flag or escalate unauthorized or insufficient material |
| Output and review | Required evidence, omission flags, review and publication authority | Owners check and revise unsupported or conflicting content |
| Actions | Permitted operations, parameter scope, approvals and repeated-action handling | Establish state before proceeding after failure or an uncertain result |
| Resources and cost | Task-specific execution, spending and resource limits | Stop, notify and arrange takeover when limits or anomalies occur |
OWASP's Prompt Injection guidance notes that external content can affect behavior and RAG does not fully mitigate the risk. Design tool privileges and consequential-action approval separately, testing relevant scenarios.
Record known control limits. One successful exercise does not establish safety for every input or remove maintenance needs.
Operating handover: make work checkable
| Item | Records to provide | Receiving-team check |
|---|---|---|
| Acceptance | Cases, results, criteria, limitations and open decisions | Verify assessed scope and consequential exceptions |
| Permissions and configuration | Data, tools, approvals and suspension | Test allowed and refused access with appropriate accounts |
| Monitoring and incidents | Useful event, cost and quality signals, reporters and handlers | Report a test incident and locate its owner |
| Support | Contacts, triage, responsibilities and agreed service scope | Walk through a sample ticket |
| Data and version updates | Update methods, checks, reassessment and approval | Try an approved source update |
| Suspension and takeover | Recoverable settings, original process and external actions needing follow-up | Exercise suspension and manual takeover |
| Responsibilities | Operating, maintenance, approval, supplier and scope-change owners | Confirm records and unresolved issues |
Arrange exercises according to risk, using safe environments or data as appropriate. A documented setting does not establish that a service enforces it. Do not perform unauthorized production actions to demonstrate handover.
NIST's AI Risk Management Framework is a voluntary lifecycle reference. Check the actual system's permissions, responsibilities and operating evidence rather than treating a framework name as certification.
Update evidence after changes
Assign someone to assess changes to data, models, prompts or tools and update affected cases and records. Logs can contain sensitive information; define access, redaction and retention together.
Ensure the receiving team can verify results, report issues and return to the original process before expanding the use. Documentation clarifies responsibilities and actions. Use, content quality and applicable requirements each need corresponding evidence.
Summarize this page with AI
Related posts
Start with one workflow.
Agree on the next step.
Leave your contact details and question type. We will follow up by email to understand the work and discuss scope.