# Hatchways Data Retention Packet

Name exactly what HotTea stores during a limited Hatchways-style technical pilot, how it can be reviewed, and which retention/compliance claims are not made yet.

Boundary: One synthetic or internal Hatchways-style repo assessment, one reviewer owner, GitHub Actions fallback only, no production candidate traffic, and no enterprise procurement claim.

## Stored Artifacts

### candidate session metadata

- Examples: session id, candidate email, assessment id, status, timestamps
- Review surface: tokenized reviewer report and JSON report

### assessment task data

- Examples: repo URL, instructions, public test command, hidden-test summary
- Review surface: candidate task packet and reviewer report

### AI session evidence

- Examples: Claude JSONL exports, Codex/Claude wrapper events, external transcript uploads
- Review surface: sample report, session exports, GitHub Action evidence payload

### engineering telemetry

- Examples: terminal logs, git snapshots, test output, diff notes, VM event timeline
- Review surface: reviewer packet and sample evidence JSON

### reviewer-only evidence

- Examples: hidden-test result summary, reviewer scores, interview transcript placeholder
- Review surface: tokenized reviewer report only

## Deletion And Cleanup Paths

### /api/vm/teardown-expired

- Scope: Expired or submitted candidate VMs
- Authentication: system bearer token required
- Proof: https://hottea.ai/vm/lifecycle.md

### workspace lifecycle state

- Scope: Submitted sessions mark VM teardown due when autoTeardownVmOnSubmit is enabled
- Authentication: server-side state transition
- Proof: https://hottea.ai/vm/lifecycle.json

### future account-level deletion

- Scope: Pilot data deletion and retention SLA need a product owner policy before enterprise rollout
- Authentication: not currently claimed
- Proof: https://hottea.ai/hatchways/security.md

## Buyer Review Questions

- Is this data shape acceptable for one synthetic/internal technical pilot?
- Does Hatchways require deletion within a fixed number of days before any pilot?
- Which artifacts should be excluded from a partner pilot: terminal logs, Claude JSONL exports, interview transcript placeholders, or hidden-test summaries?
- Is the GitHub Actions fallback enough to validate evidence usefulness before a real GitHub App stores installation-scoped metadata?

## Current Controls

- Candidate and reviewer links are tokenized.
- Secrets are blocked/redacted before agent prompts are accepted.
- System VM cleanup endpoint requires authentication.
- Public proof routes render sample or configuration data, not live candidate records.
- Reviewer packets are aids for human review, not automated hiring decisions.

## Current Gates

- Formal retention SLA is not complete.
- Customer data deletion API is not complete.
- DPA, SOC 2, SSO, and enterprise vendor review are not complete.
- Real GitHub App storage boundaries are not claimable until GITHUB_APP_INSTALL_URL is configured and app webhooks exist.

## Not Claimed

- No enterprise retention SLA.
- No DPA, SOC 2, SSO, or completed vendor security review.
- No production customer rollout.
- No official Hatchways partnership.
- No real GitHub App before GITHUB_APP_INSTALL_URL is configured.
- No automated hiring decision.

## Proof URLs

- Data retention JSON: https://hottea.ai/hatchways/data-retention.json
- VM lifecycle proof: https://hottea.ai/vm/lifecycle.md
- Security packet: https://hottea.ai/hatchways/security.md
- Sample reviewer packet: https://hottea.ai/sample-report
- API config: https://hottea.ai/api/config