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 / 3401The 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 / 3401The 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 / 3401The 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 / 3401The problem
How far we already reach into your estate
Built by one 360 Labs engineer in a 6-hour sprint on 20 September. Every pair of passport and destination now answers, and each answer states how deep its evidence goes. Every count is computed from the data on disk.
Pairs answering
39,402
Full corridor answer 3.5%
Government rule 13.8%
Reference dataset 82.7%
Full corridor answers
1,369
Visa types, purposes, steps, documents, fees and channel
Across 67 destinations, every line carrying a verbatim quote from its source. 1,338 of them read through the VFS content API, across 63 destinations and 161 origins.
Government-sourced pairs
6,818
17.3% of all pairs, and half of VFS’s own
Inside VFS’s 86 destinations, 6,328 of 12,672 pairs already answer from a government or VFS source rather than the reference dataset.
What it cost
1.3 ¢
Per corridor that needed a model, and nothing for the rest
Where the content API carries a structured catalogue, the record is assembled with no model call at all. Running the whole VFS estate is about $90 a year of infrastructure.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
06 / 3402360 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 / 3402360 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 / 3403The 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
09 / 3403The 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
10 / 3403The 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
11 / 3403The 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
12 / 3403The 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
13 / 3403The 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
14 / 3403The 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
15 / 3403The 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
16 / 3403The 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
17 / 3403The 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
18 / 3403The 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
19 / 3404Proof
Where full answers are live
1,369 corridors across 67 destinations return a full, quoted answer today. In 53 of those destinations every line is verified against its source.
| Destination | Origin passports with a full answer | Grounded | Source |
|---|---|---|---|
| United Kingdom GBR | 139 | 97% | VFS API |
| Canada CAN | 75 | 86% | VFS API |
| Austria AUT | 61 | 99% | Crawl + VFS API |
| Denmark DNK | 58 | 100% | Crawl + VFS API |
| Croatia HRV | 57 | 100% | Crawl + VFS API |
| Norway NOR | 55 | 100% | Crawl + VFS API |
| The Netherlands NLD | 53 | 100% | Crawl + VFS API |
| Ukraine UKR | 49 | 100% | VFS API |
| + 59 more destinations | 822corridors, from Sweden to Romania |
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
20 / 3404Proof
Known gaps
Stated plainly, because they are the first items on the build plan. All four are throughput problems, not unsolved techniques.
9 destinations
Thin policy pages
Australia, Azerbaijan, Georgia, Germany, Ireland, Israel, Lebanon, Thailand and Ukraine publish only a few nationalities, so most of their pairs still fall back to the reference dataset.
3 destinations
Unparsed policy pages
Brazil, South Korea and Montenegro. The page exists and was found, but is script-rendered. One hand-picked URL each resolves it.
398 filed
Mission websites not yet harvested
Embassy and consulate sites found in ministry directories, resolved to their host country and queued. They are the next full-answer layer for passports other than Indian ones.
API corridors
Jurisdiction depth
Consular-district rules exist for the crawled corridors. Answers built from the VFS content API still carry jurisdiction as unknown until the mission layer lands.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
21 / 3404Proof
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
22 / 3404Proof
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
23 / 3405Economics
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.
Measured today
What the three drivers actually cost
Fetching and serving the VFS estate: about $90 a year. Extraction: 1.3 cents per corridor that needs a model, and nothing where the source is already structured. Review: 2 material changes in the last 118-page run.
Modelled at scale
What they become at 40,000 corridors
Infrastructure rises to about $32,300 a year at full global coverage, and review to two to four people. Both are set out with their assumptions on the next slide.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
24 / 3405Economics
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 / 3405Economics
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 / 3405Economics · Commercials 1 of 2
Capex and opex
What it costs to build the platform, and what it costs to run it. Infrastructure is bought by VFS directly and is never marked up by 360 Labs.
Capex
Build once
Engineering, research and architecture. Initial source discovery and qualification. The knowledge model and pipelines. Platform and integrations. Initial infrastructure setup. 360 Labs fees are stated separately on the next page.
Opex
Run continuously
Source monitoring and re-fetching. Model usage on changed content only. Browser and residential egress where a source needs it. Storage, database and serving. Human review of material change. AI and ML operations and maintenance.
Infrastructure: rent it or own it
| Rented · serverless models and VPS | Owned · GPU cluster in VFS’s own racks | |
|---|---|---|
| Up front | $0 no commitment, no hardware | ~US$11,000 2-node cluster, through 360 Labs or a distribution partner |
| Running cost today | US$550 to 1,450 a month models, storage, serving, egress | Power, colocation and ops sized with your infrastructure team; hardware amortised over 3 years |
| At global coverage | ~$32,300 a year 39,800 corridors, 95% external sources | Cheaper per token, once utilisation is high |
| When it makes sense | Now, and until volume justifies otherwise. Serverless absorbs bursty crawling; you pay for what you use. | Only at sustained load, around 5M tokens an hour. Below that the cluster idles. |
Measured figures come from the corridors we already run. Owned-hardware running costs are modelled, because they depend on where VFS racks it.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
27 / 3405Economics · Commercials 2 of 2
360 Labs fees and total cost
One fixed build fee, one optional monthly fee, and nothing else passing through us. Add the infrastructure from the previous page to get the total cost of ownership.
360 Labs consulting and engineering fees
| Option 1 · Build and handover | Option 2 · Build and maintain | |
|---|---|---|
| Build fee | $26,000 | $26,000 |
| What it includes | A 4-person pod for 2 months: AI-native engineering lead, AI-native PM, 2 full-stack AI engineers. Registry build, extraction and grounding, review tooling, monitoring, documentation and training. | The same team, scope and 2-month timeline. |
| After the build | Structured handover; your team runs it. | $2,500 a month for 2 full-stack AI engineers: maintenance, source growth, model updates and improvements. |
Total cost of ownership · year one, fees plus rented infrastructure
| Coverage | Corridors | 360 Labs fees | Infrastructure | Year one total |
|---|---|---|---|---|
| VFS estate | 1,826 | $26,000 | ~$90 | ~$26,090 |
| Priority expansion | 5,000 | $26,000 | ~$3,900 | ~$29,900 |
| Broader coverage | 10,000 | $26,000 | ~$7,900 | ~$33,900 |
| Global | 39,800 | $26,000 | ~$32,300 | ~$58,300 |
With Option 2, add $30,000 a year of maintenance. Human review is costed in reviewer hours on the governance page. Infrastructure is billed to VFS directly, at cost.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
28 / 3406Governance
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.
Serving
Under VFS control
The knowledge base is served from VFS’s own environment, answering is a database read rather than inference, and it can be hosted in-region wherever residency requires it.
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
29 / 3406Governance
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
30 / 3407Delivery
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
31 / 3407Delivery
Relevant case studies
Three systems built on the same shape of problem: fragmented information that keeps changing and has to drive a decision someone is accountable for. Client names are withheld here and available under NDA.
A travel services group
Travel
AI proposes, a named human approves
The governance pattern this system uses: the model drafts, a person with a name signs off, and every decision is recorded against the record it changed.
Draft → review queue → named approval → published record
A global logistics operator
Logistics, top three worldwide
Documents turned into validated financial records
OCR extraction of transport and delivery documents, validation against the system of record, tax calculation, approval routing and generated invoices, now extending into their ERP.
Documents → extraction → validation → workflow
A national retail network
Retail and food service
Location-aware crawling, validated against a live source
Every customer postcode mapped to the store that could actually serve it, the serviceable inventory selected, and prices validated against a live third-party source.
Location → source → availability → validation
01 Problem02 360 Labs03 System04 Proof05 Economics06 Governance07 Delivery
32 / 3407Delivery
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
33 / 3407Delivery
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
34 / 34