Axis 1
Capability
Find the right source, read it correctly, and prove every line against it.
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
02 / 3301The 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 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
03 / 3301The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
04 / 3301The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
05 / 3301The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
06 / 3302360 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
07 / 3302360 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
08 / 3302360 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
09 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
10 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
11 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
12 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
13 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
14 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
15 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
16 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
17 / 3303The 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.
| Stage | Measured rate | At 400,000 pages | What it costs |
|---|---|---|---|
| Unchanged after a week | 94% | 376,000 pages | A conditional request. Effectively free. |
| Hash change per day | ~5.7% | ~22,800 pages | A cheap semantic gate, no extraction. |
| Material change per day | 0.12 to 0.23% | 480 to 920 pages | Re-extraction and one human review each. |
| Review load per day | ~2 min each | 16 to 31 hours | Two 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
18 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
19 / 3303The 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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
20 / 3304Proof
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
21 / 3304Proof
The live prototype
Not a recording. Pick an origin and destination and ask; every answer carries the verbatim quote it came from.
Live prototype
The sandbox could not be loaded here. It may be offline, or you may have no network connection.
Open chancery.360labs.tech/sandbox01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
22 / 3305Economics
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
23 / 3305Economics
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
| Coverage | Corridors | Infrastructure per year |
|---|---|---|
| VFS estate | 1,826 | ~$90 |
| Priority expansion | 5,000 | ~$3,900 |
| Broader coverage | 10,000 | ~$7,900 |
| Global | 39,800 | ~$32,300 |
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
24 / 3305Economics
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
25 / 3305Economics
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.
| Option | Cost basis | Data and IP | Verdict |
|---|---|---|---|
| Together AI, serverless | Per token | Prompts and outputs stay VFS’s | Use now. No commitment, already used by VFS. |
| AWS Bedrock, Mumbai | Per token | Inside VFS’s own account and region | Move here when volume or residency requires it. |
| Azure | Per token | Inside VFS’s tenant | Equivalent alternative if VFS standardises on Azure. |
| Dedicated GPU | Per hour | Full control | Only at sustained load, around 5M tokens an hour. |
| VFS-owned hardware | Capex | Full control | Possible, not the default for a bursty workload. |
| Hybrid | Mixed | Split by workload | Batch extraction on cheap capacity, serving in-region. |
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
26 / 3305Economics
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
27 / 3306Governance
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
28 / 3306Governance
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
29 / 3307Delivery
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
30 / 3307Delivery
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 handover | Option 2 · Build and maintain | |
|---|---|---|
| 360 Labs fee, build | $26,000 | $26,000 |
| Team and timeline | AI-native engineering lead, PM and 2 full-stack AI engineers. 2 months. | Same team and timeline. |
| After the build | Structured handover to your team. | $2,500 a month for 2 engineers: maintenance, updates and improvement. |
| Infrastructure | Paid by VFS directly, about $550 to 1,450 a month at current scope. | Same, paid by VFS directly. |
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
31 / 3307Delivery
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.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
32 / 3307Delivery
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
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
33 / 33