Entry rules change without ceremony. A fee goes up on the payment page of an e-visa portal while the guidance page describing that portal keeps quoting the old amount for a fortnight. A nationality gains a row in a table inside a gazette that has no feed, no mailing list and no press release. A start date slips by three months in the eleventh paragraph of a ministry circular.
None of it arrives in a form a computer can read. There is no standard for publishing an entry rule, no version number, no changelog. Governments are not shipping an API. They are posting a notice, in their own language, on their own schedule, from whichever department happened to own the decision.
We keep requirement data for more than 190 destinations and file applications end to end on more than 60 of them. Three of us are responsible for that data being right on any given morning. People ask how that is possible, so here is the actual practice.
What we read
The unit of work is a destination, and each one has a short list of places where its rules genuinely live:
That list is a template rather than a rule. Some destinations run everything through one portal and publish nothing alongside it. Some put the decision in a gazette weeks before the portal reflects it. A few keep the authoritative version in a language none of us speak, which is a translation problem and a verification problem at the same time, and it is one reason we keep the original document attached to the rule it produced.
Around that sits a second ring. The British, American, Australian, Canadian, French and German foreign ministries each publish per-country entry summaries and maintain them properly, which gives us six well-staffed observers reading the same governments we read, in six editorial styles, disagreeing with each other often enough to be useful. We read them for corroboration and early warning. When one of them says something our primary sources do not, we treat that as a question to answer before anything gets published.
What our filing robots see
The part of this that is hard to copy has nothing to do with reading. Filing applications on government portals is our day job, across the 60-plus destinations we process end to end. Our filing robots log into those portals every working day, complete real forms for real travelers and pay real fees.
That produces an observation layer no amount of watching public pages can match. The robot sees the fee at the payment step, which is the number the government is charging this morning. It sees the form fields, so a newly required document shows up as a form that suddenly wants something. It sees downtime, which no page ever admits to. When the portal disagrees with the page describing the portal, we hear about it the same day, and the portal wins.
It also tells us where our confidence is highest. On the destinations we file every day the evidence is first-hand. Across the rest of the catalogue we are reading and cross-checking on the same weekly cadence, without that signal underneath it, and it is worth saying so plainly rather than implying one standard of certainty everywhere.
The gazette is where a date becomes real. The payment page is where a fee becomes a price.
Most page changes are noise
The naive version of this job is to watch every page and read everything that moves. It collapses in a week. Government sites change constantly and mean nothing by it: rotating banners, session tokens in URLs, a widget rendering today's date, a cookie notice with a fresh build hash. Watch enough pages that way and you will spend every Monday reading markup.
So the first pass is mechanical. We keep a copy of every page we watch, compare this week's fetch against it, and discard everything identical. What survives gets read for materiality, which is a judgment call and always has been. A restyled navigation bar and a changed fee produce a diff of roughly the same size and deserve completely different reactions. Each source also teaches us its own noise as we go, so the tenth week of watching a page costs far less attention than the first.
The second pass is corroboration. A real change is rarely shy: it appears on the portal, then in the gazette, then in a foreign ministry's summary, sometimes with dates that do not quite agree. Sources are unreliable in different ways, which is why that matters. A portal is current and says nothing about scope; a gazette is exact about dates and slow to reach the web. Agreement between them is what earns publication, and a single sighting earns a note and another look next week.
The review, every week
All of it feeds one habit. Every week, the three of us sit down with the queue the machines have built.
Sweep. Every registered source is fetched and compared with the copy we kept, whether or not anything suggested it would move. Completeness is the point: a source we skipped is a hole we cannot see.
Triage. Surviving diffs are sorted by what they would do to a rule. A fee or eligibility change on a destination we sell is same-day work. A reworded FAQ is filed and forgotten.
Corroborate. Anything material is chased to a second source and preferably a third, with the effective date pinned to whichever document carries legal weight rather than the one that reads most clearly.
Publish. A person signs it off. Then our rules engine, the changelog and the partner alert emails move together, on the same day.
The weekly rhythm is the floor. A fee change on a destination we sell does not wait for the next review; it gets corroborated and published the day it lands, and the review then picks up everything that arrived more quietly.
Most weeks, most checks confirm what we already knew. Nothing in Kenya moved, nothing in Japan moved, the Indian fee is the Indian fee. That result is worth the work, because a rule nobody has looked at since March and a rule somebody confirmed on Tuesday are two different products, even when the text is identical.
Every rule we publish carries the date a person last confirmed it against its government source. That date moves when we confirm a rule, not only when we change one, so a rule that has been stable for a year still tells you when somebody last looked.
That date is why the weekly sweep covers everything rather than only the destinations in the news. Freshness you can prove has to be earned on the quiet rules as well, and the requirements endpoint exposes the same timestamp whether the answer is dramatic or dull.
Why three people is enough
The division of labour is the entire answer. Machines are good at noticing. They are patient, they never skip a week, and they do not get bored of a page that has looked the same since spring. They are also incapable of telling us what a Mongolian immigration circular means for a Nigerian passport holder connecting through Doha in November.
That second part is the actual job, and it does not scale by hiring. It scales by making sure a person only sees what deserves a person. When the filing robots and the diffs are doing their share, the queue that reaches the three of us each week is small and specific, and reading it carefully is realistic rather than heroic.
For a partner, all of this reduces to one line in an answer. Ask us what a passport needs for a route, and you get the requirement plus the date a person last confirmed it against a government source. You can then decide for yourself whether a rule verified last Tuesday is fresh enough for the booking in front of you. That decision belongs to you, and it needs a date to be possible at all.