AVIANIS scoping workspace.
Where we are before writing the engagement proposal. Reconciles the team's reviews, lays out the five ecosystem areas from Patrick's diagram, sizes the six potential builds, and collects the open questions and constraints in one place. Everyone on the team sees the same workspace in real time, with each edit attributed.
The engagement, and the builds.
There are two separate things going on in this project, and a lot of the risk we're carrying comes from them getting tangled together in conversation.
The first is the engagement itself, which is the paid scoping and roadmap work that Bill and Patrick are asking us for. Bill's email is explicit that he wants a quote on this work before we undertake it, so getting that quote in front of him is the next blocker we need to clear. The shape of the work is clear even if the price isn't yet. We're being asked to figure out what AVIANIS actually does, who relies on its data downstream, what would need to exist if it were unplugged, and which of the proposed builds are real candidates for development.
The second is the actual builds underneath. There are six potential build streams in play right now (NOTAMs, the McD's board, the passport portal, the v5 work on Flight Concierge, the broader trip support module, and crew scheduling), and none of them are properly sized yet. The whole point of the engagement is to size them, which means we shouldn't be agreeing to build any of them at this stage. The roadmap is the deliverable that converts them into real go/no-go line items.
The discipline we need is to keep these two things separate in our heads even when the client conversation mixes them. If someone in a meeting says "and also crew scheduling," the right move is to treat it as an addition to the discovery scope rather than a build we've signed up for. Waqar's framing about meetings not equating to commitments captures the same idea, and a version of that line probably belongs in the proposal as a written clause.
How we look at each domain.
Every one of the six build domains gets read through two lenses. They're how we decide what could be quoted as a standalone piece now, what has to wait, and what we shouldn't be quoting at this stage at all.
Rule 1. Endstate-dependent versus standalone
The first question is whether a given build depends on the system-of-record decision, by which I mean what eventually happens to AVIANIS. Some of the proposed builds make sense regardless of that decision and can be quoted now. Others can't be properly scoped until we know whether AVIANIS stays, partially stays, or goes away. NOTAMs is the clearest example of the first kind, because it doesn't sit inside AVIANIS in the first place, so it doesn't have to wait on any of the bigger questions.
Rule 2. AI-interfacing versus system-replacement
The second question, which I think is Arthur's main contribution, is whether we're putting an LLM on top of something that already exists, or whether we're building a brand-new system from scratch underneath the AI. Arthur is suggesting we interface LLMs onto existing systems (including AVIANIS itself, if necessary) before committing to replace anything underneath them.
This matters because Bill's actual blocker, by his own description, is that he can't justify the ROI of a full replacement. AI interfacing is a lot cheaper and faster to demonstrate than replacement, and it gives Mike a visible win without making him sign off on the much bigger number that replacement would require.
Patrick's framing in his email pulls in the opposite direction. His language is about developing the system first and then implementing the AI Concierge on top of it. That isn't necessarily wrong, but it's a different bet, and the proposal will need to make our case carefully because Patrick is already anchored on his framing.
Independent convergence.
Arthur's scope analysis, Waqar's discovery notes, and Hamza's earlier working notes have looked at this picture independently. They use different framings and different vocabularies, but they end up at roughly the same caution: we shouldn't agree to replace AVIANIS wholesale before defining what "replacing AVIANIS" actually means in concrete terms.
That convergence matters more than any one specific recommendation in this document, because three people working independently arrived at the same warning. The job of the proposal is to take that warning and make it legible to Bill and Patrick without sounding like we're hedging on the work itself.
What lives where in Patrick's diagram.
Patrick's diagram divides trip management at Execaire into five distinct functional areas. Each one has its own workflows, its own data flowing in and out, and its own set of AI opportunities that Patrick has already flagged inside the picture. The six build domains all live inside one or more of these areas, so understanding the areas first makes it easier to see which builds touch which parts of the operation.
The diagram is below. The five regions are clickable, so hovering shows the area name and clicking jumps to that area's detail card. The area cards underneath include the functions, inputs, outputs, AI opportunities, and which build domains touch each area.
1.Dispatch
Flight Following + Flight Planning- Updates logistics when a flight is delayed, cancelled, or arriving early.
- Ensures aircraft land at the planned destination and triggers ERP if an aircraft is overdue.
- Monitors weather and NOTAMs at destinations.
- Disseminates ATC delays to flight crew.
- Triggers flight planning workflows on a time-based schedule: flight plan built 60 hours before ETD, fuel completed 12 hours before, filed 12 hours before, weather and NOTAMs checked 6 hours before.
- Sets up fuel based on fuel marketplace data and tankering analysis.
- Actual aircraft movement times from FlightAware API.
- Flight plan details from ARINCDirect.
- Feasibility status and contract fuel prices.
- Aircraft actual departure and ETA, sent to FlyExecaire.
- Movement data to external stakeholders, including email.
- Leg details to ARINCDirect for flight plan generation and changes.
- Automatically monitor weather and NOTAMs at destination and alternate airports.
- Generate movement emails and send to logistics stakeholders.
- Automatically generate flight plans.
- Build and adjust flight plans based on LLM review of pilot flight plan requests.
2.Flight Concierge
The blue box: passenger, itinerary, logistic bookingPassenger Management. Add and remove passengers from legs. Create passenger records with name, DOB, email, phone, residency, gender, linked account and aircraft, family tree association. Edit and inactivate passengers. Store preferences and travel documents (passports, visas, permanent residency). Securely acquire travel documents.
Itinerary Management. Create a trip with status, type, primary contact, flight concierge responsible, sales manager responsible, attending maintenance engineer, regulatory standard (CAR 604 etc.), departure and arrival ICAOs, scheduled ETD and ETA, flight time calculation, leg status, departure and arrival handling agents. Inactivate, edit, add legs, remove legs, move legs between trips, conduct and monitor feasibility.
Logistic Booking (Concierge side). Build service requests for catering, chauffeured transportation, rental car. Each request type has different fields. Set completion due date, cancel, edit.
- Travel documents from secure system; travel status from government systems; immigration requirements.
- FlyExecaire change requests, Azure user data (flight concierge info), arrival trip log data from FlyExecaire (actual OOOI times).
- Internal Execaire aviation systems.
- Submission of passenger data to government systems (EU-LISA, US eAPIS).
- Generated general declaration PDF.
- Submitted requests for travel documents.
- Leg details and service request details passed to Dispatch and Trip Support.
- Passenger creation, editing, and assignment via LLM prompt.
- Suggest passengers based on historical data.
- Identify duplicate passenger records.
- Validate immigration status (feasibility).
- Review travel documents for errors.
- Read passport data.
- Itinerary creation and editing via LLM prompt; suggest trips based on historical data.
- Service request creation and editing via LLM prompt.
3.Trip Support
Logistic Booking (Trip Support side)- Automatically creates service requests based on trip and leg details (for example, landing permit service request for legs to Cuba, US CBP request when landing in the USA).
- Creates and edits service requests with type-specific fields (catering, landing permit, overflight permit, etc.).
- Generates, sends, and receives permit request forms.
- Monitors trip changes and executes logistic updates.
- Monitors service request status holistically and executes based on time-based workflows.
- Leg details, service requests created by Flight Concierge.
- Passenger details and due dates for each service request.
- Leg changes.
- Service request status.
- Issues with service acquisition (e.g. customs not available, parking not available).
- Draft and send permits automatically.
- Receive and interpret permit approval using LLM.
4.Crew Management
Schedules, compliance, training- Builds and edits crew schedules.
- Manages days off and vacation approval workflow.
- Enters training events by type.
- Provides a crew statistics dashboard.
- Monitors Canadian duty time regulations.
- Monitors and reports on flight crew overtime based on corporate policy.
- Assigns and removes crew from flights based on crew availability and compliance.
- Vacation and days-off requests from FlyExecaire.
- Training schedule from third-party provider (e.g. CAE).
- Training status of crew from LMS / QMS.
- Crew assignment from elsewhere in the system.
- Crew availability.
- Crew statistics (flight time, time away from base).
- Crew regulatory compliance status.
- Build crew schedules automatically based on tail-specific crewing model (days off, workload balancing).
- Assign crew automatically based on schedules and trips.
5.Charter Sales
Quoting and pricing- Generates sales quotes including account, primary trip contact, departure and arrival ICAOs, scheduled ETD and ETA, flight time calculation.
- Calculates sale price (payback to aircraft owner + flight costs + margin = sale price).
- Adjusts cost data and sales price; manages aircraft-specific payback rates.
- Sets charter terms and conditions on a per-tail basis.
- Generates and sends sales quotes for electronic signature.
- Airport and navigation cost data.
- Feasibility status, flight time calculation.
- Trip changes that result in re-quote under new assumptions.
- Sales data.
- Trip details for downstream processes.
- Countries overflown, used to create service requests.
- Automatic quote generation and distribution.
- Build quote based on AI interpretation of aircraft owner's rules of engagement (e.g. charge additional fee if leg less than one hour).
What's actually on the table.
The original conversation was about four build domains: NOTAMs, the McD's board, the passport portal, and v5 (the Flight Concierge AI). Two more have been added since. Crew scheduling came up in the most recent call as "the last component missing," and the Trip Support reframing has gone from being just a board to being a fuller module replacement with data migration off AVIANIS. That puts us at six.
The summary table is the at-a-glance view. Each row links to the full card below. Crew scheduling stays "unknown" on complexity deliberately because the call notes don't yet have enough detail to rate it honestly. The v5 row shows two ratings because the gap between "interface only" and "full replacement" is the entire strategic question we have to answer in the proposal.
| Domain | Complexity | Creep risk | Endstate-dependent |
|---|---|---|---|
| NOTAMsFlight Following | Medium | Low | No |
| McD's boardTrip Support, narrow | High | High | Yes |
| Trip Support moduleMcD's board, expanded | Very High | Very High | Yes |
| Passport portalPassenger management | Medium | Medium | Partial |
| v5Flight Concierge AI | Med / VH | High | Yes |
| Crew schedulingNewly added | Unknown | Very High | Likely yes |
1.NOTAMs
Flight Following2.McD's board
Trip Support, narrow scope3.Trip Support module
McD's board, expanded4.Passport portal
Passenger management5.v5
Flight Concierge AI6.Crew scheduling
Newly added; walled offWhat the discovery phase has to answer.
These are pulled from Waqar's notes, Arthur's open questions, and the email thread. They're grouped by area for legibility rather than priority. The engagement work itself will set the order of operations.
Operational
- What triggers ERP today, who owns it, and what does the integration actually look like?
- FlightAware data: pull or push? This shapes how Flight Following actually receives movement data.
- Where do contract fuel prices come from? Who owns that integration today?
- Movement email: current recipient list, format, and generation step. Who depends on this exact email today?
Architecture and system-of-record
- For each of the six domains, who or what is the source of truth once AVIANIS is partially or fully out?
- Passenger records: FlightIQ, AVIANIS, or somewhere else?
- Service requests: same question, and more urgently, because this is the foundation of the Trip Support module decision.
- Itinerary data: where does this live once a trip is in motion?
Downstream consumers
- Finance and JD Edwards: what API calls, what data, on what cadence? An "unplug" without inventorying these is not actually an unplug.
- FlyExecaire: currently powered by AVIANIS data. What does an unplug actually look like for the crew-facing app?
- What other consuming systems exist that we haven't yet identified? Waqar's API matrix is the artifact that answers this.
Engagement and commercial
- Source code access for current systems: can we secure this upfront, before discovery starts?
- What is Mike's actual ROI bar? What number does Bill need to clear, even informally?
- What is the cadence for client review of discovery outputs: weekly working sessions, or milestone-based?
The boundaries we're working inside.
- 01AVIANIS costs about $200k per year. This is the ROI anchor. Every replacement conversation eventually returns to what the alternative saves against that number. Bill has been clear that he can't justify the financial weight of a replacement without that number in front of him.
- 02Execaire is locked into AVIANIS until October. Anything built before then is parallel infrastructure rather than a replacement, which both limits and helps us. It limits what "near-term" can mean in the proposal, and it gives us room to ship standalone pieces (NOTAMs being the obvious candidate) without colliding with the contract.
- 03A roughly 1.5-year phase-out timeline has been discussed. We should treat this as directional rather than committed. Anything we write about timing in the proposal needs to be framed as the client's working assumption, not as a plan we've already quoted.
- 04Finance and JD Edwards consume AVIANIS data downstream. An unplug without an inventory of these consumers is not actually an unplug, and Patrick has acknowledged this contradiction himself in conversation. It's the practical constraint on what replacement can mean.
- 05Passport data was previously stolen in a hack at Execaire. This is the underlying reason for the decision not to store passport data in FlightIQ. It raises the stakes on the passport portal design, since security review will be live engineering rather than a checkbox.
Two corrections to feed back internally.
Arthur's preliminary scope analysis was solid at the time, but the conversation has moved since then, and two specific points in his matrix are now out of date. Both should go back to him so his next pass is built on current ground.
Now: The newer call notes show that the McD's board has grown into a configurable, Salesforce-style service-request engine plus a separate tasking and dashboard layer. That "service is the record, task is the status" distinction is a real architectural split, not a board.
The broader Trip Support module is therefore no longer low complexity. It's Very High. Even the narrow McD's board piece, taken on its own, is High once you account for the service-request engine sitting underneath it.
Now: Answered. The decision from the earlier passport discussion is that FlightIQ will not store passport data.
The important context for the matrix is that this is settled, not provisional, because Execaire previously had passport data stolen in a hack. Any passport portal design has to treat security as real engineering, not a compliance step.
What is not in this engagement.
Two things should be visibly out of scope, regardless of what comes up in upcoming calls. The discipline here is contractual rather than technical. Both should be named in plain language in the eventual proposal's "out of scope" section, so that neither shows up later as an assumed inclusion.
Crew scheduling
Added in the most recent call as "the last component missing." It goes onto the roadmap as part of the AVIANIS inventory and the consuming-systems map, but we are not building it as part of this engagement. It's almost certainly a separate product if it goes ahead at all, because it has a different problem space, different stakeholders, and a different timeline.
Charter sales
Same treatment. The charter sales workflow has its own audience (sales and quoting rather than flight ops), its own data shape, and its own development effort. It's scoped on the roadmap but not built in this engagement.
Rates, scoping work, and build estimates.
Everything below saves locally as you type. Hours can be fractional, use 0.5 for half hours. Rates are in dollars per hour. The summary at the bottom rolls up across people and across sections. The pricing data is included when you export, so backups capture everything.
Team and rates
Add or remove people and set their hourly rates. The hours and cost columns roll up everything they're assigned across the scoping engagement and the build estimates.
| Person | Rate ($/hr) | Hours | Cost | |
|---|---|---|---|---|
| Team total | 0h | $0 |
Scoping engagement workstreams
The discovery and roadmap work itself, broken into the pieces that would go into the quote for Bill. The starting numbers are conservative first cuts that should be adjusted based on what the team actually thinks is realistic. Edit names, descriptions, and per-person hours. Add or remove workstreams as needed.
Build estimates (placeholder)
These get sized properly once the discovery work produces real numbers. Leave them at zero, or use them as a working scratchpad for first-cut ballparks. The whole point of the scoping engagement is to fill these in honestly, so the proposal for the actual builds is grounded rather than guessed.
Summary
By person
By section
| Scoping engagement | 0h | $0 |
| Build estimates | 0h | $0 |
| Grand total | 0h | $0 |
Every bullet in the picture, decomposed.
Organized into the five ecosystem areas from Patrick's diagram. Each area opens with the diagram's stated inputs, outputs, and AI opportunities verbatim, then one card per bullet within. Each card includes assumptions to validate, the specific data sources it touches, where the data lives and what we'd need to validate about that, an effort estimate per person (hooked into your Pricing tab so renames and rate changes propagate here), an Ours / Theirs / Mixed resource toggle, and interdependencies in both directions.
Ours shows our team and their hours. Theirs hides our names and gives you an editable list of resources we'd need from Execaire (pre-populated from the functional roles on the card; add or remove as needed). Mixed shows both stacked, with combined hour math and our cost.
Dispatch
- FlightAware API (actual aircraft movement times)
- ARINCDirect (flight plan details)
- Contract fuel prices
- Feasibility status from Flight Concierge
- Aircraft actual departure and ETA to FlyExecaire
- Movement data to external stakeholders via email
- Leg details to ARINCDirect for flight plan generation and changes
- Monitor weather and NOTAMs at destination and alternate airports automatically
- Generate movement email and send to logistics stakeholders
- Automatically generate flight plans
- Build and adjust flight plan via LLM review of pilot requests
Update Logistics if Flight is Delayed, Cancelled, or Early
A system that detects schedule changes from movement data and propagates the change everywhere downstream. Trip Support gets updated due dates and statuses for service requests, Flight Concierge gets the updated arrival time, external stakeholders get notified, ground handlers are alerted. The propagation logic is the work, the detection is easy.
- FlightAware API provides movement data with low-enough lag (under 5 minutes) for delay detection to be useful
- Delayed, cancelled, and early each map to different cascading actions; that rule set exists or needs to be built with Execaire ops
- External stakeholder distribution lists for movement emails are documented (recipient list, format, content)
- Notification routing rules (who gets notified for which kind of change) need to be defined with operations
- FlightAware API actual movement times (the trigger)
- Active trip and leg data from FlightIQ
- Active service requests downstream that depend on the leg timing
- Updated movement data to FlyExecaire
- Updated ETAs pushed to Trip Support for cascading status updates
- Movement emails to external stakeholders
- Retention policy for movement events (operational vs compliance need)
- Whether outbound email content is logged or just metadata (recipient, timestamp)
- Whether trip_changelog feeds into safety/regulatory reporting
Ensure Aircraft Lands at Destination
A monitoring service that verifies each leg arrives at its filed destination. If an aircraft diverts, the system needs to know, log it, and trigger downstream updates including any logistic recovery (handler at the diversion airport, accommodations if overnight). Detection comes from comparing FlightAware tracking against the filed destination.
- FlightAware tracking is reliable enough to confirm diversions with low false-positive rate
- Diversion playbooks exist or need to be created with Execaire
- Handler relationships at non-home airports can be looked up programmatically
- FlightAware API (actual landing location)
- Filed flight plan destination from ARINCDirect
- Active leg data
- Diversion flagged in trip records
- Updated leg destination
- Movement data updated with actual landing location
- Trip Support notified for downstream logistic adjustments
- Whether diversion log is fed to compliance and safety reporting (likely yes)
- Retention requirements for diversion records
Trigger ERP if Aircraft Overdue
Emergency Response Plan trigger. If an aircraft is past its expected arrival time by a set threshold without movement data, the system needs to initiate ERP procedures including alerting on-call staff and escalating per the company's emergency playbook. This is safety-critical, so reliability and audibility matter more than features.
- Execaire has a documented ERP playbook we can reference and encode
- On-call rotation is tracked somewhere accessible (likely an Execaire-side system)
- Overdue threshold rules are defined (typical default is 30 minutes past ETA without movement, but needs confirmation)
- Audit log meets Transport Canada and safety regulator standards
- FlightAware API tracking
- Filed ETA from ARINCDirect
- Active leg data
- On-call roster
- ERP escalation rules (Execaire-specific)
- ERP triggered (PagerDuty-style escalation likely)
- On-call staff alerted with situation summary
- Immutable audit log entry
- Hand-off to ERP coordinator
- Retention requirements (Transport Canada likely requires 7+ years for safety incidents)
- Audit log access controls and tamper-evidence
- Whether incident records are surfaced to other regulatory reporting
Safety-critical. Build with that posture.
Monitor Weather and NOTAMs at Destination
A monitoring service that watches weather and NOTAMs for every active trip's destination and alternates, and alerts flight followers when conditions cross thresholds relevant to that aircraft and route. Output sits as a dashboard or feed with a notification panel for unread items. This is the cleanest standalone build in the whole picture because it doesn't depend on AVIANIS at all.
- Free NOTAM feeds (FAA, Transport Canada) are sufficient for coverage, or we need to buy a commercial feed
- Operationally significant thresholds can be defined with dispatchers (and will vary by aircraft type)
- Alert routing preferences are known (in-app, email, SMS, or all of the above per severity)
- Weather feed (NOAA, Environment Canada, or paid like ForeFlight)
- NOTAM feed (FAA, Transport Canada, ICAO, EUROCONTROL depending on operating areas)
- Active trip data from FlightIQ
- Aircraft type and operational profile for relevance filtering
- Each feed is its own integration with its own auth, rate limits, and format issues
- Dashboard with active trips and weather/NOTAM status per leg
- Detail view per trip with NOTAMs rendered in human-readable form
- Alert states with thresholds (rules validated with Execaire dispatchers)
- Notification panel for unread items
- How long the NOTAM cache persists (hours? days?)
- Whether LLM summaries are stored or regenerated each time
- Whether alert acknowledgements need to be retained
Disseminate ATC Delays to Flight Crew
When ATC issues a delay (ground stop, EDCT, slot constraint, FCM), the dispatcher needs to push that to the flight crew in real time. The system has to subscribe to the right ATC feeds (different by region) and route messages to the right cockpit using whatever connectivity the aircraft has (ACARS, EFB, SATCOM).
- FAA SCS or equivalent regional ATC feeds are accessible (some require credentials or agreements)
- Aircraft connectivity profile is known per tail and stored in FlightIQ
- Crew acknowledgement mechanism is determined (ACARS uplink, EFB push, or SMS fallback)
- FAA SCS or equivalent regional ATC feeds
- Trip and leg data from FlightIQ
- Aircraft connectivity profile (ACARS, EFB, SATCOM availability)
- Message to flight crew via the appropriate channel
- Acknowledgement back to dispatch
- Updated ETD/ETA
- Movement data updated downstream
- Whether crew acknowledgement records are regulatorily required (likely some are)
- Retention for ATC message log
Flight Plan Action Trigger - Time-Based Workflow (60h, 12h, 6h)
A scheduling engine that triggers different actions at different points before ETD: build flight plan at 60 hours pre-ETD, complete fuel at 12 hours, file at 12 hours, refresh weather and NOTAMs at 6 hours. Each step has its own integrations and its own validation, so this is really a small workflow orchestration system, not a cron job.
- The 60h/12h/12h/6h cadence is exactly Execaire's process and won't fragment into per-operator variants
- ARINCDirect API supports the actions we need (build, file, modify, retrieve plans)
- Fuel marketplace integration sits where the diagram puts it in the workflow (rather than earlier or later)
- Active trip and leg ETDs from FlightIQ
- ARINCDirect for flight plan operations
- Fuel marketplace data for fuel decisions
- Weather and NOTAM feeds for the 6h check
- Generated flight plan in ARINCDirect
- Filed flight plan
- Fuel selections recorded
- Weather and NOTAM check log per leg
- Whether weather and NOTAM snapshots at filing time need to be retained for post-flight safety analysis
- Whether ARINCDirect data is mirrored locally or only referenced
Setup Fuel Based on Fuel Marketplace Data
An integration with the fuel marketplace that pulls current contract pricing and helps the dispatcher choose where to fuel and how much (tankering decisions). The output is a fuel plan attached to the leg.
- Fuel marketplace API is documented and stable
- Tankering rules are well-defined for Execaire's fleet and not aircraft-by-aircraft tribal knowledge
- Cost data flows back to Charter Sales pricing engine when applicable
- Contract fuel prices (per the diagram)
- Trip route and stops
- Aircraft fuel capacity
- Tankering rules
- Fuel plan attached to the leg
- Fuel selection recorded
- Cost data passed to Charter Sales for accurate pricing when applicable
- Retention for cost-analysis and post-flight review
- Whether marketplace prices at planning time are stored (or only the chosen price)
Flight Concierge
- Government systems (EU-LISA, US eAPIS) for travel documents and immigration requirements
- Travel documents from secure submission system
- Internal Execaire aviation systems
- FlyExecaire change requests
- Azure user data (flight concierge info)
- FlightAware data (arrival trip log, OOOI times)
- Submission of passenger data to government systems
- Generated general declaration PDF
- Submitted requests for travel documents
- Leg details and service request details to Dispatch and Trip Support
- Passenger creation, editing, and assignment via LLM prompt
- Suggest passengers from historical data
- Identify duplicate passenger records
- Validate immigration status (feasibility)
- Review travel documents for errors
- Read passport data
- Itinerary creation and editing via LLM prompt
- Suggest trips based on historical data
- Service request creation and editing via LLM prompt
Add or Remove Passengers from Legs
A UI for associating passengers with specific legs (or removing them). Sounds simple but has to handle the case where a passenger is added late and immigration data hasn't been collected, or removed last-minute and downstream notifications have to fire (catering counts change, transport vehicles change).
- Cascading impact rules (catering count changes, transport vehicle changes, etc.) are well-defined or definable
- Government re-submission rules when manifest changes after filing are clear per country
- Last-minute manifest changes are a real use case (not edge case)
- Passenger records
- Trip and leg structure
- Immigration requirements per route
- Existing service requests that depend on passenger counts
- Updated leg passenger manifest
- Downstream notifications to Trip Support (catering, transport counts)
- Updates to government submissions if already filed
- Whether removal events are preserved (regulatory ask in some jurisdictions)
- Retention for legacy passenger associations on inactivated legs
Create Passenger (Name, DOB, Email, Phone, Residency, Gender, Linked Account, Family Tree)
A passenger record CRUD with full fields per the diagram. The "Family Tree" piece suggests relationships matter (a passenger is the dependent of an owner, etc.), which has implications for permissions and notifications.
- Family Tree relationships are operationally important (worth modeling) rather than nice-to-have
- Owner-passenger linkage rules (who can manage whose record) are clear and can be encoded
- PII storage rules differ from document storage rules and that distinction is acceptable to compliance
- Internal Execaire systems (existing customer data)
- FlyExecaire (if owners create passengers from their app)
- Azure user data
- Passenger record available for legs and trips
- Family relationships visible for downstream rules
- PII encryption at rest (row-level vs field-level encryption)
- Canada-specific data residency requirements
- Whether DOB and gender need elevated access controls
Edit / Inactivate Passenger
Standard edit and soft-delete behavior on passenger records. The non-trivial part is what happens to historical trip data when a passenger is inactivated. We don't want past records to disappear, just remove the passenger from new trip flows.
- Soft-delete is the right model (inactivated records still queryable) rather than hard-delete with archive
- Active trips with inactivated passengers should block inactivation (or only warn, depending on operator preference)
- Passenger records
- Trip history (to confirm safe to inactivate)
- Updated or inactivated passenger record
- Historical records preserved
- No new trips can use inactivated passenger
- How long inactivated records remain queryable
- Right-to-be-forgotten obligations under applicable privacy law
Store Preferences
Passenger preferences (food, drinks, music, seating, anything operationally relevant) attached to the passenger record. Used to pre-populate service requests automatically when the passenger is on a trip.
- Preference categories are bounded and definable (food, drinks, music, seat) rather than open freeform fields
- Auto-population of service requests from preferences is desired by Flight Concierge (rather than explicit confirmation every time)
- Manual entry from Flight Concierge
- Historical service requests (to learn implicit preferences)
- Owner instructions where applicable
- Preferences attached to passenger record
- Used downstream to pre-fill catering and transport requests
- Whether AI-inferred preferences are stored alongside explicit ones (and tagged as such)
- Whether passengers should be able to see and edit their own stored preferences
Store Passport, Visa, Residency
Where travel documents get associated with passengers. Per the no-storage rule for passport data in FlightIQ, this isn't actual document storage. It's metadata (document type, document number, issuing country, expiry) plus a secure pointer to the document held elsewhere. The diagram says "Store" which is incompatible with the policy, so this needs a product decision.
- Metadata-only storage in FlightIQ is acceptable to Flight Concierge for their operational use
- Document validity checks (expiry, route match) happen at submission time and live with the secure capture pipeline rather than in FlightIQ
- A secure document store outside FlightIQ exists or needs to be selected (vendor decision needed)
- Travel document metadata from the secure submission system
- Government systems for validation
- Document metadata attached to passenger record
- Document available for routing to government systems on demand
- That metadata-only is operationally sufficient for Flight Concierge workflows
- Vendor selection for the external secure document store
- Encryption at rest and access logging for the metadata table itself
Needs a product decision because the diagram says "store" but Execaire policy is don't store passport data in FlightIQ.
Securely Acquire Travel Documents
A portal where passengers submit travel documents (passports, visas, residency) directly. Data flows through to required systems without being persisted in FlightIQ. Important context: Execaire previously had passport data stolen in a hack, so this is real engineering and not a compliance checkbox. The no-storage requirement shapes the entire architecture.
- Mobile-first capture is acceptable to passengers (vs email-with-PDF for older or less tech-comfortable passengers)
- Document routing rules per destination country can be encoded as config rather than per-route custom logic
- No-storage architecture is buildable with the AI agents we want to use (working memory holds no PII at rest)
- Security review happens before deployment, not after, and the reviewer has authority to block release
- Passenger contact info from FlightIQ
- Trip route (to determine which documents are required: US eAPIS for US arrivals, EU-LISA for EU, country-specific visa requirements)
- Document capture from mobile and desktop
- Secure handoff channels to government systems
- Each government system is its own integration with its own format and auth
- Submitted documents passed through to relevant government systems
- Audit trail (who submitted what when, without storing the doc itself)
- Status visible to internal Flight Concierge view
- Security review must explicitly sign off on the no-storage architecture
- That ephemeral really means ephemeral (no Redis persistence, no temp files, no AI agent state holding PII)
- Audit trail without the documents themselves still meets regulatory and operational needs
Create Trip (Status, Type, Contacts, Regulatory Standard, ICAOs, ETD/ETA, Flight Time, Handling Agents)
A trip CRUD with the full set of fields per the diagram: trip status, trip type, primary contact, flight concierge responsible, sales manager responsible, attending maintenance engineer, regulatory standard (CAR 604 etc.), departure ICAO, arrival ICAO, ETD, ETA, flight time, leg status, departure and arrival handling agents. Large object, many fields, central to the whole picture.
- All trip fields per the diagram are required for v1, rather than some being optional
- Regulatory Standard maps to a predefined set of options (CAR 604, EU-OPS 1, FAA Part 91, etc.) rather than freeform text
- Linkage to aircraft and crew availability happens at trip create time (not just at feasibility)
- Aircraft availability
- Crew availability from Crew Management
- Charter quote (if a sale)
- Internal Execaire systems
- Trip record available to all downstream consumers
- Visible to Dispatch, Trip Support, Crew, Sales, Finance
- This replaces AVIANIS as source of truth for trip data; migration plan for historical AVIANIS trips
- Reconciliation strategy during the transition window when trips may exist in both systems
- Whether downstream consumers (FlyExecaire, finance, JD Edwards) read from FlightIQ or from a sync mirror
Inactivate / Edit Trip
Edit trip details or inactivate a trip. Like passenger inactivation, the hard part is what happens to all the downstream things attached to the trip (service requests, crew assignments, government submissions, financial records).
- Trip-level changes (e.g., regulatory standard) and leg-level changes have different cascading rules
- Cancellation triggers different downstream behavior than edit, and the rules differ per downstream consumer
- Trip record
- All downstream attachments (service requests, assignments, filings)
- Updated trip record
- Cascading updates or cancellations across Trip Support, Crew, Dispatch
- Retention for cancellation history (operational and possibly billing relevance)
- Whether changelog feeds into reporting
Add / Remove Legs
Legs are the operational unit. Adding or removing a leg has to ripple through feasibility, charter pricing if applicable, flight planning, fuel, service requests, and crew duty calculations.
- Adding a leg automatically triggers feasibility re-check (rather than manual recheck)
- Last-minute leg additions are operationally common enough to optimize for
- Existing trip structure
- Feasibility inputs (aircraft range, crew duty limits)
- Updated trip with new or removed legs
- Triggered re-feasibility
- Possible re-quote in Charter Sales
- Possible re-planning in Dispatch
- Whether full structural history is needed or just current state
- Compliance implications of changing flight legs after filing
Move Legs Between Trips
Sometimes legs need to move between trips (the owner combines two trips, or a leg is reassigned to a different tail). Operationally complex because both source and destination trips need consistent updates.
- Operationally rare enough to not be a primary use case (vs core flow)
- Transactional consistency (both trips updated atomically) is required and tooling supports it
- Source trip
- Destination trip
- Both trips' downstream attachments
- Updated trip structures
- Cascading updates on both sides
- Reconciliation reports if move events affect billing or accounting
- Whether move events are visible in both source and target trip histories
Conduct Feasibility
For each leg, check whether the trip is feasible: aircraft range, crew duty limits, regulatory compliance, immigration requirements, airport restrictions. Outputs a feasibility status that gates whether the trip can proceed.
- Aircraft specs database (range, MTOW, certified airports) is maintained and complete
- Regulatory rules database can be sourced commercially or needs to be built
- Airport restrictions data (slot constraints, curfews, runway lengths) can be sourced (e.g., airnav, ForeFlight)
- Trip and leg details
- Aircraft specs and capabilities
- Crew duty data
- Airport restrictions and slots
- Regulatory rules database (CAR 604, EU-OPS, etc.)
- Feasibility status per leg and per trip
- Reasons for any infeasibility
- Suggested mitigations (tech stop, crew change, etc.)
- Whether feasibility decisions need to be auditable for regulatory reasons
- Snapshot retention (do we keep the inputs forever?)
Build Service Requests (Catering, Chauffeured Transport, Rental Car)
The Concierge side of service requests. Build catering, ground transport, rental car requests with type-specific fields. These then hand off to Trip Support for execution. The split between "request creation here" and "execution there" is part of the architecture decision.
- Three types (catering, transport, rental) cover the large majority of Concierge SRs
- The Concierge / Trip Support split (request creation vs execution) is the right architectural model
- Pre-fill from passenger preferences is desired by default (vs explicit confirmation per request)
- Trip and leg context
- Passenger preferences
- Existing service request patterns for similar trips
- Service request records with type-specific fields
- Handed off to Trip Support side for execution
- Whether SRs are FlightIQ-native or proxies of records elsewhere (especially during AVIANIS transition)
- Polymorphic schema vs separate tables per SR type
Set Completion Due Date
Each service request has a due date for completion (catering confirmed by N hours before ETD, etc.). This drives the time-based workflows on the Trip Support side.
- Each SR type has a known typical lead time (catering 4h before ETD, transport 1h, etc.) that can be encoded as defaults
- Due dates drive time-based workflows on the Trip Support side rather than being purely informational
- Service request
- Trip ETD
- Operational rules for each request type
- Due date set on each service request
- Drives downstream time-based monitoring on the Trip Support side
- Time-zone handling (each leg local time vs UTC) and how it surfaces to users
Cancel / Edit Service Request
Standard cancel/edit on a service request. The interesting part is what happens to in-flight executions on the Trip Support side (vendor already contacted, deposit paid, etc.).
- Cancellation rules depend on execution state on Trip Support side (vendor contacted, deposit paid, etc.)
- Vendor notification on cancel is required and the notification mechanism is per-vendor
- Service request
- Current execution state from Trip Support
- Updated or cancelled request
- Cascading actions to Trip Support if execution is already in progress
- Vendor-acknowledgement records if vendors were notified of cancellation
- Whether cancelled SRs are queryable or just soft-deleted
Trip Support
- Leg details (from Flight Concierge)
- Service requests (created by Flight Concierge)
- Passenger details
- Due date of each service request
- Leg changes (delays, cancellations, route changes)
- Service request status (back to Flight Concierge)
- Issues with service acquisition (customs not available, parking not available)
- Draft and send permits automatically
- Receive and interpret permit approval using LLM
Automatically Create Service Requests Based on Trip and Leg Details
A rule engine that infers required service requests from trip details. Landing in Cuba creates a landing permit request. Arriving in the USA creates a CBP request. Landing at airport X requires special handler X. This is the bit that turns trip data into operational checklists.
- Country-specific service-request rules can be sourced or built (significant data engineering effort either way)
- Airport-specific rules can be sourced (commercial database) or maintained internally
- Trip Support operations team will validate the rule set before it is trusted to auto-create requests
- Trip and leg details from Flight Concierge
- Country-specific rules database
- Airport-specific rules
- Auto-created service requests with sensible defaults
- Visible to Trip Support team for execution
- Source of country and airport rules data (manual, scraped, commercial vendor)
- How rules are versioned and how rule changes affect existing in-flight SRs
Create / Edit Service Requests (Catering, Landing Permit, Overflight Permit, etc.)
Manual creation and editing of service requests on the Trip Support side. Different from the Concierge side because these are typically permits, handling, customs, and operational requests rather than passenger-facing services.
- Operational SR types (permits, customs, handling) are a bounded set that can be enumerated
- Templates exist for common requests or can be created with operational input
- Trip context
- Existing service request templates
- Country-specific permit forms
- Service request record
- Ready for submission to authorities
- Whether Concierge SRs and Trip Support SRs share the same schema or need a split
- Whether status workflows are unified across SR types
Generate Permit Request Forms
A system that takes trip details and generates the right permit forms for the relevant authorities. Forms are pre-filled where possible. The system also handles the back-and-forth with authorities, which is where the bulk of trip-support time actually goes today. This isn't just a form generator. The async conversation with each authority is the harder half.
- Form templates can be acquired or built per authority (some authorities provide downloadable forms, some require manual recreation)
- Pre-fill mapping rules from FlightIQ data to form fields are definable per form
- LLM judgment on edge cases is reliable enough for operational use (with human review pre-submission)
- Trip and leg details from FlightIQ
- Aircraft registration, owner info, insurance data
- Country-specific permit requirements (fragmented and inconsistent across authorities)
- Existing approved permits on file
- Form generation view showing which permits are needed and the status of each
- Generated form preview before submission
- Status tracking (filed, pending, approved, denied, RFI)
- Retention policy for generated forms (some are legally binding submissions)
- Whether forms containing passport numbers need elevated handling
- Backup and recovery for the object storage tier
Send / Receive Permit Request Forms
The transmission half of the permit workflow. Different authorities accept different formats (web portal, email with PDF, fax in some cases). The receive half is monitoring inbound channels for responses (approvals, denials, RFIs) and matching them to outstanding requests.
- Email and fax are the dominant submission channels (vs web portals which exist but are less common)
- Inbound email parsing can be reliable enough to match responses back to outstanding requests
- Some authorities have unique submission requirements (named contact, specific subject format) that need per-authority configuration
- Generated permit forms
- Authority submission channels (email, portal credentials, fax numbers)
- Inbound email and fax monitoring
- Submitted forms to authorities
- Received responses matched to original requests
- Status updates on each request
- Email retention requirements (compliance and operational)
- PII handling for archived emails (passenger info may appear in subject lines)
- Whether AI classification confidence is persisted for audit when status is contested
Monitor Trip Changes and Execute Logistic Updates
When a trip changes (delay, cancellation, route change), Trip Support has to update everything downstream that depends on it. Catering for new times. Ground transport for new arrival. Permits possibly invalid. The system has to detect changes and execute the right cascading updates.
- A change-event system or change-detection mechanism exists or can be built on the trip side
- Cascading rules (what each kind of change implies for each kind of SR) are definable
- Vendor notification protocols are defined per vendor (email format, who to contact)
- Trip change events from Flight Concierge and Dispatch
- All currently active service requests for affected trips
- Updated service requests
- Notifications to vendors and authorities about the changes
- Status updates back to Flight Concierge
- Event sourcing approach versus snapshot-only
- Retention for change events
- Whether change events need to be replayable for debugging
Monitor Service Request Status Holistically (Time-Based Workflows)
The dashboard view: see the status of every service request across all active trips, with time-based alerting when something is approaching its due date or hasn't been progressed in N hours. This is what Patrick calls the "McD's board."
- At-risk thresholds per SR type can be defined (typically historical response time plus buffer)
- Dashboard is the right primary UI (rather than kanban, list, or notification-only)
- Time-based workflows are the primary alerting mechanism (vs human polling)
- All active service requests
- Due dates
- Status
- Trip ETDs
- Dashboard view sorted by urgency
- Alerts when items are at risk
- Whether the dashboard reads live SR state or operates on snapshots
- Alert acknowledgement state retention for compliance
- Cache invalidation rules if dashboard is precomputed
Related to Domain 2 (McD's board) and Domain 3 (Trip Support module). This card describes the dashboard, but the service-request engine work underneath is what makes it possible.
Crew Management
- Vacation and days-off requests from FlyExecaire
- Training schedule from third party (CAE)
- Training status from LMS / QMS
- Crew assignment from elsewhere in the system
- Crew availability
- Crew statistics (flight time, time away from base)
- Crew regulatory compliance status
- Build crew schedules automatically based on tail-specific crewing model (days off, workload balancing)
- Assign crew automatically based on schedules and trips
Build / Edit Crew Schedules
The core scheduling tool. Build crew rosters by tail considering days-off requests, training schedules, duty time limits, qualification requirements per aircraft. Editor for swaps and overrides.
- Tail-specific crewing model can be encoded as constraints (qualifications, currency, fatigue rules)
- Auto-build output is reviewable by humans before deployment to crew
- Manual overrides are common and required as a first-class feature
- Vacation and days-off requests (from FlyExecaire)
- Training schedule (from CAE)
- Crew qualifications
- Aircraft-to-crew assignments (tail-specific)
- Crew schedule per tail
- Crew availability for upcoming periods
- Schedule history retention requirements
- Versioning approach (full snapshots vs deltas)
- How schedule changes are surfaced to crew (FlyExecaire integration)
Days Off and Vacation Approval Workflow
Crew submit requests for days off and vacation. Workflow routes to scheduler for approval based on coverage. Tracks bank of days available per crew member.
- FlyExecaire is the request channel; system polls or receives push
- Approval rules (coverage check) can be automated to a high enough degree to be useful
- Crew member requests (from FlyExecaire)
- Crew schedule (to check coverage)
- Vacation banks per crew member
- Approval or denial
- Updated schedule and availability
- HR system integration (their HR is source for vacation entitlements)
- Legal record retention requirements for time-off decisions
Enter Training Events by Type
Training events (recurrent simulator, line checks, ground school) entered into the system, tracked per crew member, affects availability and qualifications.
- CAE provides a schedule API or feed (vs needing to scrape PDFs)
- LMS/QMS integration is feasible (vs needing to build a custom uploader)
- Training schedule from CAE and other providers
- Training records from LMS / QMS
- Training events in crew calendars
- Updated qualifications and availability
- Whether LMS or FlightIQ is source of truth
- Retention requirements for training currency records (regulatory)
Crew Statistics Dashboard
Per-crew stats: flight time, duty time, time away from base, days off used, training completions. Used by scheduling and HR.
- Actual flight time data comes from FlightAware or aircraft logs (not self-reported by crew)
- Time-away-from-base calculation rules are defined operationally
- All scheduled and actual flight legs
- Duty time tracking
- Time-away-from-base calculations
- Dashboard view per crew member and aggregate
- Statistics surfaced to compliance and HR
- Cache invalidation rules
- Reporting consistency when underlying data changes
Monitor Canadian Duty Time Regulations
Compliance monitoring against CARs (Canadian Aviation Regulations) for flight and duty time limits. Hard limits from regulation and corporate policies layered on top.
- CARs (Canadian Aviation Regulations) rules are encodable as structured constraints
- Real-time calculation cadence is required (vs end-of-day batch)
- Scheduled and actual duty times
- Regulatory rules database (CARs)
- Corporate policy rules
- Compliance status per crew member
- Alerts when at risk of breaching a limit
- CARs require records for a defined retention period (need to confirm exact requirement)
- Audit trail for violation decisions and any overrides
Safety-critical. Build with that posture.
Monitor / Report on Flight Crew Overtime
Track crew overtime against corporate policy and regulatory limits. Reporting for HR, finance, operations.
- Overtime policy is encoded in HR/payroll system (vs prose-only in a handbook)
- Reporting cadence to HR is monthly (or some other defined schedule)
- Scheduled vs actual duty hours
- Overtime policy rules
- Pay and cost data
- Overtime reports
- Alerts when crew are approaching overtime thresholds
- Payroll system integration (Execaire-side)
- Whether overtime decisions need to be auditable
Assign / Remove Crew from Flights
The actual assignment of crew to specific flights, checking availability and compliance constraints. Removal handles swaps and reassignments.
- Auto-assignment output is reviewable by humans before locked
- Qualifications database is current and comprehensive enough to drive assignment logic
- Crew schedule
- Aircraft assignment
- Flight legs
- Compliance constraints (duty time, qualifications)
- Assigned crew per flight
- Updated crew availability
- Assignment history retention for compliance and operational review
- Whether assignment changes after filing are tracked separately
Charter Sales
- Airport and navigation cost data
- Feasibility status
- Flight time calculation
- Trip details
- Sales data
- Countries overflown (triggers service requests)
- Trip changes result in re-quote
- Trip details for downstream processes
- Automatic quote generation and distribution
- Build quote based on AI interpretation of aircraft owner's rules of engagement (charge additional fee if leg less than one hour, etc.)
Generate Sales Quotes (Account, Contact, ICAOs, ETD/ETA, Flight Time)
Quote builder with the fields from the diagram: account, primary trip contact, departure ICAO, arrival ICAO, ETD, ETA, flight time. Outputs a structured quote.
- Customer inquiry comes through a defined channel (sales rep, email, web form)
- Quote format is standardized across Execaire (not per-aircraft variations)
- Customer account data
- Trip parameters
- Aircraft availability
- Quote draft
- Goes through pricing engine for cost and price calculation
- Quote retention for legal and audit purposes
- Whether expired or rejected quotes need different handling
Calculate Sale Price (Payback + Flight Costs + Margin)
Pricing engine that computes payback to aircraft owner + flight costs + margin = sale price. Costs include navigation, airport fees, fuel, handling, crew. Lots of cost data inputs.
- Cost data sources (navigation, airport, fuel, crew) are accessible programmatically
- Margin rules are defined and consistent (per aircraft, per route, or blanket policy)
- Airport and navigation cost data
- Fuel costs from Dispatch
- Crew costs
- Owner payback rates
- Margin rules
- Cost breakdown
- Final sale price
- Whether all cost components are preserved for audit (especially owner payback amounts)
- How cost data version changes propagate to existing quotes
Adjust Cost / Sales Price
Manual adjustment to costs or final price (honoring a customer commitment, applying a discount, accounting for an unusual cost). Audit trail matters here.
- Authorization rules (who can adjust by how much) are defined
- Audit trail is the primary control (vs hard limits)
- Initial calculated price
- Adjustment rules
- Authorization rules (who can adjust by how much)
- Adjusted price
- Audit log of who adjusted what when and why
- Authorization records retention for legal purposes
- Whether adjustments are visible on the customer-facing quote
Manage Aircraft-Specific Payback Rates
Each aircraft has owner-specific payback rates (the amount the owner gets when their aircraft is chartered). These vary by aircraft and need to be maintainable.
- Owner contracts are accessible (and ideally machine-readable for AI extraction)
- Rate changes happen infrequently enough that AI extraction is high-leverage rather than overengineering
- Aircraft data
- Owner contracts and agreements
- Payback rates per aircraft
- Used by the pricing engine
- Historical rates retained for audits
- Source-document references (which owner contract revision set each rate)
Standalone.
Set Charter Terms and Conditions per Tail
Tail-specific terms and conditions for charters. Some aircraft owners have specific requirements (no pets, specific crew requirements, minimum trip duration).
- Tail-specific rules can be encoded as structured data (rather than prose only)
- The diagram example (additional fee if leg less than 1 hour) is representative of the kinds of rules owners impose
- Aircraft owner contracts
- Tail-specific rules
- T&Cs attached to charters of each tail
- Surfaced during quoting
- Legal sign-off on encoded T&Cs (the structured version is operational; the contract is binding)
- How rule changes propagate to in-progress quotes
Standalone.
Generate / Send Sales Quotes for Electronic Signature
Generate final quote document and route to customer for e-signature. Integration with DocuSign or similar.
- DocuSign or equivalent is the standard at Execaire
- Signed contracts auto-trigger trip creation (or this remains a manual step)
- Finalized quote
- Customer contact details
- T&Cs attached to the quote
- Sent quote
- Tracking for signature
- Signed contract back in the system
- Legal retention requirements (years per applicable law)
- Whether the e-signature platform records or FlightIQ records are primary in case of dispute
Your notes, rolled up.
Everything you've added across the tabs, grouped by where it sits. Click any group title to jump to that section. Notes save to the workspace as you type them. Export the JSON if you want a local backup.
Activity across the workspace.
The full edit log, newest first. Each entry shows who made the change and what changed. Click any entry to jump to where the edit happened.