Request list import from Excel

What the import gives you

You upload the Excel checklist. Back comes a structured request list: categories, topics beneath them, and the individual requests, each carrying its number in the file's own numbering format. You also get the column mapping the parse used and a preview of the parsed structure next to what was read out of the sheet.

Nothing is written to the deal at that point. The parse step creates no entries and does not file the workbook into the data room. It reads the upload, returns the parsed result, and stops. Creating the list is a separate confirm action, after you have looked at the preview.

Once confirmed, the items are real requests in the deal. They can be assigned and tracked, uploaded files are scored against them automatically, and they keep the numbering from the original spreadsheet, so your list and the client's file still refer to the same item by the same number.

What the model is sent, and what it is allowed to send back

This needs to be exact, because the whole design rests on it.

What goes to the model is a compact rendering of the workbook: every non-empty row of every tab, with column letters attached, each cell truncated to a short prefix, up to a fixed row cap per tab. That is a layout-detection sample, not a redacted one. Cell text does reach the model.

What comes back is a reading plan and nothing else. The response names which tabs hold requests, with a header row and a data start row for each. For each field, category, title, description, priority and folder hint, it returns a column index plus one mode from a closed vocabulary of five: read the value from a column, treat a repeated value in a column as the category, take the category from a sparse category row, take it from the name of the sheet, or leave the field unset. It also returns the header labels for the review screen and its own count of how many categories and requests it believes the file contains.

The application then executes that plan against the raw rows. The request text written into your list is the cell value, trimmed, with an inline ordinal optionally stripped off a category label. The truncation applies only to the sample the model sees. The description written into your list is the full cell value.

One practical note before you upload. Whatever the parse produces is shown to you in the preview before any request is created, so a column that does not come through the way you expect is visible at that point rather than after the list exists. If your checklist builds its request text out of other cells, paste that column as values first and read the preview before you confirm.

Why the direction of that flow matters on a confidential tracker

Two things follow from it, and they are different things.

The first is about correctness, and it is the stronger claim. A model asked to transcribe 140 requests can drop one, merge two that look alike, or tidy the wording of a third. None of those failures announce themselves. Weeks later nobody knows that item 4.7 was silently reworded or never created. Because the model here only describes where to read, that failure class does not exist. A wrong plan produces visibly wrong output: the wrong column, the wrong categories, or zero requests. It does not produce a list that looks correct but differs from the file you uploaded.

The second is about containment. A diligence tracker is untrusted input. It contains free text written by another firm, and that text goes into a model prompt. The closed vocabulary is the boundary. An unrecognised mode is rejected outright rather than interpreted, so the model cannot return an instruction the code would have to build an interpreter for. Validation also rejects a negative column index, rejects a category-only mode used on a per-row field, and normalises the case where the title column is pointed at the description column. The worst a hostile cell can do is influence which column gets read, and that shows up in the preview before you commit.

The limit of this design should be stated plainly. It reduces what the model produces. It does not reduce what the model reads. If your requirement is that no cell of a confidential tracker ever reaches a model at all, this import is not that, and you should file the checklist by hand. Our handling of data sent to model providers is on the security page.

How one plan covers templates that look nothing alike

Firms do not agree on how to lay out a due diligence questionnaire, and the three common shapes are structurally different files, not cosmetic variations. The mode vocabulary exists to name all three.

Some files repeat the category name in a column on every row, so a change in that value starts a new category. Some put categories on their own sparse rows, with an ordinal in one column and a name in another and the requests underneath, and the code confirms sparseness before believing it: a row qualifies only if almost every cell other than the ordinal and the name is empty. Some split the list one tab per workstream, so the tab itself is the category.

Tab selection is part of the same plan. Workbooks carry cover sheets, instruction tabs and summary tabs that count requests per category, and a summary tab parsed as a request list produces a short, confident, wrong import. The plan lists only the tabs holding requests, each with its own header and data start row, and everything else in the workbook is ignored. Row numbers are resolved per tab, which matters because a header on row 4 of one tab means nothing on another.

Small details do a lot of work here. Category labels routinely carry their own numbering inline, so "1. Corporate Matters" becomes "Corporate Matters". The ordinal test requires the digits to be followed by a separator, which is why "10-K" stays a filing rather than becoming item 10. The same category name appearing on several tabs merges into one category instead of duplicating.

Where the import refuses rather than guesses

An invalid plan fails the import loudly. If no mode is recognised, or no tab is identified as holding requests, or no request text column can be found, you get an error instead of an empty list.

A parse that yields zero requests is treated as a failure, not as an empty success. The endpoint returns an error telling you the layout was not recognised. That rule exists because a success response on an empty parse is indistinguishable from a checklist with no items in it. The upload looks fine and no requests exist.

Rows that appear before any category has been established are not discarded. They land in an explicit Uncategorized category, on the same reasoning: an import that silently drops rows is worse than one that refuses, because nobody notices a diligence item that was never created.

The parse also counts itself. It records how many data rows produced a request against how many data rows it saw, and compares the totals against the model's own expected counts, flagging a deviation of more than twenty percent in either direction.

What still needs a human check before you confirm

The coverage counts and warnings are computed on the server, returned with the parse response and written to the log. The import screen shows the parsed structure and the column mapping. It does not show a warning banner. So the check is yours to make: count the requests in the preview and compare that number against the file before you confirm.

Two other things are worth a look. The split between a short topic column and the full request text is a judgement call, and if the file has no separate topic column every request becomes its own topic. And the reader is an Excel workbook reader, so a checklist that arrives as a PDF, a Word document or a CSV is not this path.

Finally, the model call is a real dependency. If schema detection fails or times out, the import fails. There is no non-AI fallback that guesses a layout. Deduplication against request lists already in the deal is also a separate, explicitly triggered step, not something the import does on the way in.