Rehearse a bounded record
Use a discardable fixture. Record an opaque connection ID and reference-only grant label; never paste a token. Name the provider-specific request route, the state the service currently reports, the owner of the local connection record, a support escalation route, and a route that restores the fixture to pending.
Keep these statements separate:
| Observation | It does not establish |
|---|---|
| A user selected Disconnect | A provider received or completed revocation |
| A request route was recorded | The route fits every provider |
| A provider result was declared | The local record is reconciled |
| A local record is pending | The user remains logged in or out elsewhere |
Exercise the local receipt
node --test sites/howtox.com/evidence/P246/connection-revocation-receipt.test.mjs
The test accepts only a synthetic receipt with an opaque connection identity, reference-only grant label, provider route, bounded provider-result state, pending local reconciliation, owner, escalation, access-outcome limitation, and rollback. It does not call a provider, revoke a grant, change a session, or establish that access ended.
Hold the statement when the result is uncertain
If the provider route, result meaning, local record owner, or escalation path is unknown, retain a pending status and explain that the connection removal is still being reconciled. Complete user-account lifecycle testing is a useful related lifecycle check, but it does not establish third-party provider revocation. Do not borrow a promise from employee offboarding or service-credential rotation: those are different authority and lifecycle problems. A named identity or integration-platform operator must inspect the real implementation before this pattern informs a user-facing policy.