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

# Data flows

> Four journeys through Casa Conect, end to end: a message to the agent, a document becoming searchable, an inbound email, and a collaborative edit.

The quickest way to understand a system is to follow something through it. Each flow below notes where identity is checked and where limits apply.

## 1. A message to the agent

<Steps>
  <Step title="The request is verified">
    The dashboard sends your message to the API, which verifies your sign-in token, resolves your organization, and checks that the organization has Casa Conect OS with a subscription in good standing, and that you may use this conversation.
  </Step>

  <Step title="A session is started, or woken">
    Each conversation has one durable session on the background job platform. Sessions are spread across queues by organization, so one organization's burst fills only its own queue.
  </Step>

  <Step title="Identity is stamped by the server">
    Follow-up input to a running session passes through the API, which verifies you again and **rewrites the message's identity with values the server trusts**. A client cannot claim to be somebody else.
  </Step>

  <Step title="The agent is assembled for this request">
    The runtime builds the agent for this one turn: your identity and role, the mode and model you chose, the tools that fit the situation, your guidance and skills, and memory keyed to your organization *and* you. Every model call is admitted by the billing guard and metered.
  </Step>

  <Step title="The turn runs within its budgets">
    The agent works through its steps within its step and time limits. Content from outside parties is fenced as data. Actions that grant outsiders access, or send mail, pause for an approval card. The final step is reserved for a written reply.
  </Step>

  <Step title="The answer streams back">
    Output streams to your browser over a real-time channel, read with a short-lived token that is scoped to this one session and issued only after the same access check.
  </Step>
</Steps>

## 2. A document becoming searchable

<Steps>
  <Step title="Direct, signed upload">
    The browser asks the API for a signed, single-purpose upload link, then sends the file **straight to encrypted storage**. The file never passes through the application servers.
  </Step>

  <Step title="Malware scan">
    The object is scanned and tagged with a verdict. Nothing reads the file until the verdict is clean.
  </Step>

  <Step title="Queued once, from anywhere">
    Every upload surface calls the same function to queue indexing. If queuing fails, the upload itself is never failed by it. Continuous saves collapse into one indexing run.
  </Step>

  <Step title="Parse, divide, index">
    The job waits for the scan verdict, sends the file to the parsing service, with a more capable parser used automatically if the first reading is poor, divides the text into passages along the document's own structure, and indexes each passage for meaning and for words. Identifiers particular to Spanish property work are recognized and normalized.
  </Step>

  <Step title="Searchable">
    From then on the document is available to [search](/documents/search). Access is resolved first; then retrieval and reranking run within the authorized set.
  </Step>
</Steps>

## 3. An inbound email

<Steps>
  <Step title="Received and stored">
    The mail service receives the message, scans it, evaluates SPF, DKIM and DMARC, and stores it encrypted.
  </Step>

  <Step title="A pointer, not the message">
    A small relay notifies the API with a **pointer** to the message, never the message itself. The notification is authenticated and capped in size **before** any of it is read.
  </Step>

  <Step title="Policy before parsing">
    The API removes duplicates and applies the drop rules from the scan verdicts, and only then fetches and parses the message. Hostile mail is never opened.
  </Step>

  <Step title="Routing and threading">
    The recipient decides the destination: an agent address, a verified customer domain, or a personal docs address. The message joins its thread by its reply headers first, then by subject among recent threads with the same counterparty.
  </Step>

  <Step title="Gating">
    Your [sender rules](/inbox/sender-rules) decide whether the message is handled, held or dropped.
  </Step>

  <Step title="An unattended turn">
    The agent runs on the same session machinery in unattended mode: a smaller step budget, a reduced set of tools, the body fenced as untrusted data, and loop guards. Replies go out through the mail service, after approval where your policy requires it.
  </Step>
</Steps>

## 4. A collaborative edit

<Steps>
  <Step title="The document exists first">
    The API creates the document's record **before** anyone connects. The collaboration server refuses to open a name that has no record, so an edit can never land in a phantom document that is never saved.
  </Step>

  <Step title="A token for one document">
    The API issues a short-lived token that lists exactly which documents you may open. Your identity and entitlement were already checked when it was issued.
  </Step>

  <Step title="Connection">
    Your browser opens a secure connection through the edge. The server checks where the connection comes from, verifies the token, and confirms that the document is on its list.
  </Step>

  <Step title="Editing">
    Each keystroke becomes a small update that merges without conflict, is broadcast to the other editors in the document, and is relayed to editors connected to other servers.
  </Step>

  <Step title="Saving">
    Changes are written back continuously as the authoritative collaborative state, with a plain copy alongside for readers that do not need the collaborative form. On shutdown the server writes out everything pending before it stops, so work in flight is not lost.
  </Step>
</Steps>