# Hatchways Trial Acceptance Checklist

Give a Hatchways product, reviewer-ops, or engineering owner a concrete pass/fail checklist for deciding whether the verified GitHub Actions fallback is enough to start a limited technical trial.

## Recommended Trial Boundary

One internal Hatchways-style candidate repo or synthetic invite-regression assessment; no production customer rollout and no enterprise procurement claim.

## Acceptance Checks

### Reviewer can make a first-pass decision from the packet.

- Pass signal: The reviewer can find hidden-test status, public test output, AI session evidence, git/test telemetry, anomaly context, and the ATS-ready note without asking for a live walkthrough.
- Proof: https://hottea.ai/sample-report
- Fail signal: The reviewer still needs a screen recording, live interview replay, or manual reconstruction of the repo work trail.

### Hatchways-style repo workflow remains intact.

- Pass signal: The trial can use candidate repo/PR metadata, GitHub Actions evidence, hidden grading summaries, and human review without replacing Hatchways task authoring.
- Proof: https://hottea.ai/hatchways/integration.md
- Fail signal: The trial requires moving candidates into a separate coding-test product or changing the assessment format.

### AI use is evidenced without proctoring claims.

- Pass signal: Claude JSONL exports, transcript counts, VM audit events, and process analysis show how the candidate used AI while avoiding outside-AI prevention claims.
- Proof: https://hottea.ai/hatchways/calibration.md
- Fail signal: The buyer needs locked-browser, screen recording, or perfect anti-cheat as the primary value proposition.

### Current account-level gaps are acceptable for a technical trial.

- Pass signal: GitHub Actions fallback is acceptable while real GitHub App creation, GITHUB_APP_INSTALL_URL, SSO, DPA, SOC 2, and retention SLA remain explicit gates.
- Proof: https://hottea.ai/hatchways/security.md
- Fail signal: Hatchways requires a real GitHub App or procurement artifacts before inspecting a public sample packet.

## Trial Inputs

- One Hatchways-style GitHub assessment or synthetic candidate repo.
- Expected public test command and hidden grading summary shape.
- One reviewer who can inspect /sample-report and answer the pilot questions.
- Decision on whether the report URL belongs in candidate instructions, PR summary, reviewer note, or ATS note.

## Go Decision

1. Run the limited technical trial through /github-action.yml if all acceptance checks pass.
2. Create the real GitHub App only after the fallback packet proves useful to a Hatchways reviewer.
3. Stop before app/procurement work if reviewers cannot use the packet within the 10-minute pilot kit.

## Current Blockers

- The real GitHub App still requires account-level creation and GITHUB_APP_INSTALL_URL deployment configuration.
- Until that app exists, GitHub Actions remains the verified fallback adapter.

## Not Claimed

- No official Hatchways partnership.
- No real GitHub App before GITHUB_APP_INSTALL_URL is configured.
- No perfect anti-cheat or outside-AI prevention.
- No automated hiring decision.
- No enterprise procurement readiness before the named gates are complete.

## Proof URLs

- Trial acceptance JSON: https://hottea.ai/hatchways/trial-acceptance.json
- Sample reviewer packet: https://hottea.ai/sample-report
- Integration guide: https://hottea.ai/hatchways/integration.md
- Calibration packet: https://hottea.ai/hatchways/calibration.md
- Security packet: https://hottea.ai/hatchways/security.md
- Pilot kit: https://hottea.ai/hatchways/pilot.md