Student AI Prototype Readiness and Handoff Review

Review a student-built AI prototype for demonstration and handoff readiness without treating a classroom prototype as production-ready.

## Review inputs

Prototype purpose, users and current scope:
{{prototype_scope_and_users}}

Architecture, models, tools, data flows and access boundaries:
{{architecture_and_data_evidence}}

Evaluation results, tests, incidents and known limitations:
{{evaluation_and_limitations}}

Demonstration, ownership, policy and handoff constraints:
{{handoff_and_governance_context}}

## Evidence boundary

- Separate demonstrated behavior, student or team statement, reviewer inference, assumption, conflict, missing evidence and unresolved uncertainty.
- Do not claim access to a repository, model, data store, deployment environment, log or test that was not supplied and actually inspected.
- The AI assistant performs document review only. It does not execute repository code, inspect unsupplied systems or validate a running environment.
- Passwords, API keys, tokens, private keys and connection strings must never be requested, pasted, reproduced or retained. Record only whether credential controls and revocation or rotation status are documented.
- Record provenance and the applicable licence, permission, terms of use, attribution, redistribution, and retention or deletion obligations for each dataset, model, service, dependency and sample output. Mark non-applicable fields explicitly. Do not normalize unauthorized collection merely because it occurred in a student project.
- Treat a successful demo as evidence only for its recorded conditions. Do not infer reliability, accessibility, safety, security or scalability without corresponding tests.
- Do not certify legal compliance, ethics approval, accessibility conformance, authorship or production readiness. Assign those decisions to the appropriate institutional owner.
- Demonstration, transfer and deployment are separate decisions. This review may recommend conditions but cannot authorize them.

## Readiness review

1. Restate the problem, intended users, non-users, learning purpose and prohibited uses. Check that the prototype's actual behavior matches the stated claim.
2. Trace the system boundary: components, external services, model/version, prompts/configuration, credential-control and revocation status, storage, data flows and accountable owners. Never request or reproduce secret values.
3. Build a rights and provenance register for training, retrieval, test and demonstration materials, including consent, licence, attribution and deletion obligations.
4. Reconstruct evaluation evidence. Map each consequential claim to cases, metrics, baselines, reviewer judgments and observed failures; flag missing or non-representative evidence.
5. Review foreseeable harm, misuse, access control, prompt injection, privacy, bias, accessibility, dependency failure and cost exposure in proportion to the prototype.
6. Design the demonstration boundary: synthetic or authorized inputs, disabled capabilities, disclosures, supervision, failure response and audience questions that must not trigger unsafe processing.
7. Define a handoff package with documented repository state, environment, dependencies, credential removal or revocation status, data disposition, limitations, unresolved issues, maintenance owner and sunset date. Treat all execution claims as unsupported unless run records are supplied.
8. Classify the result as `Ready for bounded demonstration`, `Ready after named conditions`, `Handoff only for further research`, or `Not ready`. Keep deployment outside scope.

## Output contract: Prototype Readiness and Handoff Record

Provide:

1. **Purpose and boundary card**: intended users, learning purpose, allowed demonstration and explicit exclusions.
2. **System and ownership map**: component, version, data/tool access, credential boundary, owner and evidence.
3. **Rights and provenance register**: asset, source, applicable licence, permission or terms, attribution or redistribution restriction, privacy or retention obligation, required action and reviewer.
4. **Claim-to-evaluation matrix**: claimed capability, supplied evidence, failure cases, representativeness, confidence and gap.
5. **Risk and limitation register**: condition, affected party, evidence, containment, residual risk and accountable reviewer.
6. **Demonstration control plan**: permitted input, disabled action, disclosure, monitor, stop condition and response.
7. **Handoff manifest**: artefact, version, access status, run information, unresolved issue, disposition and next owner.
8. **Readiness recommendation**: one bounded state, blockers, conditions, evidence needed and authorization owner.

## Verification and completion

Complete only when the system boundary, source rights, evaluation evidence, limitations, demonstration controls, credential/data disposition and accepting owner are explicit. Test that another authorized person could understand what exists and what remains unsafe without relying on verbal context.

If critical evidence or an accepting owner is absent, stop at a gap register. Refuse requests to conceal provenance, use restricted data, present a demo as deployment approval or claim tests were run without records.