Preserve proof while the work is still fresh

Build an EB1A evidence ledger before the proof disappears

Do not wait until petition drafting to reconstruct years of work from memory. Keep one simple row for each important project: the problem, your exact contribution, date, adoption or use, measurable result, and an independent source that can verify it.

Published Sep 12, 2026 · Educational only, not legal advice

Short answer: a repository, slide deck, or performance review may prove that work happened. An evidence ledger helps preserve the separate proof of who did what, when it happened, who used it, what changed, and where an independent reviewer can confirm the claim.

Strong work becomes hard to document surprisingly fast. A dashboard gets replaced. A launch page disappears. A manager leaves. Internal metrics move behind a new permission wall. Two years later, the petition says you led an important project, but the cleanest proof is gone.

An evidence ledger is a small habit that prevents that problem. It is not a legal argument and it does not decide whether a fact satisfies an EB1A criterion. It gives you and qualified counsel a traceable record to evaluate later.

The six fields to preserve for every important project

Field What to record Why it matters
Problem The concrete technical, business, research, or public-interest problem the project addressed. Prevents a vague project title from doing all the work.
Your contribution The exact decision, design, method, implementation, or leadership work you personally owned. Separates your role from the team's overall result.
Date and stage When the work began, launched, changed, or reached the result you are claiming. Keeps later letters and records consistent.
Adoption or use Who used it, where it was deployed, or how adoption can be measured. Shows movement beyond creation alone.
Measurable result The result, baseline, time period, scope, and any limitation on the number. Makes the claimed consequence auditable.
Independent source A publication, citation, customer record, public release, third-party reference, or other source not created only for the petition. Gives an outside reviewer somewhere to verify the story.

A worked example

Suppose a software engineer created an open-source reliability tool. A weak ledger row says, “Built a widely used monitoring platform.” That sentence mixes creation, adoption, and significance without proving any of them.

A better row separates the jobs:

  • Problem: teams could not detect a specific class of production failures before release.
  • Contribution: designed the detection method and implemented the first public version.
  • Date: prototype in March; public release in June; major integration in October.
  • Adoption: named organizations deployed it, or public package data shows a defined level of use.
  • Result: detection time or failure rate changed over a stated period, with the source and limitation recorded.
  • Independent source: third-party documentation, citations, public integrations, or coverage that discusses the work.

The repository still matters. It can prove authorship, chronology, and the artifact itself. But downstream use, citations, forks, deployments, or third-party references do a different evidentiary job. Keep those sources separate.

What to save now

Record source locations while you can still retrieve them. Useful examples include:

  • public release pages and archived product documentation,
  • dated project records that identify your role,
  • public citations, integrations, forks, or references,
  • lawfully retained aggregate metrics with the time period and source,
  • independent coverage or customer documentation, and
  • the name and current contact path of someone who directly observed the work.

Do not copy confidential employer material into a personal folder just because it might be useful later. Preserve only what you are allowed to retain. For restricted evidence, record a lawful locator and ask qualified counsel how to handle access, confidentiality, and redaction.

Three mistakes the ledger should expose

  1. Creation is treated as impact. Building a system, publishing a paper, or releasing a repository proves activity. The consequence needs its own source.
  2. The team's result is treated as your contribution. Record the boundary between the shared project and the work you actually owned.
  3. A number has no denominator or time period. “Improved performance by 40%” is hard to trust without the baseline, scope, date, and source.

Turn the ledger into a reviewable evidence map

Once you have several rows, do not immediately convert all of them into petition claims. Review them first:

  1. Mark which facts have an independent source and which rely only on internal or self-created material.
  2. Separate proof of creation from proof of adoption, consequence, or field recognition.
  3. Flag any result you cannot reproduce from the source named in the row.
  4. Ask qualified counsel which facts are legally relevant, what comparison is appropriate, and what should stay out.

The goal is not to make every project look extraordinary. It is to identify the few claims that remain concrete when someone skeptical checks the source.

What ChatEB1 can and cannot do

ChatEB1 provides educational guides and editable workflows for organizing EB1A, NIW, O-1, and RFE evidence. Profile Builder Pro helps you turn career facts into a field, claim, criterion, evidence-gap, final-merits, and attorney-handoff roadmap.

ChatEB1 is not a law firm. It does not decide eligibility, choose legal arguments, predict approval, or replace an immigration attorney. Do not send confidential documents through social messages.

Bottom line

Evidence quality is easier to preserve than to reconstruct. Start the ledger when the work is happening, keep creation separate from consequence, and make every important result point to a source another person can actually check.

If your problem is broader than recordkeeping, use Profile Builder Pro to identify the claims and gaps worth organizing before you spend on petition drafting.