Client and operator acceptance checklist

Use this checklist during handoff. A checked local item is evidence for the described behavior, not automatic acceptance of the larger production specification. Record the reviewer, date, build commit and exceptions separately.

Local functional demonstration

• Open the correct company and confirm scope/roster coverage.
• Open Business research, inspect its disabled-provider state and query preview, then add a public source manually without spending provider credits.
• Review an engagement plan and prepare a bounded kickoff request.
• Enroll a fictional participant, submit a response and accept the original as advisor.
• Create and review a task, obtain exact current owner/performer decisions, and inspect version history.
• Demonstrate that disagreement and a later edit require fresh review/confirmation.
• Inspect graph arrows, focus, readable/Fit modes, register, teams and recorded reporting chart.
• Review duties/handoffs and a workflow; complete one manual case and leave another with a visible exception.
• Record a metric, prediction and outcome without erasing missing data or confounders.
• Prepare a client report, preview it, approve its exact content/audience and inspect the ZIP.
• Change a bound source in a separate practice example and verify stale-report rejection.
• Complete the training workbook and explain the distinction between work, authority and execution.

Local technical handoff

• Lockfile install, migrations, build, tests and dependency audit pass.
• Generated route/schema artifacts match the runtime source.
• Research tests pass with a simulated provider: collected sources retain URL/date/digest, imports remain unreviewed, replay does not repeat collection, and tenant/request limits are enforced. This is separate from live-provider acceptance.
• Runtime role is non-superuser/non-bypass; tenant/company/participant denial tests pass.
• App listener and database are the dedicated loopback services.
• Graph rebuild is scoped and does not replay business actions.
• Encrypted backup authenticates; separate-database restore drill passes; original database is preserved.
• Operator knows where secrets and keys are stored and how to retain them outside the public repository.
• User manual, tutorial, playbook, workbook/answer key and client examples are accessible.
• Portable requirement, verification and API-contract links open without the repository or application running.
• Known integration and production gaps have named owners and next decisions.

Production acceptance remains open

Complete the identity, evidence access/scanning, processing policy, retention/deletion/hold, hosting, secrets, off-host recovery, monitoring, security and accessibility work described in RELEASE-STATUS before client collection. Complete legitimate authority, staged approval, managed signing, exact adapter and reconciliation before business execution. No signature on this local checklist should be interpreted as approval of unimplemented production capabilities.

Before enabling Exa for an engagement, complete one authorized live-provider request with the project's credential and spending controls. Verify source lineage, retained excerpts, review state, visibility, sanitized failures and uncertain-result handling against INTEGRATIONS. Simulated-provider tests do not establish live account access, retrieval quality or charges.

Suggested handoff record

Build commit: ______

Advisor reviewer and date: ______

Operator reviewer and date: ______

Approved operating scope: ______

Unresolved defects and owners: ______

External integrations selected and funded: ______

Data/retention/hosting decision owner: ______

Next acceptance review: ______