Crew Logistics Intelligence (CLI)
Place every legal crew in a recoverable room — then prove the enterprise can still recover.
One product / many tenantsPolicy-as-dataAI proposes / governed software disposesRecovery headroom first-classLightRAG hybrid evidenceLow-code tenant studioBattle-tested BT-01–18
30MUST FRs
9L3 capabilities
6value streams
18battle gates
Publication-safe boundary: public December 2025 inquiry material is used only as a case reference. Internal airline telemetry, meetings, system behavior, and unpublished operational facts are not asserted. EOS, headroom, graph, modes and CLI capabilities are proposed design capabilities unless explicitly marked otherwise.
Contents & cross-check status
Business case
Storyline, problem, urgency, market, fitment, investor pitch and CXO board.
Product architecture
Personas, journeys, L1–L5 capability model, six value streams, F-01–F-35.
Engineering contract
BRD FR-01–FR-30, NFR-01–NFR-10, BT-01–BT-18 and certification gates.
Consolidation corrections applied: Temporal is treated as workflow orchestration rather than the EOS/headroom store; occupancy is treated as the billing-event basis rather than “invoice truth”; event delivery is specified as durable at-least-once plus idempotency rather than an unrealistic universal exactly-once guarantee; booking identity includes a demand/layover instance; RuleCoverage freeze is scoped to tenant/station/rule-pack/effective-time; settlement/capability evidence is explicitly mapped; architecture uses one primary event backbone and one workflow engine.
1. Strategic storyline
Thin-margin industry
Airline economics leave little room for operational waste or disruption leakage.
Hidden fragility
Recovery can fail because legal room capacity, hotel inventory, transport, deadhead, decisions and policy evidence are fragmented.
CLI proposition
A governed system of record for demand, allocation, occupancy, standing instructions, decisions, outcomes and recovery headroom.
2. Problem
Core mismatch
Legal rest before next duty is a constraint; a reservation-exists model is not proof of recoverability. CLI therefore models legal-room envelopes, partner acceptance, occupancy events, transport linkage and decision ownership.
Failure modes
- Shared operational tables and hidden coupling
- Rules in code/comments rather than versioned policy
- Partner accept/reject not first-class
- Occupancy events disconnected from settlement
- Pickup changes hidden in transport UI
- No common Decision ID across hotel/cab/DHF
- No RuleCoverage freeze
- AI treated as an action-capable chatbot
3. Urgency & public case reference
Airline economics
IATA's June 2025 outlook projected 2025 airline net profit of $36.0bn, a 3.7% net margin and approximately $7.20 net profit per passenger. This is a profitability/resilience context, not a CLI savings claim.
Source: IATA, 2 Jun 2025.
December 2025 India disruption — public facts
MoCA/PIB reported 2,507 cancellations and 1,852 delays from 3–5 Dec 2025, affecting more than three lakh passengers. The inquiry cited over-optimisation, inadequate regulatory preparedness, system software support deficiencies, and management/operational-control shortcomings.
Source: Ministry of Civil Aviation / PIB, 17 Jan 2026.
Boundary: These public facts do not establish that CLI's proposed architecture existed in the affected airline, nor that any specific internal telemetry, meeting, software component, hotel inventory or decision path was observed. CLI uses the case to test resilience requirements, not to retrofit unverified facts.
4. Market & competitive white space
Crew / accommodation systems
Existing systems cover portions of crew management, hotel contracting, reservations, transport or passenger disruption.
CLI white space
Demand → legal allocation → partner confirmation → occupancy → settlement → Decision → Outcome → learning, governed by policy-as-data and recovery headroom.
Claim discipline
Third-party vendor claims such as percentage crew-cost reduction are not represented as CLI guarantees. All savings require tenant baseline and measured counterfactuals.
Planning ranges — scenario inputs, not market facts
| Metric | Planning range | Use |
|---|---|---|
| Cancellation impact | $10k–$50k / flight | Scenario model only |
| Delay-minute impact | $75–$150 / minute | Scenario model only |
| Hotel overflow premium | 40–80% | Scenario sensitivity |
| IROP hotel overrun | 15–25% | Scenario sensitivity |
| 100-flight IROP event | $0.5–$2m | Illustrative scenario |
| Duty-time violation | $25k–$50k | Illustrative risk-cost input |
5. P&L fitment
Value captured
- Hotel and transport cost avoidance
- Overflow premium reduction
- Deadhead / relocation waste reduction
- OCC minutes saved
- Leakage and ghost-room recovery
- Reduced cancel/delay exposure
Funding test
Baseline last-winter spend, define a counterfactual, measure room-on-time, overflow premium, recovery headroom, RuleCoverage and OCC minutes, and require tenant-2 onboarding without a Hotel microservice fork.
6. Investor pitch
Wedge
Publish-to-room + disrupt-to-reaccommodate.
Moat
Policy-as-data, canonical connector packs, decision/outcome evidence, recovery headroom and governed intelligence.
Kill tests
Tenant-2 Hotel fork; unowned Decision; shared CMS/HMS tables; failed battle tests; missing UCL/UEV ownership.
7. CXO board
| Stakeholder | Primary concern | Decision/control |
|---|---|---|
| CEO / Board | Resilience, reputation, capital efficiency | Fund/hold based on measurable recovery economics |
| COO / Accountable Manager | Safe operational recovery | Named authority; no unattended legality commit |
| CFO | Cost, leakage, contract economics | UCL/UEV and settlement evidence |
| CIO / CDO | Integration, data, platform | Canonical ports; one backbone; observability |
| CHRO / Crew | Duty/rest protection | Hard safety envelope |
| CCO | Commercial continuity | Recovery prioritisation without violating crew legality |
8. Product management verdict
ICP: scheduled carrier with a crew system, contracted hotel estate, OCC logistics desk and meaningful IROP volume.
Wedge: publish-to-room + disrupt-to-reaccommodate.
v1 exclusions: unattended legality L4; LLM side effects; rate negotiation; second event bus; per-airline Hotel microservices; regulatory compliance certification claims.
9. Why CLI
Design chain: regulatory constraint → crew capacity → roster → flight/aircraft plan → network capacity → recovery headroom → risk → named decision → hotel/TMS/PSS/notify → outcome → learning → human policy publish.
flowchart LR
A[Regulatory Constraint]-->B[Crew Capacity]
B-->C[Roster]
C-->D[Flight / Aircraft Plan]
D-->E[Network Capacity]
E-->F[Recovery Headroom]
F-->G[Risk]
G-->H[Named Decision]
H-->I[Hotel / TMS / PSS / Notify]
I-->J[Outcome]
J-->K[Learning]
K-->L[Human Policy Publish]
10. Strategy, capability, value-stream and operating-model loop
Differentiators
- Recovery before utilisation
- Policy-as-data
- Canonical connector packs
- Governed intelligence
KPI set
Recovery headroom; RuleCoverage; unsheltered legal rest = 0; room-on-time; overflow premium; partner confirmation; override/autopublish; tenant-N onboarding.
ARB questions
What strategic objective? Which L1–L5 capability? Which stakeholder experience changes?
11. Personas & authority
P-CREW, P-OCC, P-IROP, P-PLAN, P-FRM, P-HOT, P-TMS, P-FIN, P-CNT, P-ADM, P-EA, P-SRE, P-INT, P-REG, P-BRD.
flowchart LR
A[Proposal]-->B[OPA + RuleCoverage + Named Authority]
B-->C{Risk}
C--Low-->D[Deterministic Executor]
C--High-->E[Human Chair]
E-->D
D-->F[Decision ID + Outcome]
12. Operating journeys J1–J7
| Journey | Flow | Control |
|---|---|---|
| J1 Publish-to-room | CMS demand → validate → policy allocate → partner confirm → occupancy | booking identity + RuleCoverage |
| J2 Disrupt-to-reaccommodate | disruption → legal envelope → recoverable room → transport → notify | RECOVERY + hard rest block |
| J3 SI | standing instruction → evidence → policy version | source coordinates |
| J4 Partner occupancy | hold → confirm → check-in → checkout | event lifecycle |
| J5 Settlement | occupancy event → rate master → invoice line → exception | ERP rate master |
| J6 Learn | Decision → outcome → candidate policy change | human publish |
| J7 Admin | tenant → identity → policies → packs → conformance | RBAC + ARB gate |
13. L1–L5 capability model
L1: P3 Operations & Recovery.
L2: Crew Logistics.
| L3 | L4/L5 focus | Evidence / control |
|---|---|---|
| L3.1 Demand Sensing | Duty ingestion; demand instance; duplicate control | FR-01–03; BT-01–03 |
| L3.2 Hotel Operations | Allocation; confirmation; relocation; occupancy | FR-04–10; BT-04–07 |
| L3.3 Standing Instructions | Short/long/composite; conflict handling; evidence | FR-11–12; BT-08 |
| L3.4 Partner Operations | HMS events; PII masking; exception queue | FR-13–18; BT-09–11 |
| L3.5 Experience | CoordinationView; crew/OCC experiences | FR-14,26; BT-12 |
| L3.6 Settlement | Rate master; billing basis; leakage exception | FR-16,30; BT-13,15 |
| L3.7 Transport | Pickup re-pair; time linkage | FR-15; BT-14 |
| L3.8 Deadhead | Tail swap / DHF pricing and recovery | FR-24; BT-16 |
| L3.9 Operational Awareness | EOS; headroom; mode engine; graph overlay | FR-21–23,27; BT-17–18 |
Platform/governance are cross-cutting: P4 resilience/legality and P5 platform are not counted as additional L3 business capabilities.
14. Six value streams
| ID | Value stream | Outcome | Cycle-time target |
|---|---|---|---|
| VS-1 | Publish → Room | Legal room confirmed | File p95 ≤ 8 min pack |
| VS-2 | Disrupt → Reaccommodate | Recoverable legal room | Partner event p95 ≤ 60s |
| VS-3 | SI → Policy | Versioned policy | Governance controlled |
| VS-4 | Partner → Occupy | Auditable occupancy | Event-driven |
| VS-5 | Occupy → Settle | Accurate invoice lines | Event-driven |
| VS-6 | Exception → Learn | Evidence-backed candidate | Human approval |
15. Feature catalogue F-01–F-35
- F-01 Demand ingest dual-run
- F-02 Booking key
- F-03 Duplicate window
- F-04 Policy allocate
- F-05 Partner confirm
- F-06 Crew itinerary
- F-07 Recapture
- F-08 Cancel-then-rebook saga
- F-09 Midnight window
- F-10 Relocate + rest guard
- F-11 SSR on relocate PNR
- F-12 Pickup re-pair
- F-13 DHF/tail-swap priced
- F-14 Crisis queue classes
- F-15 Short/long SI
- F-16 Composite SI
- F-17 SI vs allocate conflict
- F-18 LightRAG SI assist
- F-19 HMS worklist
- F-20 Occupancy events
- F-21 Hotel master via Admin
- F-22 Partner PII mask
- F-23 ERP rate consume
- F-24 Invoice lines
- F-25 Leakage exception
- F-26 Exception queue
- F-27 EOS + headroom board
- F-28 Mode engine
- F-29 CoordinationView
- F-30 Outcome → candidate
- F-31 Tenant studio
- F-32 Runtime RBAC
- F-33 Pack marketplace bind
- F-34 Regulation ingest
- F-35 RECOVERY hard-block
16. Admin & control plane
| Area | Control |
|---|---|
| Tenant Studio | Stations, SLOs, envelopes, playbooks, flags |
| Policy Studio | Versioned policy-as-data |
| Pack Studio | Connector contracts and fixtures |
| Identity/RBAC | Tenant-scoped least privilege |
| Hotel Master | Master data through Admin events |
| Evidence Corpus | Immutable artifacts + source coordinates |
| Conformance / ARB | Decision, conditions, season lock |
| Observability | OpenTelemetry traces, metrics, logs |
| Settlement Map | Rate master → invoice line mapping |
17. Unit economics
UCL = (ContractedHotel + OverflowPremium + Transport + DHF + ExceptionLabour + GhostWaste + RelocationDelta) / FulfilledLayovers UEV = (AvoidedCancelValue + AvoidedIllegalRestValue + AvoidedOverflow + OCCMinutesSaved×CostPerMinute + LeakageRecovered) / FulfilledLayovers Spread = UEV − UCL Headroom $ = Residual nights/cabs/DHF seats × disruption option-value
| Metric | Measurement rule |
|---|---|
| Overflow premium | Contract baseline vs actual event spend |
| Ghost / duplicate waste | Unconsumed reservations identified through lifecycle evidence |
| OCC minutes | Time-to-decision / intervention effort |
| Time-to-legal-room | Demand accepted → legal room confirmed |
| Contract leakage | Expected entitlement vs settled amount |
| RuleCoverage freshness | Active rule pack coverage by station/effective time |
18. Low-code tenant-N model
Configuration
Stations, SLOs, allocation rules, SI catalogue, envelopes, packs, RBAC, playbooks and flags.
Code invariants
Booking-key uniqueness, outbox/inbox, saga compensation, rest hard-block, RuleCoverage freeze, isolation, Decision ownership and port contracts.
flowchart LR
A[Contract]-->B[Tenant Studio]-->C[IDP / RBAC]-->D[Policy]
D-->E[Mock Packs + Fixtures]-->F[Battle Tests Green]
F-->G[Live Flag]
G-->H{RuleCoverage PASS?}
H--Yes-->I[Season Lock Eligible]
H--No-->J[Hold / Freeze]
I-->K[Tenant-N Runtime]
19. LightRAG hybrid evidence plane
Local retrieval
PostgreSQL FTS + pgvector.
Global retrieval
Neo4j dependency / relationship graph.
Hybrid rule
Every retrieved claim must retain source coordinates before it can influence a proposal.
flowchart LR
Q[Query]-->G[Model Gateway]
G-->C[CODE]
G-->R[RULES]
G-->S[Bounded SLM]
G-->L[Challenge LLM]
M[MinIO Artifacts]-->X[Chunk + FTS + pgvector]
E[Operational Events]-->N[Neo4j]
X-->H[Hybrid Retrieval]
N-->H
H-->G
G-->P[Evidence-backed Proposal]
P-->O[OPA]
O-->Y{High Risk?}
Y--Yes-->HC[Human Chair]
Y--No-->D[Decision ID]
HC-->D
D-->EX[Deterministic Executor]
Forbidden for AI: legality commit, allocation/relocation, side effects, policy publish, season lock, mode change, or action without Decision ID. AI may assist SI interpretation, clause lookup, disruption playbooks, EA evidence, OCC brief and settlement variance analysis.
20. EA Governance OS
flowchart LR
A[Strategy]-->B[Capabilities + Value Streams]-->C[Initiative / Case]-->D[Artifacts]
D-->E[Evidence]-->F[Architecture Knowledge]-->G[OPA]
G-->H[SLM / LLM Decision Support]-->I[Findings / Risks / Options]
I-->J[Human ARB / Chair]-->K[Decision + Conditions]-->L[Conformance]
L-->M[Drift]-->N[Architecture Memory]-->A
| Concern | Reference component |
|---|---|
| Governance truth | PostgreSQL |
| Immutable evidence | MinIO Object Lock / immutable bucket policy |
| Search | PostgreSQL FTS + pgvector |
| Graph | Neo4j |
| Facts | One primary event backbone — Kafka/Apache Pulsar selected per platform decision; not both as parallel production backbones |
| Workflow | Temporal |
| Policy | OPA |
| AI control | Model Gateway + allow-listed MCP |
| Human authority | ARB / named operational chair |
21. Reference architecture — 15 views
A1 — Master CLI + EA Governance
flowchart TB
U[Channels / OCC / Crew / Admin]-->G[API Gateway]
G-->CLI[CLI Core]
CLI-->POL[OPA Policy]
CLI-->WF[Temporal Workflow]
CLI-->BUS[Primary Event Backbone]
CLI-->HMS[HMS Connector]
CLI-->TMS[TMS Connector]
CLI-->PSS[PSS / CMS Connector]
CLI-->SET[Settlement]
CLI-->OBS[OpenTelemetry]
BUS-->GOV[EA Governance OS]
GOV-->EVID[MinIO Evidence]
GOV-->DB[PostgreSQL Governance Truth]
GOV-->V[pgvector + FTS]
GOV-->N[Neo4j]
GOV-->AI[Model Gateway]
AI-->HC[Human Chair]
A2 — ARB stack
flowchart TB
S[Strategy]-->C[Capabilities]-->VS[Value Streams]-->OM[Operating Model]-->E[Economics]-->R[Risk]-->P[Platforms]-->D[Data]-->AI[AI]-->DEC[Decision]-->ACT[Action]-->OUT[Outcome]-->L[Learning]-->S
A3 — Logical runtime
flowchart LR
API[API / BFF]-->CORE[CLI Modular Core]
CORE-->POL[OPA]
CORE-->WF[Temporal]
CORE-->BUS[Primary Event Backbone]
CORE-->CACHE[Redis Cache]
CORE-->DB[(PostgreSQL SoR)]
CORE-->EVID[MinIO]
CORE-->AI[Model Gateway]
CORE-->EXT[Connector Packs]
A4 — Evidence to decision
flowchart LR
SRC[Source]-->E[Evidence]-->RET[Retrieval]-->PROP[Proposal]-->OPA[OPA]-->H{Human required?}-->DEC[Decision ID]-->ACT[Action]-->OUT[Outcome]
A5 — API/event/workflow integration
flowchart LR
API-->CMD[Command]
CMD-->DB
DB-->OUTBOX[Outbox]
OUTBOX-->BUS
BUS-->CON[Consumers]
CON-->WF[Temporal]
WF-->EXEC[Executor]
EXEC-->BUS
A6 — OpenShift / GitOps topology
flowchart TB
GIT[Git]-->ARGO[Argo CD]-->OCP[OpenShift]
OCP-->CP[Shared Control Plane]
OCP-->T0[Tenant Data Plane]
OCP-->OBS[OTel Collector / Metrics / Logs]
CP-->BUS[Primary Event Backbone]
CP-->WF[Temporal]
CP-->OPA[OPA]
CP-->AI[Model Gateway]
T0-->DB[(Tenant Data)]
A7 — Trust and security
flowchart LR
EDGE[Edge / API]-->ID[CIAM / IDP]
ID-->MTLS[mTLS / Workload Identity]
MTLS-->AUTH[RBAC / Policy]
AUTH-->TEN[Tenant Isolated Data]
TEN-->KMS[KMS / Key Management]
TEN-->AUD[Immutable Audit]
AUD-->MINIO[MinIO Object Lock]
A8 — Agent execution
flowchart LR
Q[Task]-->CODE[CODE]
CODE-->RULES[RULES]
RULES-->SLM[Bounded SLM]
SLM-->LLM[Challenge LLM]
LLM-->CIT[Citations / Coordinates]
CIT-->HITL[HITL if high risk]
HITL-->DEC[Decision ID]
DEC-->EX[Deterministic Executor]
MCP[Allow-listed MCP]-->CODE
A9 — Finding to conformance
flowchart LR
E[Evidence]-->F[Finding]-->R[Risk]-->O[Option]-->D[Decision]-->C[Condition]-->CONF[Conformance]-->DRIFT[Drift]
A10 — Resilience
flowchart TB
LAG[CMS Lag]-->ALARM[Alarm / Queue]
HMSD[HMS Down]-->MAN[Manual same cli.* events]
RC[RuleCoverage FAIL]-->FREEZE[Freeze Allocate]
DLQ[DLQ]-->REPLAY[Idempotent Replay]
REG[Region Loss]-->PLAT[Platinum SOP / Failover]
MODEL[Model Outage]-->L0[L0 deterministic/manual mode]
A11 — Architecture principles and technology decisions
| Decision | Locked principle |
|---|---|
| Application | Modular monolith first; split only for measured scaling/isolation reasons |
| Event backbone | One primary production backbone: Kafka or Pulsar selected by platform decision |
| Workflow | Temporal for durable workflow; not the system of record for EOS/headroom |
| Graph | Neo4j behind a graph port |
| Evidence search | FTS + pgvector first; LightRAG hybrid retrieval above it |
| Policy | OPA deterministic |
| Integration | Adapters / connector packs; no rip-and-replace requirement |
| Observability | OpenTelemetry-first |
| AI | Gateway, bounded JSON, citations, confidence/budget, L0 fallback |
A12 — P0–P9 delivery
flowchart LR
P0[Foundation]-->P1[Demand + Regulation]-->P2[EOS + Headroom + Mode]-->P3[Graph + Logistics]-->P4[Decision + Authority]-->P5[HOTAC Orchestration]-->P6[Crisis]-->P7[IROP Ready]-->P8[Learning]-->P9[Multi-Airline]
A13 — Guardrails
flowchart TB
G1[No shared CMS table]
G2[No HMS Hotel DB sharing]
G3[No stale legality allocation]
G4[No unattended legality]
G5[No unowned Decision]
G6[No autopublish]
G7[Source coordinates]
G8[MCP allow-list]
G9[Model outage -> L0]
G10[No tenant Hotel fork]
G11[No second AI event bus]
A14 — Board architecture acceptance
flowchart LR
SUB[Submission]-->ARB[ARB Review]
ARB-->ACC{Accept?}
ACC--Yes-->LOCK[Season Lock Eligible]
ACC--No-->HOLD[Hold / Reject]
LOCK-->CONF[Conformance]
CONF-->DRIFT[Drift Monitoring]
DRIFT-->ARB
A15 — Operating modes
stateDiagram-v2
[*] --> NORMAL
NORMAL --> WATCH
WATCH --> DISRUPTION
DISRUPTION --> CRISIS
CRISIS --> RECOVERY
RECOVERY --> NORMAL
WATCH --> NORMAL
DISRUPTION --> RECOVERY
22. BRD — 30 MUST functional requirements
| ID | MUST requirement | Acceptance / gate |
|---|---|---|
| FR-01 | CMS duty → Demand with dual-run | BT-01 |
| FR-02 | Booking identity: tenant + crew + demand/layover instance + GMT window; unique/idempotent | BT-02 |
| FR-03 | Duplicate detection window | BT-03 |
| FR-04 | Cancel-then-rebook saga | BT-04 |
| FR-05 | Midnight / 24h station window | BT-05 |
| FR-06 | Policy-as-data | BT-08 |
| FR-07 | Hold → confirm → occupy → checkout lifecycle | BT-09 |
| FR-08 | No-show / early / late / extension billing events | BT-10 |
| FR-09 | Relocation rest envelope | BT-06 |
| FR-10 | SSR on relocated PNR | BT-07 |
| FR-11 | Short/long/multiple/dual-origin SI | BT-08 |
| FR-12 | Composite SI | BT-08 |
| FR-13 | HMS separate data boundary/master via Admin events | BT-11 |
| FR-14 | Operational notification under 60s event target | BT-12 |
| FR-15 | Hotel time → TMS | BT-14 |
| FR-16 | ERP rate master consumption | BT-13 |
| FR-17 | Runtime roles / RBAC | BT-15 |
| FR-18 | Exception queue using same canonical events | BT-15 |
| FR-19 | Regulation ConstraintChanged / Abeyance events | BT-18 |
| FR-20 | Winter × constraint impact analysis | BT-18 |
| FR-21 | Compute and persist temporal EOS/headroom snapshots; Temporal orchestrates the workflow | BT-17 |
| FR-22 | Mode engine | BT-17 |
| FR-23 | Dependency graph / logistics overlay | BT-17 |
| FR-24 | DHF / tail-swap priced | BT-16 |
| FR-25 | Crisis queue prioritises crew hotel before commercial recovery actions where configured | BT-06 |
| FR-26 | Masked CoordinationView | BT-12 |
| FR-27 | RECOVERY blocks utilisation-maximisation when recovery policy requires it | BT-17 |
| FR-28 | Unowned Decision cannot act | BT-15 |
| FR-29 | RuleCoverage FAIL freezes allocation for affected scope | BT-18 |
| FR-30 | Every Decision has Outcome; learning produces candidate only | BT-15 |
NFR-01–NFR-10
| ID | Requirement |
|---|---|
| NFR-01 | Tenant isolation |
| NFR-02 | Durable event delivery with at-least-once semantics, idempotent consumers and replay/DLQ |
| NFR-03 | Partner confirmation p95 target ≤60s for the defined event class |
| NFR-04 | Notification target under 60s for defined operational events |
| NFR-05 | Envelope switch is versioned, auditable and safety-gated |
| NFR-06 | Platinum resilience profile with explicitly defined active/active semantics and no unsafe dual-write |
| NFR-07 | OpenTelemetry traces, metrics and logs with correlation IDs |
| NFR-08 | PII masking and residency controls |
| NFR-09 | Retention and immutable evidence policy |
| NFR-10 | AI gateway budget/confidence controls, bounded JSON, allow-listed tools and deterministic/manual L0 fallback |
23. Battle tests, certification & operating process
BT-01–BT-18
| Gate | Test intent |
|---|---|
| BT-01 | Dual-run CMS demand ingest |
| BT-02 | Booking-key idempotency / uniqueness |
| BT-03 | Duplicate-window suppression |
| BT-04 | Cancel-then-rebook compensation |
| BT-05 | Midnight / station window |
| BT-06 | Mass IROP / crisis prioritisation and legal-room protection |
| BT-07 | Relocation PNR / SSR consistency |
| BT-08 | SI policy composition and conflict |
| BT-09 | HMS occupancy lifecycle |
| BT-10 | No-show / early / late / extension settlement |
| BT-11 | Partner boundary / PII masking |
| BT-12 | Notification / CoordinationView latency |
| BT-13 | ERP rate / settlement mapping |
| BT-14 | Hotel → transport time linkage |
| BT-15 | Decision ownership / outcome / RBAC |
| BT-16 | Hub hotel exhaustion + DHF/tail-swap recovery economics |
| BT-17 | Late mode switch / EOS-headroom recovery |
| BT-18 | RuleCoverage failure / regulation change freeze |
Certification: Core RC requires BT-01–05, 08, 10, 13, 15, 18. IROP readiness adds BT-06, 07, 09, 12, 14, 16, 17. Ecosystem certification requires BT-11. Adaptive operation requires two game-days plus human policy review.
Operating cadence
| Cadence | Participants | Purpose |
|---|---|---|
| Daily | OCC | Headroom, exceptions, mode |
| Shift / IROP | OCC, IROP, Duty | Recovery and legal-room control |
| Weekly | Planning + FRM | Constraint / capacity review |
| Weekly | Finance + Contracting | Leakage / UCL / UEV |
| Sprint | Product + SRE | Delivery / reliability / BTs |
| ARB | EA + Board | Conformance / architecture decisions |
24. Validation, evidence boundary & acceptance
Publicly established
- MoCA/PIB inquiry and disruption statistics
- Inquiry findings on over-optimisation, regulatory preparedness, software support and operational control
- ₹50 crore bank guarantee ordered for compliance/systemic correction
- IATA 2025 profitability context
Not claimed
- Internal airline telemetry or meetings
- That the affected airline had EOS/headroom/graph capabilities
- Any regulatory compliance certification
- That proposed demo data is historical airline data
- Any guaranteed percentage savings
Hold conditions
| Condition | Disposition |
|---|---|
| New CMS/AIMS consumer requires shared operational table | HOLD |
| HMS shares Hotel DB | HOLD |
| SI exists only as free-text comments | HOLD |
| Hotel rules embedded in Transport | HOLD |
| Tenant-specific Hotel microservice fork | HOLD |
| Autopublish / unowned Decision | HOLD |
| Second event backbone introduced for AI | HOLD |
| Compliance claim without authoritative certification | HOLD |
What the airline is being asked to accept
Fund CLI as the system of record for trusted, legal and recoverable crew logistics; make recovery headroom first-class; externalise policy as versioned data; maintain explicit decision ownership; use AI for evidence-backed proposal and challenge rather than autonomous operational side effects; and prove the architecture through repeatable battle tests and tenant-N conformance.