Verify the petition is complete before USCIS flags it.
VisaForge re-derives exactly what your petition type requires (every form, every supporting document, the eligibility criteria, the fee), judges the package you assembled against it, and hands you a per-package verdict. Either the package is complete, or it is not, and when it is not you get the specific missing item and the correct required-set as a receipt you can act on before the envelope is sealed.
Verify a package See a worked receipt
THE PROBLEM
You assemble an immigration petition, you believe it is complete, and you mail it into a backlog that sits near twelve million cases. The trouble is that USCIS does not just queue your filing, it runs anomaly classifiers on intake, so a missing form or a supporting document you forgot does not get quietly fixed, it draws a request for evidence or an outright rejection, and either way the case goes to the back of a line measured in years. The evidence of what was required was never a secret, it lives in the form instructions the agency already publishes, but nobody has just been checking your package against that required-set, deterministically, before it goes in. So the completeness gap gets found by the agency, on their clock, instead of by you, on yours.
HOW IT WORKS
VisaForge is the same producer-agnostic verifier AYA already uses to grade regulatory walks, pointed at the USCIS mailbox instead of a regulator:
- The required-set becomes a checklist, and the checklist becomes a decision tree. The petition type and visa category determine the required forms, supporting documents, eligibility criteria, and fee. AYA generates that checklist (the same immigration-petition capability it already ships), and the verifier treats it as a decision tree, one node per requirement. This is data, not code. - The package is the profile, your completeness claim is the claim. The manifest of what you actually assembled (the forms included, the documents attached, the form editions, the fee paid) is the input the tree walks over. Your belief that the package is complete is the claim we judge, and it is never trusted, it is re-derived. - Five checks, deterministic, no model at verification time. We re-derive the required-set ourselves and compare, on the verdict, the path, the evidence each requirement rested on, whether an abstention was honest, and whether every item cited is one the required-set actually carries. A package that clears all five is complete. A package that fails one comes back with the specific gap. - The failure speaks the filer's own language. A generic verifier failure is mapped onto the completeness vocabulary (a missing required form, a missing supporting document, a form edition USCIS no longer accepts, an unmet eligibility criterion, an unpaid or wrong fee), so the finding lands where you can fix it before mailing. - Across a batch, the pattern surfaces. Single-package verdicts roll up, so if a whole batch of filings keeps missing the same document, you see it as a pattern in your own assembly process, not as a stack of individual rejections arriving weeks apart.
WHAT YOU GET
Per package, a verdict, and when the package is incomplete, the exact missing item plus the correct required-set as an auditable receipt. A missing-items worklist, so the verdict does not just tell you the package is short, it hands you the list of what to add. And across a batch, the pattern of gaps, where your assembly is systematically dropping the same requirement. The verdict and the worklist travel together, which is the whole point, a conclusion without the list does not help you fix the filing, and the list without the conclusion is just paperwork.
WHO IT'S FOR
Immigration paralegals and solo or small immigration firms filing on volume, high-volume filing shops that live or die on turnaround, and pro-se petitioners who need to know a package is complete before they mail it. If you are on the sending side of a twelve-million-case backlog and you need to find the gap before USCIS does, this is built for you.
PRICING (the ladder)
- Single-package. Verify one petition package against the required-set, with the missing-items receipt. - Batch-audit. A batch of packages verified before a filing window, with the across-cases completeness report. - Subscription. Continuous verification as packages are assembled, with a running readiness dashboard. - Platform. The verifier wired behind your case-management workflow, every package checked before you mail it.
(Prices are hypotheses we are validating, not commitments carved in stone.)
THE PROOF (the dogfood)
This is not a new engine we are hoping works. It is the exact re-walk judge AYA already runs to verify its own agents' determinations, and the same one behind our regulatory verification wedge with a live design partner, plus the immigration-checklist capability AYA already ships. Pointing it at a USCIS filing took no new code, we reused the checklist atom as the required-set generator and added a small data map from the verifier's failures to the completeness vocabulary. So the pitch is not a claim about a clever new thing, it is the verification capability we already trust on ourselves, turned outward at your petition package.
HONEST NOTE
Two straight things. First, VisaForge checks a package against a required-set that has to be kept current with USCIS form editions and fees, so it is only as good as that data, and where a requirement genuinely turns on case-specific judgment rather than a checklist item, the honest output is needs-review, not a false verdict, and we would rather abstain than guess. Second, the engine and the domain build are real and the pattern passes our quality gate today, but a live paid run waits on a real package manifest mapped in and a required-set kept current, plus a booted mesh, so this is capability-ready, not one-click-live for a stranger yet. And to be clear about scope, VisaForge produces the verdict and the missing-items worklist, it does not file your petition or send anything to USCIS or pay a fee, that stays your decision and your action.
Verify a package
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*