# Commands and recovery

Every controlled write uses the common command receipt protocol. Console, REST and MCP use the same command identity and business effect. The server derives account and operator identity from current authentication, never from a caller-supplied actor field.

## Canonical identity

The key is `v1.<Unix milliseconds>.<random base64url nonce>`. Its whole-key hash identifies the command. Changing the timestamp creates another key; it does not extend the lifetime of the original command. New acceptance is allowed for 24 hours, with at most five minutes of future clock skew checked against the database clock.

Recover an existing receipt even after its acceptance deadline. An overdue request with no retained receipt cannot be accepted again.

## Outcomes

| Outcome | Meaning and next step |
|---|---|
| accepted | This command was accepted. Follow its object references; current object state is separate. |
| rejected | A specific business rule refused the command and no business side effects were committed. Correct the issue before a new command. |
| processing | An external result is pending. Explicitly check again after Retry-After; never change the key. |
| unknown | The command may still be in flight. Recover the original key or explicitly seal while its acceptance window remains open. |
| not_accepted_final | A timely, atomic seal proves this key will not be accepted. Re-enter inputs before using a new key. |
| receipt_expired | The old receipt is absent after its acceptance window. Acceptance cannot be established. Inspect related object lists or contact support. |

## Explicit final seal

When you choose to abandon an unknown request, send `POST /v1/commands/{kind}/{key}/seal` with an empty JSON object. Console uses the equivalent authenticated Console route. The server arbitrates the seal against any in-flight submitter and checks the database clock again after acquiring the receipt lock.

A seal cannot override accepted, rejected or processing facts. After the acceptance deadline, an absent receipt returns `receipt_expired`; it can never establish final nonacceptance.

## What is retained

Receipts retain the normalized request digest, safe object references, reasons and times. They contain no original input, API Key secret or bearer download link. Terminal receipts remain for at least seven days after their terminal time, and cleanup additionally requires the acceptance deadline to have passed. Processing receipts are not cleaned while unresolved.

The browser retains only account-scoped pending command metadata. It does not retain or automatically replay the input body. API Key plaintext is shown once on initial creation and cannot be recovered; revoke and create a new key if it was lost.

## Technical failures

A technical exception, timeout, lock conflict or connection failure rolls back the transaction. It is not recorded as a business rejection. Financial and task facts, audits, outbox entries and the accepted receipt commit together. A lost response may still follow a committed acceptance, so check the original receipt before doing new work.