None of these answers sit in one place. They depend on how things are connected: crew to trips, trips to flights, flights to aircraft, people to rules. That's why I built CrewOps on FalkorDB for the Graph Hacks hackathon. It keeps the whole operation in a graph and answers these questions by following the connections.

The setup

The data is a made-up week for three fictional airlines: 150 crew, 147 flights, six aircraft, reserve crew on call, certificates, 28 days of duty history, boarding gates and the people on duty at each station. Loaded into FalkorDB, that's about 6,000 nodes, and it loads in under a second.

There are five kinds of users:

• a reporter, who logs what went wrong

• a controller, who plans the cover (there are three desks)

• an approver, who has to be a different person from the controller

• crew, who only see their own schedule

• an auditor, who can read everything but change nothing

The graph

Here's the core of the model:

(:Crew)-[:ASSIGNED]->(:Pairing)-[:HAS_DAY]->(:DutyDay)-[:LEG]->(:Flight)
(:Flight)-[:ON]->(:Aircraft)-[:OPERATED_BY]->(:Airline)
(:Flight)-[:NEXT_LEG]->(:Flight)          // the aircraft's day, flight by flight
(:Crew)-[:HOLDS]->(:Certification)
(:Crew)-[:ON_CALL]->(:Station)            // reserve duty

A "pairing" is airline speak for a trip: one or more days of flying that a crew does together.

The part I'm happiest with is that decisions live in the graph too, not just data. When a disruption comes in, the analysis writes its results back as nodes and edges:

(:Disruption)-[:GROUNDS]->(:Crew)
(:Disruption)-[:HAS_GAP]->(:Gap)-[:OPTION {rank, cost}]->(:Crew)
(:Gap)-[:RULED_OUT]->(:Exclusion)-[:BREACHES]->(:Rule)
(:Plan)-[:APPROVED_BY]->(:User)

So the next person, the next agent, or the auditor all read the same picture.

Finding cover is just a walk through the graph

Who could possibly fly this seat? Only crew from the airline that operates the aircraft, at the right rank, who aren't already on the trip. In Cypher that's:

MATCH (p:Pairing {id: $pairing})-[:FLOWN_BY]->(:Aircraft)-[:OPERATED_BY]->(al:Airline)
MATCH (c:Crew)-[:EMPLOYED_BY]->(al)
WHERE c.rank = $rank AND NOT (c)-[:ASSIGNED]->(p)
RETURN c.id

Then one more query pulls everything the legality rules need for every candidate at once: their aircraft ratings, certificates, other duties, the last 28 days of duty hours, reserve windows, and whether anyone has reported them unavailable. Seven rules run on that, covering things like the 13-hour duty limit (which shrinks with each extra flight), 60 hours in any 7 days, and 12 hours of rest.

For our sick captain, 9 captains are considered and 4 are legal. The cheapest is recommended, a reserve captain at INR 23,090. Cancelling the trip would cost about 65 times more.

What I like most is the "why not?" part. If a controller asks why a certain captain wasn't picked, the answer is a short walk: Gap -> RULED_OUT -> Exclusion -> BREACHES -> Rule. For one captain it comes back as: would exceed 60 hours in 7 days by 1h20m on 13 Oct. No guessing, just the graph.

Delays travel along the aircraft

Delays were fun to model. When a flight runs late, the aircraft is late for the rest of its day, and so is the crew on it. With variable-length paths that's a few lines:

MATCH (f:Flight {id: $flight})
MATCH path = (f)-[:NEXT_LEG*0..12]->(g:Flight)
RETURN g.id, g.dep_ts, length(path) AS hop
ORDER BY hop

Each delayed flight then climbs up to its crew's duty day to check the limit. In my test case, a 90-minute delay stretches a four-flight day to 12.75 hours against a 12-hour limit, so the last flight has to come off that crew.

Two people, one write

In crew control you don't want software quietly changing the roster. So in CrewOps the agents only recommend. A controller submits a plan, and a different person has to approve it.

When they approve, the app checks legality again and recomputes a fingerprint of the plan and the roster it was made against. If anything changed in between, it refuses. Then the whole change happens in a single Cypher query: the crew swap, any cancelled flights, any moved gates or delayed departures. It all happens or none of it does.

Agents that share a graph instead of talking to each other

There are a few agents behind the app. A triage agent picks up new reports, works out what they affect, and writes the options back. A notifier tells the right people. An assistant answers questions.

They never call each other. They coordinate through the graph. A triage agent claims a disruption like this:

MATCH (d:Disruption {status: 'REPORTED'})
WITH d ORDER BY d.reported_ts LIMIT 1
SET d.status = 'ANALYSING', d.claimed_by = $agent

FalkorDB runs write queries on a graph one at a time, so two agents can never grab the same disruption. I tested this with four agents racing over six disruptions, and each one was claimed exactly once.

Memory is a graph too

Every user gets their own memory graph, in the same FalkorDB instance as the main one. It stores their conversations, the crew and trips they talked about, and their preferences.

That's what makes follow-ups work. If I ask "Who covers C-1042 on 13 Oct?" and then "Is she legal for it?", the assistant walks back through my memory graph to find who "she" and "it" were. When I come back the next day, it remembers what I asked last time.

The assistant uses free open models through Groq to decide which graph tools to call. The numbers always come from the graph, never from the model doing maths. If the model is busy or down, a simple rule-based planner answers instead, so the demo never breaks.

A few other things

• Graph algorithms as tools. PageRank and betweenness on the route network show that Bangalore is the hub everything depends on. Shortest paths suggest how to move crew between airports.

• Crew schedules. Desk roles can see every crew member's week across all three airlines. Crew only see their own.

What I learned

Put decisions in the graph, not just data. This was the biggest lesson. Once options, exclusions, plans and approvals were nodes and edges, the hard features became easy. Explanations, the audit trail, agent coordination and memory all turned into simple traversals.

Getting the rules right takes patience. Duty limits use calendar days, the duty limit shrinks with every extra flight, and a delay today can make someone illegal for a trip two days later. I worked out six scenarios by hand and kept fixing things until the graph matched every one of them exactly.

Free models need some care. Groq's free tier limits tokens per minute, and my first version blew through it in two questions. Sending only the tools the model actually needs, and switching to another model when one is busy, fixed it.

A few FalkorDB notes. It's fast, and having many graphs in one instance is great for per-user memory. I did hit a couple of things: EXISTS { } subqueries aren't supported (OPTIONAL MATCH and count() worked instead), and betweenness is sampled, so I set a fixed seed to get the same result every time.

Try it

• Live demo: crewops-falkordb.onrender.com

• Code: github.com/kashu94/crewops-falkordb

Sign in as Imran (a reporter) and report a sick crew member, switch to Ananya (a controller) to pick cover, then switch to Meera to approve it. Or open the assistant and ask "Who covers C-1042 on 13 Oct?".

All 123 Cypher queries are listed in the repo under docs/CYPHER.md, if you'd like to see how it all works.

Thanks for reading. I built this for Graph Hacks by WeMakeDevs and FalkorDB.