# Task27 final bounded-pilot release verdict

## Verdict

**GO for one explicitly consenting bounded pilot customer only.**

Candidate:
`d1109d8f78aaccf949ec4f664d9e62584c3cca33032030518bc3e2d712239112`

Delivered root:
`.omo/evidence/task26/task26-combined-v38-delivered-st_01a019d7`

This report supersedes the suspended initial verdict for pilot-readiness assessment. It
does not activate a customer, start a service, contact Telegram or a provider, deliver a
message, release code, commit, or push. Every customer-facing operation still requires
its normal permission-sealed preflight and explicit owner/operator action.

## Exact candidate and provenance

- Hermes wheel:
  `f8b3c779c58435dd33f8f9bbc89e9823bd09f81367a27366c6d678270c1860b1`
- Profile wheel:
  `a56da2417df0912f3fe407c0b78befd7362207d1c8a35271000af46701ba79d2`
- Postfreeze seal:
  `3002d815d7523c2971c990544d92c1f0d16fd51781f83d9d636ef6336b5878f6`
- Delivered-bundle seal:
  `54be54cf89720057486596a21941ec5d456a1c54148f66dbde0475503a752f67`
- Independent verifier:
  `TASK26_INDEPENDENT_CANDIDATE_PASS`
- Frozen bootstrap:
  `TASK26_FROZEN_BOOTSTRAP_PASS`
- Installed Golden Path:
  `ACTUAL_INSTALLED_GOLDEN_PATH_PASS`

The historical suspension remains preserved at
`.omo/evidence/task27/task27-v38-verdict-suspension.json`
(`9be5a187ace59a72099ace5262923cfee0ca96d7c5971608e87eb2ef53d23a87`).

## Privacy and authority architecture

- Customer delivery uses a private customer DM.
- Owner/operator review remains on customer-free staff surfaces.
- No shared customer group is supported.
- Owner/operator is the sole v1 nutrition review authority.
- No active trainer marker, role, route, claim, invite, card, data-access path, review,
  readiness requirement, activation requirement, or safety-hold path exists.
- Wrong-role, stale, duplicate, wrong-chat, and wrong-topic actions fail closed.
- The rehearsal customer is disabled and nonconsenting.
- Customer, bootstrap, publication-outbox, and staff-membership operational roots are
  absent.
- Retained trainer-named rehearsal archives and legacy `gate_d` migration files are
  historical evidence only; without a matching enabled registry/customer/journal graph
  they grant no runtime authority.

## Automated qualification

The immutable candidate retains the following sealed results:

| Gate | Result |
|---|---:|
| Actual isolated profile qualification | 749 passed |
| Focused Task26 | 306 passed |
| Expanded Task26 | 76 passed |
| Parser source | 204 passed |
| Parser installed | 204 passed |
| Related lifecycle | 131 passed |
| Full Gateway | 8,552 passed, 0 failed |
| Direct-URL attacks | 32 passed |
| Ty target attacks | 14 passed |
| Supplemental cleanup suite | 22 passed |
| Supplemental controller compile | PASS |
| Supplemental controller/test LSP errors | 0 |
| Scoped Ruff and Ty gates | PASS |

Direct final commands:

```text
python3.12 -I verification-tools/independent_verify_candidate.py .
=> TASK26_INDEPENDENT_CANDIDATE_PASS

python3.12 -I verification-tools/task26_frozen_bootstrap.py .
=> TASK26_FROZEN_BOOTSTRAP_PASS
=> ACTUAL_INSTALLED_GOLDEN_PATH_PASS

sha256sum -c .omo/evidence/task27/receipt-hashes.sha256
=> every listed Task27 artifact OK
```

## Real-surface evidence

- The retained authorized synthetic Telegram lifecycle used customer DM
  `8527916639` and the owner/operator staff surface.
- Owner explicitly sent the approved coaching message.
- The customer observed provider message ID `157`.
- Exactly one `sent_audited` receipt and one synthetic customer delivery were recorded.
- Duplicate, stale, and wrong-role actions created no second delivery.
- Task24 real-surface evidence:
  `7431b043f1aa9f67481692ed3555f9072f091984b931e77041ee5aa50d2258b4`
- Task25 terminal evidence:
  `30275bb8a9d0637fb4b46889672105836f18baa64e02270f1a4728efe2d6378d`

No new Telegram, provider, activation, or delivery action was performed during final
cleanup or final verification.

## Exactly-once and recovery proof

- Delivery authority is claimed atomically before provider I/O.
- Approval alone sends nothing.
- Explicit send creates one provider message and one durable receipt.
- Duplicate send reuses or rejects the existing authority and never sends again.
- Unknown provider outcome consumes authority and is never blindly retried.
- Restart, stale callback, wrong actor, callback-expiry, provider-auth failure,
  generation-claim expiry, provider-success-before-receipt, and cleanup-resume paths
  are covered by the sealed recovery and adversarial matrices.
- Supplemental cleanup used one deterministic operation ID,
  `005a3c3f9897e2d298a9a7409759509e`.
- Its authorization was consumed on commit; reexecution returned exit code `2`.
- Faults after archive copy and source pruning restored exact pre-operation state in
  disposable tests.

## Cleanup state

Initial canonical cleanup receipt:
`7848def41100aa4f4ef27239dfaae3cc634d5ad2b24df7966d4d80838f692a3a`

Supplemental cleanup receipt:
`13b28b5745cf1fb6e8aa9457f14ad86dbf972c3c203394e2fd919d99b7bf659d`

Supplemental archive manifest:
`636acca796ef627cc488c85d5cbc79894eaaa1ee68bbd8660aaf7692d4b9b7e2`

- 26 committed publication receipts and one membership epoch were archived.
- Source and archive digests match exactly.
- Live publication-outbox and staff-membership roots are absent.
- Active target matches are zero.
- Customer remains `enabled=false`; AI-processing consent remains `granted=false`.
- Gateway is `inactive/dead`, `MainPID=0`, with no matching process.
- Other profiles remain byte-identical under aggregate digest
  `9096c74dac8583eb8186f37fcb15ac06ff13795269979af808dd0855d85b51b6`.
- Supplemental archive directories are `0500`, files are `0400`, with zero writable
  entries and zero symlinks.

## Final independent reviewers

Fresh post-supplemental verification:

| Lane | Receipt | Verdict |
|---|---|---|
| F1 objective and invariants | `task27-v38-final-verification-f1-supplemental.json` | PASS |
| F2 privacy and authority | `task27-v38-final-verification-f2-supplemental.json` | PASS |
| F3 reliability and exactly-once | `task27-v38-final-verification-f3-supplemental.json` | PASS |
| F4 real surfaces | `task27-v38-final-verification-f4-supplemental.json` | PASS |
| F5 cleanup and provenance | `task27-v38-final-verification-f5-supplemental.json` | PASS |

Consolidated receipt:
`.omo/evidence/task27/task27-v38-final-verification-consolidated.json`

## Bounded pilot scope

The only permitted initial rollout is:

1. one explicitly consenting pilot customer;
2. private customer DM and customer-free owner/operator staff surfaces;
3. no shared customer group;
4. this exact candidate and sealed wheels only;
5. daily owner/operator review during the observation window;
6. no expansion until the defined observation window is clean.

## Normal-surface pilot launch sequence

1. Run production readiness and provider-auth preflight against the exact candidate.
2. Present the preflight evidence for an explicit owner go/no-go decision.
3. Select exactly one consenting pilot customer and verify private-DM/staff membership
   isolation.
4. Issue one permission-sealed onboarding link.
5. Complete onboarding and attestation through the customer DM.
6. Complete customer check-in through the customer DM.
7. Observe automatic draft generation on the owner/operator surface.
8. Owner/operator reviews and explicitly approves the current draft.
9. Owner/operator explicitly sends to the customer.
10. Observe the durable `sent_audited` receipt and the matching customer-DM message.
11. Monitor authorization, duplication, delivery, provider, process, and cleanup signals
    through the bounded observation window.
12. On any rollback criterion, stop the gateway, disable delivery and the customer,
    archive receipts, and require a new candidate review before resuming.

## Immediate disable and rollback criteria

Immediately disable the pilot and stop further delivery on any:

- candidate, wheel, seal, authority, profile, route, or receipt mismatch;
- missing, expired, reused, duplicate, stale, or wrong-actor capability;
- unknown provider outcome, duplicate message, missing `sent_audited` receipt, or
  customer-surface mismatch;
- provider call without `store=false`;
- unexpected external destination;
- failed daily owner/operator review;
- service, process, FD, watcher, socket, pending, unknown, orphan, trainer, or writable
  residue;
- cleanup, archive, consent-withdrawal, or manifest-integrity failure.

Rollback is fail-closed: stop the gateway, disable delivery and the pilot customer,
revoke candidate authority, archive terminal receipts, and require a new immutable
candidate plus the full qualification and independent review before resuming.

## Residual risks

- Evidence is deterministic and owner-permission/hash sealed, not externally signed or
  WORM against a privileged host administrator.
- The 809 Ty diagnostics outside the selected capability/transport spans remain known
  technical debt; zero diagnostics occur inside those spans.
- Real-network proof is the retained authorized synthetic Telegram rehearsal.
- Supplemental rollback is process-local; a host power loss during mutation would
  require recovery from the byte-recoverable archive.
- A bounded pilot still depends on explicit customer consent, explicit owner decisions,
  daily review, and trusted-host operation.