> ## Documentation Index > Fetch the complete documentation index at: https://docs.merchantops.ai/llms.txt > Use this file to discover all available pages before exploring further. # Lakehouse ingestion > Decide when an extracted product PDF pauses for a human to approve it before its data enters the lakehouse. When you upload a product PDF, MerchantOps extracts the products and technologies it finds — and then, by default, **stops and waits for a person** before writing any of it to the [lakehouse](/data-ingestion/lakehouse). Lakehouse ingestion settings are where you decide when that pause happens. This page is for owners and admins; you need settings permission to view these controls and edit them. The platform default is **not** "ingest everything automatically". A new organization is on *Review only below a confidence threshold* at **80%**, and that setting parks a great many real-world product PDFs — so if you upload a PDF and its products never appear in the lakehouse, the usual explanation is that the document is parked waiting for your approval, not that extraction failed. ## The three review modes Every product PDF waits for a reviewer, whatever the extraction looked like. Documents that clear the confidence threshold are ingested automatically; the rest pause. This is the default, at 80%. Extracted data goes straight into the lakehouse. Products still carry a confidence score and can be reviewed afterwards in the Product Explorer. The setting applies to **product PDFs only**. Spreadsheets have their own, separate human-in-the-loop step — the column-mapping review that runs *before* extraction — and MAP pricing documents are not covered by this gate at all. See [The Lakehouse](/data-ingestion/lakehouse) for both. ## What the threshold actually compares The confidence threshold is a slider from 50% to 100%, and it is used **only** by threshold mode. It is compared against the document's confidence, which is the score of its **weakest** product — not an average. One bad product parks the whole document. A catalog of forty clean products and one garbled one has a document confidence equal to that one garbled product, so it pauses. A product's score is built from how complete the extraction is: whether it has a name, a vendor style ID, a description, enough features, enough specifications, and a confirmed brand. The number is not the only thing threshold mode looks at, though. It also parks a document — **whatever the threshold is set to** — when: * it extracted **zero products**; * the PDF had **blank pages skipped** or needed **repair** before it could be read; * the document's **brand couldn't be confirmed**; or * **any product is missing its vendor style ID**. That last one is the one that surprises people. A document containing a product with no vendor style ID parks in threshold mode at **any** threshold — the check is separate from the number, so lowering the slider will not let it through. If your source PDFs don't print style codes, expect every one of them to wait for a person; the only ways around it are switching the mode to **Never** (for the organization or for that one upload) or getting style codes into the documents. A style code MerchantOps recovers from the **filename** counts, and doesn't trip this. ## Which setting wins for a given upload A PDF resolves its rule in one order, most specific first: The upload dialog offers a per-upload review mode for product PDFs. Leaving it on **Use organization default** records no override at all — the dialog shows you inline what you're inheriting. The mode and threshold saved on this page. Threshold review at 80%, for an organization that has never saved a setting. A per-upload choice covers that upload only — it never changes the organization's saved setting. Saving a new setting here applies to **future** uploads; documents already waiting keep the rule they were staged under. ## The extraction verification judge An optional switch runs a verification pass over the extracted products, comparing them against the images of the pages they came from to catch products the extractor invented. It costs one extra vision call per batch of pages and is **off by default**. Its findings appear as review reasons on the affected products rather than silently changing anything. ## Reviewing a parked document A document that parks shows as awaiting review, and its [job](/jobs/overview) sits at **Awaiting review** until someone resolves it — the job cannot finish on its own. Open the document's extraction review page from the job or from the documents list. You need lakehouse read permission to open it and lakehouse write permission to act on it. The review page puts the extracted drafts beside the PDF itself, so you can check a claim against the page it came from. Opening a product jumps the viewer to the page it was extracted from. From there you can: Decide product by product what gets committed. Dropped drafts are simply not written. Your corrections layer over what the extractor produced — the original extraction is never altered, and the edits are applied at commit. If the wrong brand was detected, set the right one. This changes the keys the document writes, so the create-or-merge forecast on screen updates with it. Commits the kept products and technologies. The button states exactly how many of each it will write before you press it. Nothing from the extraction is written, the document is marked rejected, and its job settles. A reason is required and is stored on the document. There is no un-reject. Recovering a rejected document means reprocessing it, which re-extracts from scratch — any edits made during the review are lost. Once a document has been approved, committed, or rejected, its review page stays readable as a record of what was decided, but the actions are gone. ## Reprocess The document detail page offers **Reprocess** on a product PDF that isn't currently being worked on — it's the recovery path for a document that failed to extract, extracted badly, or was rejected. You need upload permission to use it. Reprocessing re-extracts the document from scratch and **replaces** any staged draft, so a review in progress is discarded. It re-uses the same document rather than creating a new one, and the document keeps pointing at the run that produced its current state — so you follow it from the document, not by hunting for a second upload. ## Related What the lakehouse holds and how documents get into it. Why a job sits at **Awaiting review**, and how to clear it. Once data is committed, what your organization shares from it. What enrichment does with the lakehouse data you approve.