A Document Tracker for Multi-Month Petition Preparation

Why a tracker matters for a petition built over months

A typical EB-2 NIW petition ends up with 30 to 60 discrete documents: Form I-140 and its supplements, a personal statement, six to ten recommendation letters, published papers, citation reports pulled from Google Scholar or Web of Science, degree certificates and their credential evaluations, media coverage, patents, grant letters, and proof of membership or peer review activity. None of this arrives at once. It is requested, drafted, revised, and finalized in bursts over weeks or months, often with long gaps while you wait on a recommender, a translator, or a records office.

That stretched timeline is exactly what causes problems. A recommendation letter signed in January may reference a job title or project that changes by June. A citation count pulled early in the process goes stale by the time you file. Two versions of the same exhibit — one with a typo fixed, one without — circulate by email and no one is sure which is current. Documents requested from a co-author or university registrar get forgotten entirely because there was no list to check against.

A tracker solves this by giving you one place that reflects the true, current state of every document: what exists, what's still needed, what's outdated, and what's ready to file. It is not a place to work out whether your evidence meets any legal standard — that is a separate task. Its only job is to stop things from being lost, duplicated, or filed in an obsolete version.

Choosing a format: spreadsheet vs. document management tool

The tracker itself can live in several kinds of tools. What matters is that it stays a single, current file that everyone involved checks — not which software runs it.

Spreadsheets (Google Sheets, Excel)

A spreadsheet handles this job well for almost anyone filing without a large support team. It requires no setup beyond opening a blank sheet, works offline (Excel) or with automatic version history (Google Sheets, via File > Version history), and is trivial to share with a recommender, translator, or attorney by sending a link or exported copy. Filtering and color-coding statuses takes seconds.

Dedicated tools (Notion, Airtable, shared drives)

Notion and Airtable offer relational views, reminders, and file attachments directly inside each row, which can help if several people are editing simultaneously or if the petition involves many linked sub-documents. A shared drive with a strict folder and naming convention can substitute for a tracker entirely for very simple filings, but it lacks the at-a-glance status view a spreadsheet or database gives you.

Choosing between them

Base the decision on three questions: How many people need to edit or view the tracker at once? Do you need offline access at any point? Do you need to recover an earlier version if something is overwritten by mistake? For a solo filer working with one or two recommenders and perhaps a translator, a spreadsheet answers all three adequately. This article uses a spreadsheet layout as the working example throughout, but the same columns and logic transfer directly to Notion or Airtable if you prefer those tools.

Building the master tracker: columns and structure

Set up one row per document, one sheet, nine columns. Resist the urge to split this into multiple tabs at this stage — a single flat table is easier to sort, filter, and eventually convert into an exhibit list.

Core columns

Worked example

Keep this sheet visible and update it directly rather than tracking status in email threads.

Categorizing documents to match the Kazarian/Dhanasar evidence framework

The Category column in the master tracker should not be freeform. Use a fixed set of values so that rows sort cleanly into the structure most NIW petitions follow when assembled. This is a filing and organization convenience — it has nothing to do with arguing why any document satisfies a legal standard.

Recommended category values

1. Biographical/identity — passport bio page, prior visa stamps, current I-94, degree certificates, transcripts, credential evaluations.
2. Proposed endeavor — the petitioner's statement of the endeavor, business plans, project descriptions, patents, grant applications.
3. National importance — publications, citation reports, media coverage, industry data, funding awards, government or industry reports referencing the field.
4. Well-positioned to advance the endeavor — CV, employment letters, degrees, prior project outcomes, invitations to speak or review.
5. Recommendation letters — tracked in the sub-log described below but still tagged here for exhibit numbering.
6. Supporting/other — anything that doesn't cleanly fit above (e.g., professional membership records, licenses).

Why this matters for later

When every row carries one of these six tags, filtering or sorting the tracker by Category produces a ready-made grouping of exhibits in the order many petitions present them. Apply this tag as soon as a document is added to the tracker, not at the end — retrofitting categories onto fifty rows the week before filing is where errors creep in.

Tracking recommendation letters separately: a sub-log

Recommendation letters move through more stages than any other exhibit, and the master tracker's single "Status" column cannot capture all of them. Set up a separate tab (or a distinct block within the same sheet) dedicated to letters, with one row per recommender.

Columns to include

Why a sub-log, not just a status tag

Each letter passes through: recommender identified, draft sent, recommender edits returned, signature obtained, notarization if used, and final PDF saved. A single status field collapses these steps and hides where a letter has stalled — for example, a recommender who received a draft six weeks ago but never sent edits back.

The common failure

When recommenders revise their own drafts, multiple versions of the same letter can end up circulating by email. Without a log tying a specific file name to the version actually signed, it becomes easy to file an unsigned or superseded draft. Record the exact file name only once a signed copy is in hand, and treat any version without a signed-date entry as not yet usable.

File naming and version control

A tracker row is only as good as the file it points to. If filenames are inconsistent ("letter final v2 ACTUAL.docx"), the tracker's File name column becomes useless the moment two people touch the same document.

A naming convention

Use a fixed pattern for every document destined for the petition:

Exhibit-[number]_[Category]_[Identifier]_[Status]_[Date].pdf

For example: Exhibit-07_RecLetter_Smith_Signed_2024-03-15.pdf

Break this down:

• Exhibit-07 — matches the Exhibit # in the tracker, so files sort in filing order automatically.
• RecLetter — category tag, matching the Category column.
• Smith — a short identifier (recommender surname, journal name, or degree institution).
• Signed — status tag: Draft, Signed, Notarized, Final. Never leave this ambiguous.
• 2024-03-15 — the date of that version, not the date the file was created.

Apply the same logic to non-letter exhibits: Exhibit-12_CitationReport_GoogleScholar_Final_2024-06-01.pdf.

Keeping drafts and finals apart

Maintain two folders per document type: a working folder for drafts and a Final folder that only ever receives the version approved for filing. Once a file lands in Final, do not edit or overwrite it — if a correction is needed, save a new dated version and update the tracker's Status and File name columns to match. Filed versions should never change after the petition is submitted; keep them exactly as sent, alongside the mailing or upload receipt.

Weekly review routine and status flags

A tracker only works if someone actually looks at it. Set aside 15 minutes at the same time each week — Sunday evening or Monday morning works for most people — to run through every row.

The weekly pass

1. Update the Status column for anything that moved (Drafting → Awaiting signature → Final).
2. Check Date requested against today's date. Anything requested more than two weeks ago with no update gets highlighted red.
3. Add a note on red items: what's blocking it, and who you're waiting on.
4. Compile a short list of outstanding requests — recommender signatures, citation report pulls, employer confirmation letters — that need a follow-up email this week.
5. Send those follow-ups before closing the laptop. A flagged row that never gets a nudge stays flagged forever.

Calendar reminders, not memory

Don't rely on remembering who owes you what. When you request a document, set a calendar reminder for two weeks out with the exhibit number and recipient in the title (e.g., "Follow up: Exhibit 07 — Dr. Smith signature"). If the item is marked Final before the reminder fires, ignore it; if not, that's your cue to chase it during the weekly review.

This routine catches the two most common failure modes: recommenders who go quiet after agreeing to write a letter, and self-sourced documents (transcripts, citation counts) that quietly stall because no one else is waiting on them but you.

From tracker to exhibit list: the final handoff

Once every row in the master tracker shows Status = Final, the tracker stops being a working document and becomes the source for the exhibit list itself. The Exhibit # and Document name columns, sorted in the order you intend to file them, convert almost directly into the table of contents that sits at the front of the petition binder or PDF. Copy those two columns into a new sheet or the first page of the assembled document, add page numbers once the final PDF is paginated, and that becomes your exhibit list.

Final cross-check before filing

Before submission, run one last reconciliation pass:

1. Print or export the tracker filtered to Status = Final.
2. Open the assembled PDF (or physical stack) and go exhibit by exhibit.
3. For each exhibit, confirm the tracker row's file name matches the actual file used in the final assembly — not a draft or earlier version.
4. Check that exhibit numbers run in sequence with no gaps or repeats.
5. Confirm every row in the tracker has a corresponding exhibit in the stack, and every exhibit in the stack has a corresponding row — duplicates or orphaned files usually surface here.

Common errors this catches

• An exhibit renumbered during editing but not updated in the tracker or table of contents.
• A recommendation letter's signed final swapped for an earlier draft during compilation.
• A document listed as Final in the tracker but never actually inserted into the assembled PDF.

This cross-check is the last point at which the tracker functions as a control document rather than a planning tool.