Visa requirements are a versioning problem

A visa requirement is a fact with a shelf life. The fee for a Turkish eVisa, the bank statement threshold for a Schengen application, whether a US green card holder needs a visa for Mexico: each of these is true until, quietly and without notice, it isn't. Most of the industry stores these facts the way you'd store a blog post. Somebody pastes them into a CMS, a wiki, or a spreadsheet, and somebody else overwrites them when they notice they've changed.

The failure mode is always the same, and every operator has lived it. A consulate raises a fee or adds a document requirement. Nobody notices for three weeks. The first signal is a rejected application, an applicant stuck at a counter, and a client on the phone asking how a visa company got the visa part wrong. The knowledge wasn't missing. It was stale, and nothing in the system could tell you that.

We think this is a versioning problem, and versioning is a problem software solved a long time ago. Code has diffs, review, publication, history, and blame. Visa knowledge deserves the same machinery, because the cost of a bad change is at least as high.

Research is automated. Publication is not.

Our knowledge engine uses AI research agents to do the part of the job that burns human hours: reading embassy sites, government portals, and official circulars across hundreds of jurisdictions, and extracting requirements, fees, forms, and exemptions. Every fact an agent extracts carries a citation: the source it came from and when it was captured.

Then the agent stops. A researched change does not flow into production. It lands in a review queue as a proposed update with a before and after diff, the way a pull request lands in front of a reviewer. A specialist looks at the change, the source, and the cross-checks, and either publishes it or rejects it. Both outcomes are recorded: who decided, when, and what the values were before and after, in an append-only audit log that nobody can edit, including us.

One detail that matters more than it sounds: the research agents work against a closed vocabulary. The set of visa categories, authorization types, and recognition codes they can reference is seeded and curated, not generated. An agent can discover that Brazil changed an eVisa fee. It cannot invent a visa category that doesn't exist, because the publishing layer will not accept codes outside the vocabulary. Anyone who has watched a language model confidently hallucinate a plausible-sounding visa subtype will understand why we built that constraint in from the start.

The engine that answers is boring on purpose

When a case asks "what does this traveler need", no language model is involved in the answer. The determination engine evaluates published rules: passport, residency, destination, purpose of travel, what the traveler already holds. The same inputs produce the same answer, every time. Determinism sounds unfashionable in 2026, and we are fine with that. An operator defending a decision to a corporate client, or to an auditor, cannot work with "the model usually gets this right."

Every answer ships with a decision record: the exact rules that fired and the exact version of the knowledge base they came from. Months later, you can replay the decision and see the same reasoning. When someone asks why the platform requested a bank statement on a case in March, the answer is not a shrug. It's a record.

The engine also evaluates what the traveler already has before suggesting anything new. A valid visa or residence permit can waive the requirement you were about to file. Multi-leg journeys get evaluated leg by leg, including the awkward exposures like airport transits and cruise port calls, and rolled up into one verdict for the itinerary. These are the edge cases that separate a lookup table from an engine, and they are most of the value.

Cases pin a version

Versioning earns its keep at the boundary between knowledge and operations. When a case is created, it takes a snapshot of the requirements as they stand at that moment. If the rules change next week, the in-flight case does not silently mutate underneath the processor working on it. New determinations get the new rules; existing work keeps the version it was built on, visibly.

This is the same reason you pin dependency versions in software. An unpinned dependency that updates itself mid-build is a debugging nightmare. An unpinned visa requirement that updates itself mid-case is worse, because the person debugging it is an applicant at a border.

Trust, but cross-check

Even reviewed knowledge can be wrong, so we don't grade our own homework. Our answers are continuously compared against the authority data the airline industry relies on to decide who boards a plane. When the two sources disagree, the disagreement does not get papered over or silently resolved in either direction. It becomes a review task with both versions attached, and a specialist settles it.

Staleness gets the same treatment. Published knowledge has an age, and when it crosses a threshold it is flagged and queued for re-research automatically. "When did a human last confirm this fact" is a queryable property of every requirement in the system, which is a sentence we could not have written about any spreadsheet we ever ran an operation on.

What this costs us

Human review adds latency. A fee change detected at 2pm is not live at 2:01pm; it is live when a specialist has looked at it. A fully automated pipeline would publish faster, and for a while it would look smarter. We made the opposite trade deliberately. In this domain, publishing a wrong fact quickly is strictly worse than publishing a right fact an hour later, because wrong facts turn into rejected applications with someone's trip attached.

The review queue also means we staff for it, and that curation is real ongoing work rather than a one-time data import. That's the honest cost of the model. We think it's the entire point. Anyone can scrape embassy websites. The asset is the machinery that turns scraped claims into knowledge you can defend: cited, reviewed, versioned, cross-checked, and replayable per decision.

When an auditor, a client, or your own team asks "why did we tell the traveler that, and who decided it", the answer should take thirty seconds and produce a record. That bar is normal for code and for financial transactions. We're just applying it to visa rules, where the consequences of a bad change land on real people at real borders.