A leadership briefing platform for YVR: a daily, sourced executive digest for each member of the Executive Team, and a plain-language way to ask the airport a question — built on the systems Sea Island already runs.
For discussion with the Executive Team and Board of Directors · September 2026 · Draft v1
The report you were shown is produced every morning for another company's C-suite: one page per officer, live numbers, sources attached, no analyst in the loop. Below is what the same product looks like with YVR's portfolios and YVR's published figures in it.
Figures shown are from YVR's public 2025 Annual & Sustainability Report and Consolidated Financial Statements, used here for illustration only. In production every tile is pulled live from the system of record and links back to it.
The 2025–2027 Strategy commits YVR to "fully harnessing the power of digital transformation and data analytics", to growth and yield, and to reducing variability across the operation. A record year makes the case sharper, not softer.
Revenue over operating expenses was $43.8M on $717.7M — about 6%. A $73.3M asset write-down turned 2025 into a $50.4M deficiency. Yield decisions now need to be made weekly, on current numbers, not quarterly on assembled ones.
YVR beat targets on punctuality, security waits and baggage connections. Holding that at higher volume means leadership seeing the exception the morning it happens — winter ops, a transborder dip, a baggage subsystem trend — not in next month's pack.
The Strategy invests in a talent-first organization. The scarcest asset on Sea Island is the attention of the people who can see around corners. Today too much of it is spent finding, waiting for and re-explaining data that already exists.
YVR runs a strong, mature application landscape — the Digital Twin, the airport operational database, Maximo, Oracle financials, SuccessFactors, BI. Each has an owner. Almost every question a board member or executive actually asks spans two or three of them.
Which system holds the answer, whose team owns it, whether the figure is current, and who to ask when it isn't.
A question that takes four minutes to answer routinely takes four days, because it queues behind someone else's week — or the next committee cycle.
Board and committee material is assembled by hand from exports and screenshots. By the meeting, the numbers are three weeks old and nobody can drill into them.
This isn't a tooling gap. It's a time-of-flight problem — how long a question takes to become a decision. At an airport, that time is measured against a live operation.
The digest you saw is produced by a working agent at a ~600-person North American distributor. It started as an engineering tool in February 2026 and became a business platform within months. The pattern is portable; the systems are not, which is what the rest of this deck is about.
An airport authority is regulated, safety-critical and publicly accountable, so governance comes first, not last (slide 9). But YVR also starts further ahead: the Digital Twin has already done the hard work of integrating operational systems into a single source of truth. This proposal sits on top of that, it does not compete with it.
| Portfolio | What the morning brief shows | Likely sources (to confirm with the CIO) |
|---|---|---|
| President & CEO | Passengers and cargo vs. plan; the day's top three exceptions across the operation; items heading to the Board | Roll-up of every section below |
| Operations & COO | Departure punctuality, security wait times, baggage connections, taxi and turnaround times, winter/IRROPS status, airside incidents | AODB · Digital Twin · baggage SCADA platform · CATSA feed · NAV Canada data |
| Finance & CFO | Revenue by stream (AIF, terminal, landing, concessions, parking, rentals) vs. budget; opex run-rate; ERM watch-list; capital burn; legal & privacy matters | Oracle E-Business Suite · PROPworks · Chrome River · ERM register |
| Airport Development & Asset Optimization | Capital program milestones and variance; Maximo work-order backlog and asset health; utilization of gates, stands and belts | IBM Maximo · project controls · Digital Twin |
| Commercial Data Integration & Optimization | Concession sales per enplaned passenger, parking and ground-transport yield, dwell time, tenant performance | PROPworks · concession POS feeds · parking systems · BI |
| Innovation & CIO | System availability, service-desk load, cyber posture, Digital Twin adoption, pilot pipeline from the Innovation Hub | ITSM · monitoring · security tooling |
| People & Culture | Headcount and vacancies, overtime, safety incidents and near-misses, training completion | SAP SuccessFactors · Kronos · H&S system |
| Communications, Environment & Indigenous Relations · External Affairs | GHG trajectory vs. Net Zero 2030, noise complaints, media and community sentiment, Musqueam commitments, government files | Emissions model · noise management · media monitoring · CRM |
System names are drawn from public reporting about YVR's application landscape and are placeholders until validated. The design does not depend on any one of them — each connected system is built once and reused by every portfolio.
Assembled from AODB passenger counts, AIF revenue in Oracle, and stand allocation in the Digital Twin — with links to each. In ninety seconds, not the next committee cycle.
Maximo work orders joined to baggage-platform events and connecting-bag outcomes. The pattern was always there; nobody could see across three systems at once.
Taxi-time emissions from the Twin against the ESP glidepath, drafted as a paragraph with sources attached, ready for the Corporate Secretary to review.
The first two need no new AI capability at all — only reachable systems and a permission model. The third is a drafting task on top of the same data. All three are Phase 1 or 2.
AODB, Digital Twin, Maximo, Oracle, SuccessFactors, PROPworks, BI. Unchanged. Still the truth. Nothing migrates.
One standard, permissioned, read-only way for an agent to query each system. Built once per system, reused by every portfolio and every future agent.
What was never in a system: targets and thresholds, why a KPI is defined the way it is, who owns which decision, what the Board was last told.
A morning digest per portfolio, and Q&A in Microsoft Teams (or wherever leadership already works) — staff simply ask @otto. Same permissions as the person asking. Every read logged.
The Twin is YVR's real-time picture of the physical airport, and the best possible data source for this. The brief is the narrative layer above it: what changed, why it matters, what the Board needs to hear — across finance, people and commercial as well as operations.
It's deciding what the canonical source is for each number, who owns it, and who is allowed to see it. That is an executive decision, not an IT ticket — which is why this belongs in front of the Executive Team and the Board.
The agent sees exactly what the person asking is entitled to see. No shadow access. Compensation, legal matters, security-sensitive operational data and commercial terms stay scoped to their owners.
Phase 1 reads and reports. Nothing is written to any system of record. Any later capability — drafting a work order, updating a register — is added only with the data owner's sign-off and explicit human approval per action.
Every read, every query, every generated figure is auditable after the fact by whichever officer the Board designates. No unsourced assertions in a decision context — if it can't cite, it says so.
Executive KPIs are aggregates. The platform is deployed in a Canadian region under YVR's control, reviewed by the CIO's security team, and aligned to PIPEDA / BC PIPA and YVR's existing privacy program.
Staff will know the tool as @otto — a river otter, for the estuary around Sea Island and the Twin Otters landing at YVR South. Otto doesn't fly the plane. He surfaces what changed overnight; the crew still make the decisions. The tool's formal name, and any Indigenous identity, is chosen with Musqueam in Phase 2 — not by us.
Suggested oversight: Finance and Audit Committee for data integrity and controls; Governance Committee for the access and privacy policy. Deliberately left for this room: AI use policy, model vendor selection and residency, and which systems are out of scope entirely.
Each phase ends with a demonstration to the Executive Team and a go/no-go on the next, with measured results against the Phase 1 baselines.
The return is speed and capacity for the people already here. Sold internally as cost-cutting, the experts whose knowledge it needs will quietly decline to contribute.
Every system of record stays exactly where it is. This is connective tissue on top of the Twin, Maximo and Oracle — not a new platform to migrate to.
It assembles context and drafts. Deciding what YVR should do about the context remains the job of the Executive Team and the Board.
One integration standard, one permission model, one audit trail. Departments buying disconnected AI tools is the failure mode this prevents.
Decision requested: approve the pilot, name the sponsor and the three system owners. Everything after that comes back to you with measured results.
"Nobody at YVR waits a committee cycle for a number that lives in a system we already own."
"Every executive starts the day knowing what changed on Sea Island overnight, and why."
"Our Board pack was pulled from live data the morning of the meeting — and we could drill into any figure in the room."
"We did it under our own governance, in Canada, read-only, with every query on the record."
The pattern is proven. The systems are YVR's. The only open question is whether to run a 90-day pilot — and who owns it.