Student AI Prototype Readiness and Handoff Review

Public field comparison

Student AI Prototype Readiness and Handoff Review

Student AI Prototype Readiness and Handoff Review

Test whether a student AI prototype has documented users, data rights, evaluation evidence, limitations, risks and a safe accountable owner before demonstration or reuse.

Test whether a student AI prototype has documented users, data rights, evaluation evidence, limitations, risks and a safe accountable owner before demonstration or reuse.

Use this before a capstone or club prototype is demonstrated, transferred or reused to create a bounded readiness record without authorizing deployment.

Use this before a capstone or club prototype is demonstrated, transferred or reused to create a bounded readiness record without authorizing deployment.

Capstone Demonstration Gate
AI Club Prototype Handoff
Student Project Reuse Review

Capstone Demonstration Gate
AI Club Prototype Handoff
Student Project Reuse Review

prototype_scope_and_users
architecture_and_data_evidence
evaluation_and_limitations
handoff_and_governance_context

prototype_scope_and_users
architecture_and_data_evidence
evaluation_and_limitations
handoff_and_governance_context

Run this prompt in any capable AI assistant before a public demo, course handoff or reuse decision. Paste the stated purpose and attach sanitized architecture notes, source licences, test evidence, sample outputs and ownership constraints. Never upload credentials or identifiable user data. Have the project supervisor and relevant data, security, accessibility or legal reviewers resolve the resulting conditions.

Run this prompt in any capable AI assistant before a public demo, course handoff or reuse decision. Paste the stated purpose and attach sanitized architecture notes, source licences, test evidence, sample outputs and ownership constraints. Never upload credentials or identifiable user data. Have the project supervisor and relevant data, security, accessibility or legal reviewers resolve the resulting conditions.

A capstone team plans to demonstrate a retrieval assistant configured to retrieve from an authorized university document collection. The review finds unclear document rights and an unresolved shared-credential control, restricts the demo to licensed synthetic content, and produces a handoff manifest for the lab owner.

A capstone team plans to demonstrate a retrieval assistant that searches an index built from mixed university documents. The review finds unclear document rights and a shared API key, restricts the demo to licensed documents or synthetic test content, and produces a handoff manifest for the lab owner.

Expert

Expert

General AI

General AI

readiness review

readiness review

education
student-projects
app-prototype
handoff
risk-assessment
data-governance

education
student-projects
app-prototype
handoff
risk-assessment
data-governance

Student AI Prototype Readiness and Handoff Review

Student AI Prototype Readiness and Handoff Review

Review a student AI prototype for bounded demonstration or handoff using data rights, evaluation, risk, limitation and ownership evidence.

Review a student AI prototype for bounded demonstration or handoff using data rights, evaluation, risk, limitation and ownership evidence.

Prompt-body line comparison

Removed Added Unchanged context

 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 the provenance, permission and retention basis for every dataset, model, service, dependency and sample output. Do not normalize unauthorized collection because it occurred in a student project.
+- 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, permission, restriction, retention/deletion action and reviewer.
+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.