# Beacon first-release acceptance

Recorded 13 September 2026. **Status: incomplete.** This defines the useful
first-release outcome; it is not a new test registry or a certificate of release.

## Purpose and minimum outcome

A team handles customer email and first-party chat as conversations; accountable case work is separately raised when needed.

- Verified email and first-party chat persist and thread communication; a permitted operator reviews and sends a reply. A conversation with zero cases remains a complete, useful path (CHAN, WIDGET, CONV, OUT).
- Explicitly raised cases retain their accountable history and type boundaries. Tracker information never reaches customers; Back-office cases remain private. Human review gates customer sends and every enabled provider mutation; approval and acceptance never become invented provider success (CASE, EVID, APPR, ACT, RCPT).

A complete first release also requires an honest empty installation, owner-controlled
setup and repeat deployment preserving data, authenticated and authorized access,
input/privacy boundaries, recoverable failures and data export/restore appropriate
to its stored data. Verify these in the real runtime with the selected providers,
including desktop/mobile use. Applicable guarantees in [BASELINE.md](BASELINE.md)
remain obligations. A missing proof is open, not passing or automatically waived.

## Unmet release obligations

The zero-case pilot and local registry cover bounded paths. Complete selected-channel delivery/access/reconnect behavior, conversation/case privacy and recovery evidence remain obligations. Unconfigured operations are unavailable. The handover records seven full product clauses and 169 TODO; passing bounded baseline tests cannot satisfy the strict report.

## Preserved wider requirements

Knowledge and AI preparation, concrete optional provider operations, full reporting/notifications, customer administration and authentic Intercom import remain open in KNOW, AI, JUDG, ACT, ANALYTICS, NOTIFY, CUST and IMPORT. Any enabled slice must meet its safety and truth requirements.

[CONTRACT.md](CONTRACT.md) remains unchanged and authoritative for its declared
guarantees, including any full-1.0 release conditions. This narrower first-release
profile prioritizes a useful outcome; it does not reclassify clauses, waive an
owner requirement, or authorize a full-1.0 label. A conflict with an existing release
condition remains explicit and unresolved until its scope is deliberately settled.
All unmapped clauses remain in the original contract with their existing status.

## Evidence and decision rule

Read [the handover](HANDOVER.md) and [dated pilot evidence](HANDOVER.md) for exact
source versions, executed checks and limitations. These are historical receipts,
not a fresh verification of this document's candidate. Publication is independent
of deployment and product acceptance; a published tree is not a release verdict.

Report four separate results: executed gates (including failures and skips), unmet
first-release obligations, preserved wider backlog, and external unknowns. A green
`verify` proves only its executed gates. Mark this first release complete only when
its minimum outcome and applicable guarantees have evidence on the exact candidate,
remaining scope conflicts are resolved, and every external claim names what was
actually observed. Provider acceptance alone never proves mailbox delivery or a
confirmed business effect. Retain test-session and test-mode limitations.