Strictly confidential

VFS Travel
Intelligence Engine

A trusted answer for every visa corridor, kept current at a cost that works.
Prepared for

VFS Global

Prepared by

360 Labs

Technical and commercial proposal

September 2026

01The problem

The scale

200 origins × 199 destinations is close to 40,000 corridors. Our 31 deeply proven corridors are 0.08% of that. They prove the mechanism works. They are not the scope.
The frame
39,800

Corridors in the full universe

Every origin and destination pair a traveller can ask about, at roughly 10 pages each.

VFS publishes
1,826

Corridors, or 4.6% of the universe

The part of the problem VFS already owns the content for. This is where production starts.

Proven deeply
31

Corridors, or 0.08% of the universe

Crawled end to end from India with government sources, grounding and verification. Proof of mechanism, not of scale.

02 / 33
01The problem

Anyone can generate an answer

The difficult part is maintaining a trusted answer across 40,000 corridors at a cost that works. That is the problem this proposal solves, and everything after this slide is evidence on one of four axes.
Axis 1

Capability

Find the right source, read it correctly, and prove every line against it.

Axis 2

Cost

Hold cost flat as corridors multiply by a thousand, and to near zero per question.

Axis 3

Governance

A named person approves what ships. Models propose, people decide.

Axis 4

Ownership

The intelligence, the registry and the decisions stay VFS property.

03 / 33
01The problem

Why is this hard?

Seven difficulties compound. Each one is manageable alone. Together, at 40,000 corridors, they are an engineering and economics problem, not a content problem.
01

Sources

Discovery never finishes. New missions, operators and pages keep appearing.

02

Changes

No changelog, no API, no notice. A rule changes and the page just reads differently.

03

Conflicts

One operator, two names. Two sources disagree. Jurisdiction decides who wins.

04

Dynamic content

Script-rendered pages hold nothing to read until a browser runs them.

05

Scale

Everything above multiplies by a thousand at 40,000 corridors.

06

Cost

Naive crawling and extraction at that scale costs more than the answers are worth.

07

Governance

Models hallucinate, so a named person decides what reaches a traveller.

04 / 33
01The problem

What it looks like today

One corridor, one question, and the answer is spread across sources with different owners, different jurisdictions and different vocabulary.
Fragmented sources

The answer is rarely on one page

VFS pages, mission and government sites, other operators, and the PDFs they link to.

Different operators
4 of 31

In the corridors we examined, the service is run by someone other than VFS. Spain from India is BLS International, not VFS.

Different jurisdictions

Who serves the corridor depends on where you live

Consular districts decide which mission and which centre applies, and the rules differ by district.

Different vocabulary
212

Distinct visa-type names across sources for the same underlying set of visas.

Silent change
95

Operational notices found in one pass. Any of them can change an answer with no notification.

05 / 33
01The problem

How far we already reach into your estate

Built by one 360 Labs engineer in a 6-hour sprint on 20 September. Every count is computed from the data on disk, not estimated.
VFS corridors live
1,338

Read through the VFS content API

Across 63 destinations and 161 origins, the same API your own website calls. Where the catalogue is structured, the answer is assembled with no model call at all.

Government-sourced pairs
6,818

17.3% of all 39,402 passport and destination pairs

Inside VFS’s own 86 destinations, half of all pairs (6,328 of 12,672) are already answered from a government or VFS source.

What it cost
1.3 ¢

Per corridor that needed a model, and nothing for the rest

Running the whole VFS estate is about $90 a year of infrastructure. The sprint itself cost one engineer, one day.

06 / 33
02360 Labs

Why us

One team takes a problem from research through engineering to production and runs it. That is the whole pitch; the next two slides define the terms and show the evidence.
Step 1

Research

Model evaluation, retrieval and grounding, compression, inference economics.

Step 2

Engineering

Crawlers, pipelines, registries, review tooling, APIs.

Step 3

Production

Monitoring, audit trails, cost control, human review at volume.

Step 4

Deployment

Handover into the client’s own cloud, or run by us.

Where we have worked

Sectors

Government, financial services, travel, logistics, industrial and manufacturing, and AI infrastructure.

07 / 33
02360 Labs

What we mean by AI-native and research

Both words get used loosely, so here are our definitions and what they look like in this build.
Definition

AI-native

AI sits inside the operating architecture, not on top of it as a chatbot. In this system that means the discovery loop that proposes sources, the review queue that routes judgement to a named person, and the source registry that records what was approved and why.

Definition

Research

Named, measurable work, not a claim: model evaluation per task, architecture experiments, inference optimisation, retrieval and grounding methods, agent orchestration, and content compression.

Evidence

In this build

The compression benchmark on the next act, the verifier that sits outside the model, and a model strategy that puts deterministic code first and frontier models last.

08 / 33
02360 Labs

Two projects that match this one

Both solve the same shape of problem: fragmented, changing information that has to drive a decision someone is accountable for.

Arika

Travel

AI proposes, a named human approves

The same governance pattern this system uses: the model drafts, a person with a name signs off, and the decision is recorded against the record it changed.

Business Brain

Industrial operations

Fragmented operational data turned into evidence-scored intelligence

Data from systems that never agreed with each other, resolved into one record per entity, with every finding traceable to the source row that produced it.

09 / 33
03The system

How the system works

Six stages, two of which are continuous loops that never finish. The next two slides open those loops up.
01

Discover

Find, validate and qualify candidate sources

02

Harmonise

One record per corridor from many formats

03

Ground

Every line checked against its source text

04

Review

A named person approves what ships

05

Publish

Into the verified knowledge base

06

Serve

Database read, no model call

Loop 1

Source discovery

Runs continuously against the open web. It never finishes, because new missions, operators and pages keep appearing.

Loop 2

Source monitoring

Runs on its own schedule against approved sources only, and acts only when something material changes.

10 / 33
03The system · Loop 1

Finding sources never finishes

Discovery is a standing process, not a task that completes. Every run widens the registry and improves the next run.
Step 1

Research agent

Searches for candidate sources per corridor: VFS estate, missions and ministries, other operators, immigration and policy sites.

Step 2

Candidates

Fetched and inspected. Is this the right page, is it relevant, is it reachable, is it a duplicate or an error shell?

Step 3

Validation

Authority, ownership, coverage and purpose are assessed, and the model states its recommendation.

Step 4

Human ratification

A named reviewer approves or rejects. In the sprint: 77 policy sources approved, 114 rejected. Nothing serves from an unapproved page.

Step 5

Approved source registry

URL, authority tier, purpose, fetch method and last check. The registry is the asset the rest of the system runs on.

11 / 33
03The system · Loop 2

Watching what we already trust

A separate loop, on its own schedule. It touches approved sources only, and spends effort only on change that matters.
Step 1

Scheduled crawl

Every registered page and PDF is re-fetched daily, using conditional requests so unchanged pages are not downloaded again.

Step 2

Change detection

Content hash and timestamp first, because that is nearly free.

Step 3

Materiality check

One question decides the cost: would a caseworker care about this change? Cosmetic changes are logged and stop there.

Step 4

Human review

Material changes only. The reviewer sees the old text, the new text and the difference between them.

Step 5

Knowledge update

The record is republished with its new evidence and fetch time. Last run: 118 pages checked, 60 unchanged, 47 cosmetic, 2 material, 9 failed.

12 / 33
03The system

The fetch ladder

Reaching a page is the expensive part. We start at the cheapest rung and climb only when the source forces it, logging every step.
Rung 1

Direct HTTP

Static pages, APIs and PDFs. Milliseconds, no browser, negligible cost. Most sources end here.

Rung 2

Residential IP and geographic context

Consular pages serve different content by country, so we fetch from where the traveller is.

Rung 3

Blocked and incomplete detection

A 200 is not success. We check for challenge pages, empty shells and truncated content.

Rung 4

Browser escalation and JavaScript rendering

Script-rendered pages run in a real browser until the promised content actually exists.

Rung 5

Stealth handling

Only where a source is flagged. The slowest, most expensive rung, so it is used last.

Rung 6

Retry, fallback and validation

Failures back off and retry higher up the ladder. Every fetch is validated before extraction.

Always on

Allow-list and logging

Same-domain only, depth limits, and a log of every fetch: rung, egress, result, duration.

13 / 33
03The system

Turning pages into one record

A model is the most expensive tool in the box, so it only runs where the source is not already typed.
Step 1

Raw source

HTML, JSON from the content API, a PDF checklist, or a notice written as prose.

Step 2

Already structured?

No model runs. Where the VFS content API carries a typed visa catalogue, the record is assembled directly by code, at zero token cost. This is how 1,338 corridors were built.

Step 3

Selective extraction

Only unstructured sources reach a model, at temperature zero, asked only for the fields the schema defines. About 1.3 cents per corridor.

Step 4

Deterministic structuring

Output is validated against a fixed schema by code. Anything outside the schema is dropped, not repaired by another model call.

Result

One harmonised record

Visa type, purpose, jurisdiction, requirements, fees, channel and the source quote behind each line, in the same shape for every corridor.

14 / 33
03The system

How we keep extraction honest

The verifier sits outside the model. It does not ask the model whether it was right; it looks for the text.
01

Claim

A single line the model proposes

02

Source

The page or PDF actually fetched

03

Verbatim evidence

The exact words found, with position

04

Keep or drop

Deterministic, outside the model

Keep  Seafarer Visa

Matching text found on the fetched vfs.global page, stored with the claim.

Drop  Digital Nomad Visa

No supporting text in any fetched source, so the claim never reaches the knowledge base.

Measured
99.6%

Of claims grounded in the crawled corridor set: 510 of 512. The 2 that failed were rejected automatically.

15 / 33
03The system

The compression benchmark

Reduction on its own is easy and worthless. Reduction with full recall is the result that makes the economics work.
Input
8,968,533

Tokens of raw source pages

Everything fetched for the corridor set, as the pages actually arrive.

Output
6,718

Tokens of relevant, structured content

A 99.93% reduction before any model sees the content. Measured, not modelled.

Recall
16 of 16

Probe facts recovered after compression

The leading public extractor recovered 0 of 16 on the same inputs. Compression is only meaningful paired with recall.

16 / 33
03The system

Why corner cases resolve without a model

Facts are stored as a graph with their source and authority, so the awkward cases are traversals, not hand-written rules.
Corner case 1

Liechtenstein

Liechtenstein has no visa service of its own. Switzerland acts for it under a 1919 treaty. In the graph that is two hops, so the right centre and rules are returned without anyone writing a Liechtenstein rule.

Corner case 2

Spain from India

The corridor is operated by BLS International, not VFS. The operator edge carries that, so the answer names the right operator instead of assuming VFS.

Why it matters

No model call at request time

The relationships are resolved when the record is built and reviewed. At request time the system is reading a graph, not reasoning about treaties.

17 / 33
03The system

What change looks like at 40,000 corridors

Measured rates on the corridors we run, then applied to roughly 400,000 pages. This is what decides the running cost and the review headcount.
StageMeasured rateAt 400,000 pagesWhat it costs
Unchanged after a week94%376,000 pagesA conditional request. Effectively free.
Hash change per day~5.7%~22,800 pagesA cheap semantic gate, no extraction.
Material change per day0.12 to 0.23%480 to 920 pagesRe-extraction and one human review each.
Review load per day~2 min each16 to 31 hoursTwo to four reviewers, modelled at full scale.
The point

Effort tracks change, not corridors

Multiplying corridors by 1,000 multiplies cheap checks. It multiplies expensive work only by the share of pages that actually changed in a way a caseworker would care about.

18 / 33
03The system

Zero model calls when a traveller asks

Answering is a database read. Model cost is paid once, when a source changes, and never again when a question is asked.
Cost per question
0 model calls

Traffic cannot generate a model or search bill

Partner volume, seasonal peaks and bot traffic change your infrastructure cost, not your inference cost.

Latency

A read, not a generation

Response time is a property of the database and the cache, so it is predictable and does not move with model provider load.

Auditability

The same answer twice

Two identical questions return identical text, with the same quote and the same fetch time. Nothing is regenerated per request.

19 / 33
03The system

Controls on what the system does

Both directions: what we take from sources, and what a consumer can take from us.
Crawling

Same-domain only, with depth limits

The crawler follows links inside the approved source’s own domain, to a set depth. It does not wander the open web.

Caching

Bounded by time to live

A page is not re-fetched inside its window, which keeps polite load on government hosts and cuts cost.

Consumers

Per-key rate limits with back-off

Every API key has its own ceiling. Over the limit, the caller is slowed, not the system.

Egress

Residential or in-country where required

Used only where a source needs it, and recorded per fetch.

Logging

Per key and per fetcher

Who asked, what was fetched, from where, at which rung of the ladder, and what it cost.

20 / 33
04Proof

What is proven, and what is not

The mechanism holds on real corridors. Scale is an engineering programme, not a claim we are making today.
Proven today

The mechanism works on 31 real corridors

Discovery, fetch, extraction, grounding and review, end to end, on live government and operator sources.

Grounding holds: 99.6%

510 of 512 claims carried verbatim evidence; the rest were dropped automatically.

Compression holds: 99.93% with full recall

16 of 16 probe facts recovered after reduction.

Cost holds

1.3 cents per model-read corridor, zero for structured ones, about $90 a year to run the VFS estate.

Still to solve at scale

Continuous scheduling across 400,000 pages

Daily checks at that volume need queueing, back-off and failure handling that a 31-corridor run never tests.

Growing the registry towards 40,000 corridors

Discovery and ratification have to keep pace, which is a throughput problem, not a technique problem.

Sustained review throughput

480 to 920 material changes a day needs a staffed queue with priority, not goodwill.

Jurisdiction depth outside the crawled set

Consular-district rules exist for the crawled corridors; API-built answers still carry jurisdiction as unknown.

21 / 33
04Proof

The live prototype

Not a recording. Pick an origin and destination and ask; every answer carries the verbatim quote it came from.
chancery.360labs.tech/sandbox Live Open in new tab

Live prototype

The sandbox could not be loaded here. It may be offline, or you may have no network connection.

Open chancery.360labs.tech/sandbox
22 / 33
05Economics

What does this cost at 40,000 corridors?

The right question to ask before any number. Three things drive the answer, and the architecture is built to hold all three down.
Driver 1

Fetching

400,000 pages, re-checked. Held down by conditional requests and by climbing the fetch ladder only when forced.

Driver 2

Extraction

Model tokens. Held down by never running a model on a structured source, and by 99.93% compression on the rest.

Driver 3

Review

Human hours. Held down by spending them only on material change: 480 to 920 pages a day, not 400,000.

23 / 33
05Economics

Capex, opex and total cost

Measured figures come from the corridors we already run. Modelled figures are projections, and are labelled as such.
Capex

Build

Engineering and research, architecture, initial source discovery, the knowledge model, the platform and its integrations, initial infrastructure setup. Optional private GPU cluster: about US$11,000 for two nodes.

Opex

Run

AI and ML operations, infrastructure, monitoring, continuous source discovery, maintenance and engineering support, model and inference costs, knowledge updates, human review.

Measured

What it costs today

VFS estate: about $90 a year of infrastructure, no model calls. Corridors that need a model: 1.3 cents each. Current running range: US$550 to 1,450 a month.

Modelled

What it costs at scale

CoverageCorridorsInfrastructure per year
VFS estate1,826~$90
Priority expansion5,000~$3,900
Broader coverage10,000~$7,900
Global39,800~$32,300
24 / 33
05Economics

Which model runs, and why

Every tier is a deliberate choice with a reason to be used or not used. Most of this system runs no model at all.
Default

Deterministic code

Used for most of the system. Registry, fetch ladder, validator, compression and serving. No model, so no token cost, no drift and no hallucination surface.

Workhorse

Open-weight models

Used for extraction. The balance of cost, control and privacy: they run on Together AI or inside VFS’s own Bedrock, and the prompts and outputs stay VFS property.

Exception

Frontier models

Used only for hard reasoning, and never where VFS data would leave VFS’s control. They are the most capable and the most expensive, so they are the last resort.

Reserved

Small, vision and domain models

Evaluated task by task, not assumed better. A smaller model earns its place only when it matches quality on that specific task at lower cost.

25 / 33
05Economics

Where it should run

Our recommendation: Together AI now, AWS Bedrock in Mumbai once volume or data residency demands it. The rest are open options, not plans.
OptionCost basisData and IPVerdict
Together AI, serverlessPer tokenPrompts and outputs stay VFS’sUse now. No commitment, already used by VFS.
AWS Bedrock, MumbaiPer tokenInside VFS’s own account and regionMove here when volume or residency requires it.
AzurePer tokenInside VFS’s tenantEquivalent alternative if VFS standardises on Azure.
Dedicated GPUPer hourFull controlOnly at sustained load, around 5M tokens an hour.
VFS-owned hardwareCapexFull controlPossible, not the default for a bursty workload.
HybridMixedSplit by workloadBatch extraction on cheap capacity, serving in-region.
26 / 33
05Economics

Infrastructure is yours, not ours

VFS chooses and pays for its own infrastructure directly. 360 Labs does not resell it and does not mark it up.
VFS pays directly
  • Model and inference spend, on VFS’s own account
  • Cloud, storage and serving
  • Residential or in-country egress where needed
  • Optional GPU capacity

Today this is US$550 to 1,450 a month, and about $90 a year for the VFS estate alone.

360 Labs invoices
  • Engineering and research time
  • The build, to an agreed scope
  • Optional maintenance after handover

One fixed build price, one optional monthly fee. Nothing else passes through us.

27 / 33
06Governance

Who owns what

Everything that carries domain value is VFS property. Everything replaceable is a supplier you can change.
VFS owns
  • The extracted corpus and every source quote
  • The knowledge graph and the harmonised records
  • The source registry and its authority tiers
  • The evidence trail and every review decision
  • The prompts, schemas and domain logic
  • The workflows and the review queue
Replaceable suppliers
  • The model provider
  • The cloud and GPU infrastructure
  • Commodity software and libraries
If the model provider changes?

Nothing moves. The corpus, graph and registry are VFS’s data, not provider state.

Can VFS change models, or move infrastructure?

Yes, on either axis, without rebuilding the intelligence layer.

Does VFS data leave VFS-controlled boundaries?

Only to the inference endpoint VFS itself chooses, and never to a frontier model without that choice.

28 / 33
06Governance

Where people decide

Automation narrows the work; people make the call. Nothing reaches a traveller without a named approval against it.
01

Automation

Fetch, extract, verify, classify change

02

Prioritisation

Only material items enter the queue

03

Human decision

Approve, reject, or send back

04

Trusted record

Published with the reviewer’s name

Where review happens

Five points

Source qualification, ambiguous information, conflicting sources, material change, and governance exceptions.

Modelled at full scale
16 to 31 hours a day

480 to 920 material changes a day at roughly two minutes each: two to four reviewers, working a prioritised queue. Staffed, not assumed.

29 / 33
07Delivery

The plan

Four phases. Review capacity scales with each one, rather than being left until it breaks.
Phase 1

Harden and verify

Gold-set review with your consular team, audited fetch path, measured cost and latency.

Review: your reviewers, our queue, on the corridors you pick.

Phase 2

Complete the VFS estate

All 1,826 published corridors through the content API, with jurisdiction rules added.

Review: one reviewer, part-time, on material change only.

Phase 3

Grow the registry

Harvest the 398 filed mission sites, close the thin policy pages, expand to priority corridors.

Review: two reviewers as discovery volume rises.

Phase 4

Channels and handover

API for partners, internal tools, then handover or ongoing support.

Review: two to four reviewers at full scale.

30 / 33
07Delivery

Engagement

Two ways to work with us. Infrastructure is paid by VFS directly in both, and is not part of these figures.
Option 1 · Build and handoverOption 2 · Build and maintain
360 Labs fee, build$26,000$26,000
Team and timelineAI-native engineering lead, PM and 2 full-stack AI engineers. 2 months.Same team and timeline.
After the buildStructured handover to your team.$2,500 a month for 2 engineers: maintenance, updates and improvement.
InfrastructurePaid by VFS directly, about $550 to 1,450 a month at current scope.Same, paid by VFS directly.
31 / 33
07Delivery

Next steps

All six can start this month, and the first three need only a short call and access.
01

Gold-set review

You pick the corridors. We show the answers, the quotes and the sources behind them.

02

Stakeholder group

Name the people whose sign-off the system needs, on both sides.

03

Consular review

Your consular team checks jurisdiction and district handling on their own corridors.

04

Scheduled monitoring

Turn the daily loop on for an agreed set and watch what it catches.

05

Audited fetch path

We walk your security team through the ladder, the egress and the logs.

06

Live sandbox iteration

Keep using the sandbox and tell us what an answer should look like for your channels.

32 / 33
07Delivery

Let’s build it

We can start with the gold-set review and a scoping call in the same week.
Co-founder and CEO

Prithvi Raj Agrawal

Co-founder and CTO

Saurabh Kumar

360 Labs

Lightyear 360 Labs Private Limited  ·  360labs.ai

33 / 33
Live prototype
chancery.360labs.tech/sandbox
New tab
All slides
Arrow keys to navigate  ·  F present  ·  G all slides