> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

Operate EmailOS by checking each approved Mac, keeping permissions narrow, and recording the next action when a result needs review. This guide separates team administration from local account and connection work.

## Administer the right scope

Start with the organisation, person, and Mac you intend to review. In the portal, confirm membership, role, licence or seat context, approved-device metadata, and visible support or receipt references. An administrator view is not a remote inbox and does not turn a role into permission for every operation.

Keep one owner for each change. A team owner or administrator can coordinate access and setup under the organisation’s policy; the person working in EmailOS remains responsible for checking local permissions, connected sources, and the review decision. If a control is absent or asks for approval you cannot establish, record that state and hand it to the owner.

For a new Mac, confirm the intended organisation and account, then check local setup before adding a source. Keep provider credentials in the authorization flow.

## Observe evidence before changing anything

Use the smallest evidence set that answers the question: Mac or account, app version/build when visible, approximate time, affected area, and displayed state. Do not treat a label, old screenshot, or previous approval as proof of the current runtime state.

When a Lithi Doctor run is available to your team, it is a read-only check. It reports an overall status, details for each check, and a next action. A warning, failure, or unknown needs review before you widen scope. Doctor does not change permissions or read private content.

Compare evidence in the same scope and time window. A portal device record can identify which Mac to inspect, but cannot prove that a local model, mailbox permission, or provider connection is ready. A receipt or support reference shows that a bounded event was recorded; it does not complete the source or grant access.

## Diagnose bounded failures

Diagnose from the visible state outward. Confirm the account, organisation, and Mac, then check local app state, the relevant macOS System Settings permission, and the source or model state named by the error. If evidence says **unknown**, treat it as unresolved rather than guessing. If a step waits for approval, use the organisation’s normal process.

For an integration problem, review the connection’s scope from EmailOS → Settings → Integrations and use the source’s own re-authorisation flow when presented. Do not copy data into another tool to bypass a denied scope. If a credential may be compromised, remove the affected device through your organisation’s process and rotate it with the issuing provider; Lithi does not revoke credentials it did not issue.

For a support handoff, describe what happened, what you expected, when it occurred, and the redacted message shown by the product. Leave out message bodies, draft text, attachments, passwords, access tokens, recovery codes, and unrelated local files.

## Revoke access and decommission

Revoke the narrowest thing that no longer has a purpose. An owner or administrator can remove a person through the team workflow; portal access is revoked and the organisation keeps the relevant audit trail. For a source, use its local connection controls and follow the source’s revocation path. A revoked grant is not active approval for a new request, even if an older result still appears locally.

When retiring a Mac, identify its account and device record, stop relying on it for new review work, and follow the organisation’s device and mailbox process. Do not erase local evidence while an incident, support case, or export request depends on it. For an organisation wind-down, the owner should use the documented pause or deletion process and wait for confirmation; submission is not completion.

## Preserve bounded evidence

Keep the event or support reference, app version, timestamp, affected scope, visible state, and next action. Share only a redacted bundle when support asks. Keep private work and credentials out of it.

## Common problems and next steps

If a Mac is missing, check the signed-in account and visible device state before repeating setup. If Doctor needs review, follow its next action and capture the result. If a connection is denied, narrow the scope or use its authorization flow.