> ## Documentation Index > Fetch the complete documentation index at: https://docs.anthid.com/llms.txt > Use this file to discover all available pages before exploring further. # Recorded before acknowledged: why an instruction and its execution fail independently > How Anthid orders the record and the execution of an instruction, what that ordering rules out, and what it lets you answer when nothing came back from the broker Anthid writes your instruction to a durable record before it tells you the instruction was accepted, and before it contacts a broker. That ordering is the rule the rest of the execution layer is built around. This article explains why it matters, what it rules out, and what it lets you answer on the day something goes wrong. ## An instruction and its outcome fail independently Most broker APIs give you one object. You send an order, and what comes back is both your request and the live state of that order at the venue. While that is convenient, it collapses two things that do not fail together. A broker can be unreachable. It can reject an order. It can acknowledge an order and then lose it. It can fill an order hours later. In every one of those cases your instruction was real, was authorized, and was acted on by the platform. A model where the record begins only once the broker accepts cannot describe the moment in between, and it cannot answer the question a review asks first: what was attempted when nothing came back? Anthid keeps the two apart. An [intent](/pages/concepts/intents) is what you asked for. An [order](/pages/concepts/orders) is what came of it at the broker. The intent exists first, and it exists whether or not an order ever does. ## What "recorded before acknowledged" means in practice When you submit an intent, Anthid commits it to an append-only event stream in the same database transaction that queues it for execution. You receive a response only after that transaction commits. ```bash theme={null} curl https://api.anthid.com/v1/intents \ -X POST \ -H "x-api-key: " \ -H "Content-Type: application/json" \ -d '{ "trading_account_id": "", "command": { "type": "CREATE", "payload": { "symbol": "AAPL", "order_side": "BUY", "spec": { "Limit": { "price": "100.00", "quantity": "10", "time_in_force": "DAY" } } } } }' ``` ```json theme={null} { "intent_id": "019c0538-86f2-7c32-9c1e-6f79cbfdb7b4" } ``` That response is a receipt for the record, not for the fill. It says three things: your controls allowed the instruction, the instruction is now durable, and the work to carry it to the broker is queued. It says nothing about execution yet, and it is not supposed to. See [SENT is not FILLED](/pages/blog/articles/sent-is-not-filled) for how execution is reported. Because the record and the queue entry are one transaction, there is no window in which an instruction is in flight but unrecorded. Either both exist or neither does. No order can reach a broker through Anthid without a record that says who asked for it. ## The record cannot be rewritten The instruction stream is append-only, and that is enforced by the database rather than by application code. A trigger rejects any attempt to update or delete a row. The application has no path to modify a recorded instruction, and neither does an ordinary database session. Corrections are not edits. A replace or a cancel is appended as a new, sequenced action against the same intent, carrying the credential that sent it. Amend an order twice and then pull it, and the intent holds four actions in order: the create, two replaces, and the cancel. Read them back with one call. ```bash theme={null} curl "https://api.anthid.com/v1/intents//actions" \ -H "x-api-key: " ``` A `REPLACE` carries a complete order specification, not a patch. Fields left out of the replacement are not inherited from the original. The record keeps every version, so the history shows exactly what each amendment asked for, but a replace that names only a new price will not preserve the original quantity. See the [Intents API](/api-reference/intents/overview). ## What each record carries A record is only useful in a dispute if it can say who, when, and from where. Every action carries: | Field | What it establishes | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Resolved order payload | The instruction exactly as Anthid understood it | | Action type and sequence | Create, replace, or cancel, and its position in the intent's history | | Credential | Which of your credentials sent it, and of what kind: an API key, a signed-in user, or an Anthid service acting for you | | Client reference | Your own correlation identifier, carried unchanged through every later action | | Request identifier | Ties the record to the single request that produced it | | Arrival and write timestamps | When the request reached the edge, recorded separately from when the row was committed | | Client address | The calling address as observed at the network edge, never from a caller-supplied header | Attribution is taken from the request every time and never inherited from the thing being changed. One credential cancelling what another credential placed is visible rather than hidden. That is the half of a disputed order that turns out to matter, and it cannot be reconstructed afterwards if it was not written at the time. ## Refusals are recorded too A record of what Anthid accepted is only half of what a supervisory review asks for. The other half is what it stopped. Submissions refused by your [controls](/pages/controls/overview), by an entitlement, or by authorization are written to their own append-only stream with the same attribution and the submission exactly as it arrived. A controls refusal carries the specific limits that triggered, which is the same detail the caller received. The record is written independently of the transaction the order would have used, so a refusal cannot be lost to the same rollback that discarded the order. ```bash theme={null} curl "https://api.anthid.com/v1/intents/rejections?stage=CONTROLS&days=7" \ -H "x-api-key: " ``` One case is worth stating plainly: an attempt to submit against an account your organization does not own is refused and recorded, with the credential behind it. The caller is told the account was not found. The record says what was tried. ## What this lets you answer Put the pieces together and the awkward questions get short answers. *The broker never responded.* The intent exists, its actions are recorded, and its dispatch state says how far the platform got. Nothing about the instruction depends on the broker having spoken. *Two systems trade the same account and one of them placed something it should not have.* The credential on the action says which one. The client reference says which run. *An order was amended and nobody remembers what it originally said.* The action chain holds every version in sequence. *A limit blocked an order last Tuesday and someone wants to know why.* The refusal record names the controls that fired, and the control change stream says who set them and when. *A regulator asks two years from now.* The instruction stream is retained for six years, with the attribution intact. See [Compliance](/pages/about/compliance) for the full retention model. ## Why this makes the broker a setting The same separation is what keeps the layer broker-agnostic. An intent is expressed in Anthid's own terms and recorded that way. It is translated into a broker's dialect only at routing time, which is after the record exists. So the instruction reads the same whether it goes to [Alpaca](/pages/brokers/alpaca) or [Lightspeed](/pages/brokers/lightspeed-connect), and the record of it does not change when the account behind it does. The model in detail: intents, actions, dispatch, and outcome. What is recorded, how it is protected, and how long it is kept.