Set the rule. Apply it everywhere. Prove every decision.

Your officers write the admissibility rule. Nibomont applies it at the departure desk — every desk, every shift, the same way — gathers the facts from your own records, and seals each decision into a record one of your officers signs.

Single-tenant, deployed inside your own estate. Your records stay where they are. Bilingual interface, and the interview reads in around sixty languages.

The Nibomont officer inbox: cases awaiting a decision, each with a system verdict, a confidence band and an SLA state.

The officer queue — every referred case, one decision each

A case record showing how the decision was reached: the desk flag, the interview turns, the scenario considered, and a second reading of a failed requirement that disagreed with the first and was referred to an officer.

Every case answers one question: how did we get here? The desk flag · the interview · the checks · the conclusion

The problem.

The same rule, read differently at every desk.

One rule your officers wrote is applied by hundreds of agents who do not work for you, at desks you do not see, on every shift. Some read it one way and some another, some ask and some do not — and when a decision is later questioned there is no record of which facts were checked, what the traveller was asked, or who decided.

An admissibility decision is only as good as the record of how it was reached.

Nibomont exists to produce that record as a by-product of applying the rule properly — not as paperwork afterwards, and not as something an officer has to remember to write down.

One passenger.

One traveller, from a stalled check-in to a sealed decision.

  1. Check-in stalls The document isn't found. Today that means a sheet of rules, or a phone call to someone who knows.
  2. The airline's own system flags it Nibomont doesn't replace the carrier's system. On submit your registers answer, and back comes your directive — no boarding pass, no guesswork at the desk.
  3. The case hands over intact The agent scans the hand-off code. Five factors arrive prefilled: nothing retyped, nothing drifts.
  4. The interview gathers what's missing One open question starts it, then a turn at a time — while the registers are queried live, system to system. Nobody on the phone.
  5. One of your officers decides The case lands in your inbox with the conclusion, the whole conversation, and every check behind it. A person decides, by name, and the first to act resolves it for everyone.
  6. Sealed, and the desk is told The outcome joins a tamper-evident chain and the agent's phone says so. The passenger gets their boarding pass.
AeroDesk · Check-in
FlightNX418 · BKK → BRU
PassengerMai Rattana
DocumentPassport · AB4471902
NationalityTHA
AeroDesk · Result
DOCUMENT_NOT_FOUND No visa record for this document.
Contact government Boarding withheld. Hand the case to Nibomont.

Scan to continue on any device

Nibomont · Security check

Five details, as recorded at check-in.

First nameMai
Last nameRattana
DocumentAB4471902
Date of birth06-06-2003
FlightNX418
Matched · case opened
RouteBKK → BRU · dep 18:40
NationalityTHA
Referred byDOCUMENT_NOT_FOUND
CaseNB‑46‑2207

Next: the traveller’s explanation, in their own words.

Nibomont · Interview
Before we begin — in the passenger's own words, what is their situation?
She holds a Belgian Schengen visa, issued in Bangkok.
Visa register · queried 0.4s
Is the visa multiple-entry?
Single entry, and it has been used.
Requirement not satisfied · second reading disagreed
Referring to a duty officer.
Nibomont · Resolved
Approved Confirmed by a named officer
Decided byDuty officer · 14:22
Chaina19f…7c40
Defence packReady
Cleared to travel · boarding pass issued
Nibomont · Console Inbox · case NB‑46‑2207
System recommendation REVIEW The two readings disagreed — an officer decides.
TravellerMai Rattana · THA
FlightNX418 · BKK → BRU
Interview6 turns
Checks run4 lookups
Waiting2 min
Product.

Four surfaces. One authority behind them.

Scroll

One front door, whoever the carrier is

Any airline's agent hands a stuck boarding request to the same portal and re-proves identity from five details on the travel document. No carrier integration to negotiate, and no account to issue.

The verification portal on a phone: the passport MRZ scan field and the first of the five details the desk agent re-confirms.

Your rules, in your own words

An officer writes the admissibility rule as a sentence. Nibomont compiles it into the facts it needs, which of those a government source must attest, and the question to ask when nothing can. Policy changes the day you change it, without a release.

The scenarios screen: each rule with its outcome, the facts it requires, its priority and whether it is enabled.

Your Records, asked first

Visa, passport, national ID and watchlist lookups run before the traveller is asked anything. Your own records answer first, in your own order of precedence, and an outage falls back to asking — never to guessing.

The integration layer: your built-in records at lookup order zero, then connected external APIs probed after them.

The numbers a directorate asks for

Decisions per day by outcome, how many were settled by rule versus referred to a human, the top refusal grounds, and how long officers took to answer — by shift and by post. Exportable.

The analytics dashboard: sessions, approved, denied, escalated and interrogated counts, decisions per day by outcome, decision source and top deny reasons.
How it works.

Screening moves to the departure desk, decisions stay with you.

The traveller is assessed before they fly, not on arrival — so the ones who would be refused never reach your border, and the ones who would be cleared are not delayed. Every step writes one row on a tamper-evident chain, so the order things happened in is provable months later.

Walk through a live case
Check-inFlagged at the desk, not at the gate
RegistersAsked before the passenger is
InterviewDeterministic questions, one at a time
Your officerOne queue, one decision, first click wins
01

Interview at the desk

A referred traveller is asked a short, deterministic set of questions — no free-running chatbot, and no discretion at the desk. The airline's agent reads them off their own screen, in the desk’s own language, and a photographed document can answer several at once.

02

Facts before testimony

Every fact carries where it came from. A register that identifies the holder outranks the passenger's word, which outranks a third-party API. A rule may demand that a fact be government-attested — and if nothing can attest it, the case goes to a human.

03

Evidence you can hand over

One click produces a signed pack: the case record, the exhibits, and an Ed25519 signature a court, a carrier or an oversight body can verify without holding any secret of yours — built for an adversarial reader, not for your own audit.

04

One queue for officers

Referrals land in one inbox with an SLA, oldest first. The first click wins, an escalation path reaches a senior officer, and nothing is ever decided twice or by nobody.

Security posture.

Built to be inspected, not taken on trust.

Encrypted at rest

Passenger identity and every derived record are Fernet-encrypted under a key held outside the database, with searchable blind indexes instead of plaintext.

Tamper-evident chain

Each state change appends a keyed HMAC row chained to the last, so a database writer cannot rewrite history without the chain reading as broken.

Independently verifiable

Case packs are signed with Ed25519 — a court or an oversight body verifies one with a public key, deliberately not the same primitive as the internal audit export, so proving a decision never means sharing a secret.

Least privilege

Permissions are a frozen catalogue, roles are bundles of them, TOTP can be forced, staff SSO speaks OIDC, and no account can grant a permission it does not itself hold.

Retention purges on a clock, erasure actually erases, and personal data is masked in every outbound payload by default. Nothing about a traveller leaves the deployment unless you configure it to.

Questions.

Frequently asked questions

What the system is, what it deliberately is not, and where it sits relative to the carriers, your registers and your officers.

Ask us something else
Does it take the decision away from our officers?
No. Your deterministic rules can refuse outright, and a clear rule can clear a traveller — but anything uncertain routes to a named officer of yours, and that officer's decision is the one on the record. The system's job is to make the decision cheap, fast and evidenced; the authority stays with the authority.
Who actually uses it?
Two, in different places. The airline's desk agent reads the questions off their screen — which is why every question is phrased in the third person about the traveller — and your officers work the console. The traveller has no account and never sees either.
Does any of our data leave our estate?
No. It runs as a single-tenant deployment inside your own estate, on your infrastructure. Registers stay where they are and are read through a provider seam — a local database, your own HTTP API, or an existing government backend — so no authority data is copied to us or to a carrier.
What happens when a register is down?
An outage is never treated as a clean result. The lookup is recorded as unavailable, the interview falls back to asking, and a rule that requires a government-attested fact refers the case to one of your officers rather than clearing anyone on a missing answer.
What languages does it work in?
The console and the desk ship in English and Arabic today — authored rule content included, translated against a reviewed administrative termbase rather than machine calques. A further interface language is a translation pass, not a rebuild. The interview itself can already be displayed in around sixty languages without changing a word of the record.

Bring us one corridor and one month of refusals.

We will show you what the record would have looked like for each one, how many would never have boarded, and how many of your officers' hours it would have taken back.