> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Transformation and delivery > Understand how served and connected data become derived tables, and exactly what a managed delivery writes to your storage, when, and in what shape. Nexio turns connected data into two kinds of output beyond the [served-data reads](/connections/served-data). **Derivations** compute derived tables from your sources inside the platform. **Managed delivery** writes a versioned, verified set of tables to storage you own, on a daily schedule, with a record of what was held back and why. Nexio runs both for you, and a delivery goes to storage you own and name. Neither has a public API: you read the results where they are written. ## Derivations A derivation is one declared table the platform produces from sources it reads: your warehouse, your document library, reference data, or an external provider. Each derivation declares the checks its output must pass, such as a minimum group size so no row describes too few people or accounts. Nexio arms each derivation per connection with a schedule, and its output reaches you through the reads and deliveries built on it. A derivation run's result is published as a `sync.run_completed` [platform event](/events/platform-events) with `run_kind` `derivation`: | Status | Meaning | | ----------- | -------------------------------------------------------------------------------------------- | | `succeeded` | The run finished and no blocking check stopped it. Its output is published. | | `failed` | The run errored. Its output is not published. | | `refused` | A blocking check failed, or that output had already been produced. Nothing new is published. | ## Managed delivery Managed delivery writes your served document data, with its evidence and verification labels, to storage you own. It is available today. The destination is your storage, at the root path and table prefix you choose; Nexio runs the delivery job and writes there, you read, and nothing is pulled from your side. Destinations are a fixed set of supported types. Today the supported destination type is Azure Blob Storage, written over SFTP. ### How it works 1. **One snapshot.** Every table in a delivery is read inside one read-only, serializable database transaction. The transaction's timestamp is the delivery's watermark, stamped on every row as `SNAPSHOT_AT`. A join across delivered tables cannot reach a row that did not exist when another was read. 2. **Release check.** Before any file is written, the delivery evaluates its release rules against the snapshot. A failed rule refuses the whole delivery: nothing is written and your storage keeps pointing at the previous delivery. The one exception is the verification rule, which labels every row with its verification tier instead of refusing. 3. **Hold open items.** In the record families a delivery holds (fixed in code for each document profile), a record with an open review item (a pending review at the record, or an unresolved disagreement between two model readings anywhere in its source document) is left out and listed in the exclusion list with the reason. 4. **Write each file atomically.** Each file is uploaded under a temporary name and renamed only after all its bytes are sent. You never see a partial file under a delivered name. 5. **Move the pointer.** `deliveries/LATEST` is rewritten only after every file has been read back and its size and SHA-256 match what was sent. A delivery that fails before that point leaves `LATEST` naming the previous delivery; a partial directory it wrote is left in place under an id nothing points at. 6. **Copy the documents.** After `LATEST` moves, every document in the connection's document library is copied under `documents/`, named by its content hash. A failure here does not undo the tables: `LATEST` already names the new delivery, and a document it cites can be missing until the next run copies it. ### What is written to your storage A delivery contains the data tables built from the served records of the connection's document profile, a document catalog table, and the files below. The set of data tables is fixed in code for each document profile. ```text theme={null} deliveries/ LATEST id of the newest complete delivery 2030-01-01T0000Z/ _.csv + .parquet (one pair per data table) _DOCUMENT_CATALOG.csv + .parquet _EXCLUSION_MANIFEST.csv the exclusion list _DELIVERIES.csv index of the tables in this delivery DELIVERY_NOTES.md column and status definitions DELIVERY_REPORT.html human-readable summary _summary.json the delivery record LOAD_KIT/ Snowflake scripts to load this delivery documents/ the source documents themselves ``` * The delivery id is the watermark to the minute (`YYYY-MM-DDTHHMMZ`), so a directory listing is in time order. * `` is the table-name prefix you chose for your organization (see [What you provide](#what-you-provide)). It appears in file names, and in the table, stage and file format names the load kit creates. * Each data table is written as CSV and Parquet from one column declaration, so the two formats and the load kit's table definitions cannot disagree. * `LOAD_KIT/` holds numbered SQL scripts: session setup, file format and stage, control tables, one script per table, and a final verification script. ### Column groups Data tables carry these groups in this order, with the table's own columns between Identity and Evidence. A table whose records belong to a counterparty carries a counterparty group between Identity and its own columns. The document catalog table, and any table its document profile defines as catalog-shaped, carry only the identity group, their own columns, and `VERSION`, `SNAPSHOT_AT`, `DELIVERY_ID` and `DELIVERY_SCOPE`. | Group | Columns | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity | `ORG_ID`, `CONNECTION_ID`, and the row's own id. | | Evidence | `EVIDENCE_QUOTE`, `EVIDENCE_PAGE`, `CONFIDENCE`, `VERIFICATION`, `CORRECTED`, `SOURCE_BLOB_REF`, `SOURCE_REF`, `SOURCE_STATUS`, `SOURCE_REMOVED_AT`, `EXTRACTION_RUN_ID`, `DOC_EXTRACTION_ID`, `SCHEMA_VERSION`. The evidence text and page appear only where the source table carries them. | | Versioning | `VERSION`, `EFFECTIVE_FROM`, `EFFECTIVE_TO`, `SUPERSEDED_BY_VERSION`, `SNAPSHOT_AT`, `DELIVERY_ID`, `DELIVERY_SCOPE`. | `CONFIDENCE` is a reading confidence from 0 to 1, not a probability that the value is correct. An empty value is never a zero. ### Versioning Rows are versions. `VERSION` starts at 1 and increases each time a record is re-projected. An empty `EFFECTIVE_TO` means the row is current. The load kit's load step closes the prior version (sets `EFFECTIVE_TO` and `SUPERSEDED_BY_VERSION`) when it loads a newer one. A row of a held family whose source document was removed from your library is delivered already closed, with `EFFECTIVE_TO` set to that delivery's `SNAPSHOT_AT`. ### The verification column `VERIFICATION` says how much confirmation stands behind the row's critical figure, never that the figure is right. | Value | Meaning | | ----------- | ------------------------------------------------------------------------------------- | | `human` | A reviewer accepted or corrected the figure. | | `agreement` | Two different models read the stored text independently and returned the same figure. | | `single` | Neither. The default for most rows. | Tables with no per-field verification deliver `single`. See [Review](/connections/review) for how each tier is earned. ### The exclusion list The exclusion list names documents whose records are not delivered as current rows, with a status and a plain reason. It is read in the same snapshot as the tables. | Status | Meaning | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `duplicate-of` | A byte-identical copy of another document, which is delivered instead. The reason names it. | | `removed-at-source` | The document was removed from your library. Its rows are delivered closed. | | `quarantined` | The document was excluded from extraction, or failed blind re-verification. The reason says which. | | `not-yet-extracted` | The document has not been extracted yet. | | `not-served` | Lines were extracted from the document, but it has no current delivered rows. The reason gives the count. | | `pending-review` | Rows from the document held back because review items are open on them. The document's other rows are delivered. The reason gives the count. | A document is not listed because of the verification tier of its rows: the `VERIFICATION` column is the statement about them. ### The delivery record `_summary.json` is the machine-readable record of one delivery: | Field | Meaning | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | `org_id`, `connection_id` | Whose data this is. | | `delivery_id`, `delivery_number` | The id, and the count of deliveries so far (1 for the first). | | `delivery_scope` | `FULL` or `PARTIAL`. | | `snapshot_at`, `generated_at` | The watermark, and when the delivery was generated. | | `supersedes` | The delivery id this one replaces. Empty on the first delivery. | | `files` | Each file's name, label, row count and bytes. | | One entry per data table, and `catalog` | Per-table tallies. The entries for held families also count rows by verification tier and by source status. | | `manifest` | The exclusion list tally, by status. | | `measured_accuracy` | The weekly blind sample's pass rates, or a state saying accuracy is not yet measured. | To confirm a delivery is complete: read `LATEST`, open that directory's `_summary.json`, and check each file's row count against what you loaded. The load kit's verification script does this in Snowflake. ### Schedule Delivery runs at 06:00 UTC for each connection where Nexio has armed it: daily by default, or every few whole days. Scheduling is off by default and cannot be turned on until one manual delivery to your storage has completed cleanly. ### What you provide * A storage container with an SFTP endpoint and a login Nexio writes with. * Where Nexio writes (the root path) and the table prefix you want. How verification tiers and measured accuracy are earned. Read the same records through the API.