> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Inspect your data before you upload it description: >- Find your unit of work, your schema and your sensitive fields on your own machine, before anything is uploaded. Bound every sample, and record who inspected what. route: /docs/compute/inputs/local-inspection page_id: docs-compute-inputs-local-inspection page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Compute customers preparing a first input, and the AI agents helping them voice: D reader_question: How do I understand my own data before any of it leaves my machine? primary_action: Choose the field that identifies each item source_locale: en-US source_status: APPROVED source_version: docs-compute-inputs-local-inspection-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you start Work from a real sample, on a machine you control. You also need the workflow descriptor and its generated `parameters_schema`, so you know what the workflow expects to read. Nothing on this page uploads anything. Local inspection sends no bytes and costs nothing. ## Find the unit, the schema and the sensitive fields Three answers decide the whole submission. The unit is one item of work: one row, one document, one recording. Name it first, because price, failures and results are all counted per unit. The schema is the exact set of fields, their types and their encodings. Read it off the data itself, not off the documentation someone wrote for it two years ago. The sensitive fields are the ones you must remove, pseudonymize or get approved before they leave your machine. ## Inspect locally Run the local commands against your sample: ```bash lithi inspect lithi assess lithi dataset validate lithi media inspect ``` They read your files where they already sit. Then classify what you found against the data profiles, so `shared_public`, `shared_deidentified` and `shared_customer_approved` content stays separate from anything that belongs in `rejected_regulated_secret` or `rejected_credential`. A credential is never an input. It is refused rather than carried, and a request references a secret by `credential_ref` instead. See [what each data profile permits](/docs/compute/security/data-profiles). ## Bound every sample Read a fixed number of records from a fixed point, then stop. An open-ended read over a live source is slow on your side and impossible to repeat exactly. Choose a sample that is small and deliberately awkward. Include the longest value, an empty field, a repeated-looking identifier and a non-English value. Twenty records chosen that way teach you more than twenty thousand chosen at random. ## When an agent inspects the content for you You can ask your own AI agent to read the sample and describe it. That agent is your tool. It runs under your permissions, with your credentials, on data Lithi has not received. Those two facts are not the same fact. "Lithi has not received it" does not mean "no tool has seen it." The agent's provider, its logs and its context are yours to account for. So write it down. Record what the agent read and under whose authority, and get whatever approval your organization requires before pointing any agent at regulated or customer data. ## What success looks like You can state the unit in one sentence. The schema is written down. You know which fields are excluded, which are pseudonymized and which are approved to send. You have also chosen the field that will become `item_id_field`, and you hold the digest of the exact bytes you inspected. ## If inspection cannot settle something Ask once, with named options, rather than guessing. Two date columns of the same type is a real question. One obvious column is not. If the data is the problem — a missing identifier, an unreadable encoding — fix it at the source before you upload. A defect carried into a run comes back as a per-item failure you still have to reconcile, after you have paid for the attempt. Next, pick the identifier that will carry every result back to your records: [how item identity works](/docs/compute/inputs/item-identity).