Crew layover support
A nine-hour overnight and a twenty-two-hour layover are not the same trip.
CREW Downtime is the one entry in this portfolio with no working software behind it at all. It is a written product design for a crew-facing companion that knows the person, the place and the time remaining, and uses all three to rank what is actually worth doing before the next duty. It is on this site because leaving it off would misrepresent the portfolio — and it is labelled CONCEPT because every capability below is design intent.
Status Concept and scaffold only. Nothing has been built or demonstrated — every capability on this page is design intent.
The problem
A generic search for things to do in a city answers none of the questions a crew member actually has. It does not know when they landed, how long they have before the next duty, whether anything is still open, what they personally like, or whether they can read the signs. So the default becomes the hotel restaurant, and a layover that could have been a break is not one.
The answer
The design captures an About You profile once at onboarding, reads position automatically instead of asking for a city, and filters every suggestion against arrival time and remaining layover. Its central rule is rank, do not filter: the full result set is returned with profile matches floated to the top, so a crew member who likes barbecue still sees the vegan place — it simply ranks lower. Alongside that sits a two-way voice interpreter and camera sign translation, so the language barrier stops being the thing that decides the evening. None of this is built.
What it does · 5 capabilities
Each capability below exists in the build described on this page. Anything planned rather than present appears under status, not here.
Onboarding is intended to capture language, interests, food preferences and budget, so that the companion starts from the person rather than from a blank search box. Design intent — no onboarding flow exists.
The full result set would always be returned, with profile matches floated to the top and nothing hidden. This is the trust rule of the design: the companion personalises the order, it does not gatekeep the options. Design intent — no ranking engine exists.
Position read automatically rather than typed, and every suggestion checked against arrival time and remaining layover so nothing surfaces that is already closed or will not fit the window. Design intent — no location or scheduling logic exists.
Press to listen, hear the reply in your own language, answer in yours and have it spoken in theirs — a bidirectional interpreter for face-to-face conversation. The underlying speech and translation pipeline is proven elsewhere in the KBM portfolio; it has never been demonstrated in this product.
Point the camera at a sign, a menu or a notice and read it in your own language, then ask AlbertAI a follow-up about what was captured. Also proven elsewhere in the portfolio, also never demonstrated here.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
The design is advisory throughout: it suggests, ranks and translates, and the crew member decides. Nothing in it touches flight duty, rest requirements, crew scheduling or any operational system, and it is deliberately outside the safety-critical boundary the rest of this portfolio sits inside. An interpreter output is an aid, not an authority — a translation is offered for a human to judge, never as a decision the software has made.
This is the most privacy-sensitive design in the portfolio, and none of it has been implemented — no profile has been captured, no position read, no camera or microphone opened, because there is no application. A real build would hold a personal profile, continuous position, and camera and microphone access, which is exactly the combination that demands explicit, granular consent, a clear retention position and a documented answer on who may see a crew member’s location. That consent design is a precondition of any pilot, not a later refinement, and it does not exist yet.
Not applicable, and it would be dishonest to describe one: there is no application to degrade. A real build would need a defined answer for a lost position fix, an unavailable places provider and an interpreter that cannot reach its speech services — with the honest failure being to say so plainly rather than to return a confident answer built on nothing.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · Concept
Concept and scaffold only. Nothing has been built or demonstrated — every capability on this page is design intent.
Claims and evidence
If a claim below is worded more strongly than its basis justifies, it is a defect and we want to hear about it.
| Claim | Tier | Basis |
|---|---|---|
| Every capability described for this product is design intent. Nothing has been built or demonstrated. | Evidence tier:Concept | Product brief only, plus an unexercised repository scaffold. |
| The design ranks results rather than filtering them, so nothing is hidden from the crew member. | Evidence tier:Concept | Stated design principle in the brief. No ranking engine exists to exhibit it. |
| The interpreter and translation halves would reuse speech and translation pipelines already built elsewhere in the KBM portfolio. | Evidence tier:Modeled | Architectural assessment against existing components. Those components have not been demonstrated in this product, and integration effort is an estimate. |
| The concierge half cannot be built until a live places and events provider is contracted. | Evidence tier:Modeled | Dependency analysis in the brief. The commercial terms are unresolved. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
Because omitting it would tell you less about us than including it. It is labelled CONCEPT, its status line says nothing has been built, and its claim register contains no DEMONSTRATED entry. If you would rather spend your time on something you can exercise, every other product on this site is exercisable and this one is not — that is the honest sort order.
They should not accept it on the current answer, because the consent design does not exist yet. That combination is the most sensitive in the portfolio and it needs explicit granular permissions, a stated retention position and a clear answer to whether an employer can ever see a crew member’s location — our starting position being that they cannot. Those are preconditions of a pilot, and we would rather have this argument before a build than after one.
A contracted places and events provider on workable terms, a native mobile shell for position, camera and microphone, a reviewed consent design, and a latency target for the interpreter. The interpreter and translation pipelines already exist elsewhere in the portfolio, so the build is smaller than it looks — but the dependencies above are not code, and none of them is closed.
Who buys this
The operators whose problem this product is actually shaped around. Each has its own path from first contact to a decision.
The people the rest of this portfolio is ultimately about — pilots and cabin crew, whether flying a scheduled regional line, an on-demand charter leg, or a light aircraft on a private flight.
Scheduled carriers running turboprop and regional-jet fleets, often on capacity-purchase agreements, with a real operations control centre and no eight-figure software budget.
Next step
The useful conversation here is not a demonstration, because there is nothing to demonstrate. It is whether crew layover quality is a problem worth solving at your airline — and if it is, what would have to be true about consent before crew would use it.