Nobody teaches you to write the board deck. You learn to write a paper, tune a model, size a cluster, and then one day you are standing in front of a room where a reservoir geologist, a CIO, and a CEO are all reading the same slide, and only one of them is nodding. The other two have quietly decided your programme is either trivial or unaccountable, and you will not get the budget conversation you came for. The failure is almost never the work. It is that the update was written for one reader and handed to three.
We hit this on a roughly twenty-month subsurface AI engagement with a major operator in Oman, and the fix that stuck was structural, not rhetorical. By the Phase-2 board meetings of 18 October and 10 December 2022, the deck had settled into a shape we kept for the rest of the programme: one status update, layered for three audiences in a single deck. Domain experts got metrics and figures. The CIO and CDO got architecture, latency, and cost. The CEO and board got business impact and risk. Same update, three payloads, and every reader could find the one layer written for them.
Why a single flattened slide fails three ways at once
The instinct under time pressure is to write one dense slide and let each reader take what they need. It does not work, because the three readers do not fail the same way. A reservoir geologist reading a slide with no depth-MAE number decides the model has not been evaluated. A CIO reading a slide full of F1 scores and no compute footprint decides nobody has thought about what this costs to run. A board member reading either of those decides the whole thing is a science project. One slide cannot be at once specific enough for the expert and abstracted enough for the board; try, and it lands too vague for the first reader and too noisy for the last.
Layering is the answer, and it has a precondition most decks skip: named ownership. In the Phase-2 appendix each technical track had a section owner, a pair of people accountable for the numbers on it. The unsupervised track and the supervised track each had their own two-person ownership, so when a domain expert pushed on a figure, there was a name attached to the answer rather than a committee. That is what lets a layer be specific without becoming a free-for-all: the expert layer can carry a real error band because a real person stands behind it.
The three layers, and the one payload that belongs to only one of them
Layer one is for the people who will argue with the numbers. It carries the metrics and figures: sinusoid-detection F1, depth mean absolute error, dip and azimuth error bands, the blind-well prediction plots. This is the layer that earns technical trust, and it is the one a non-specialist reader is supposed to skim past without feeling lost.
Layer two is for the CIO and CDO, and it answers a different question: what does this cost to build and run, and will it hold up. Its payload is the architecture, the serving latency, and the compute cost. The concrete artefact here is a three-tier compute story. The economy stack ran on 1080Ti machines at 8 GB per machine. The next rung was a DGX A100 build, four to eight A100 GPUs, 320 to 640 GB of GPU memory, and 2.5 to 5 PFLOPS of AI compute. The top rung was a SuperPod at 25 to 50 PFLOPS. That ladder is the layer-two payload, and it is the one thing the other two audiences never see. A domain expert does not need to know the GPU memory to trust an F1 score, and a board member reading "640 GB of GPU memory" learns nothing they can act on. The compute ladder is legible and load-bearing for exactly one reader, which is precisely why it has to be layered rather than shown to everyone. What it costs to hold that hardware is its own conversation, one we set out separately in our GPU-hour ledger for the three phases; the deck cites the number, it does not re-derive it.
Layer three is for the CEO and the board, and it is the shortest and the hardest to write. Its payload is business impact and risk. Impact meant the interpretation gains the operator would see, the Omanisation outcomes the programme was building toward as it trained young Omani engineers, and the well-to-well correlation value the models unlocked across the field. Risk meant a register, kept as a RAID log, risks, actions, issues, and decisions, with GDPR compliance carried as a standing line item because client data governance was a board-level concern from the first proposal. A board does not want the RAID log's contents recited. It wants to see that a RAID log exists and that someone owns it. The layer succeeds when a board member can read it in thirty seconds and come away knowing what the programme is worth and what could sink it.
The greyed-out slide as a deliberate move
There was one visual habit in those decks worth naming, because it is the layering discipline made literal. When the deck reached a layer a given reader did not need, that content was shown greyed out, present but visibly not for them. Infrastructure detail would sit on the board slide as a dimmed appendix pointer rather than as live content. The greying is not decoration. It signals, in the room, "this exists, it is owned, and it is not your layer right now," which keeps a board from either ignoring the infrastructure or drowning in it. It is the difference between hiding the compute story from the board and telling the board the compute story is handled and lives one layer down.
The instrument above is that structure drawn out. The teal node at the top is the single update; the three lanes below are the disjoint payloads. Select a lane and it lights while the other two grey out, the same beat the decks used, so each reader is handed exactly one layer while the whole update stays intact underneath. The orange rung is the compute ladder that belongs to the CIO and CDO alone.
What this is really a discipline about
The layering is not a presentation trick. It is an accountability structure that happens to render as slides. A programme with three layers and named owners on each is one where any reader in the management chain can pull the thread meant for them and find a person on the other end. That is what makes it fundable across a chain rather than legible to a single champion who then has to translate for everyone above and below. When the champion leaves, an unlayered programme goes dark; a layered one survives, because the CIO could always read the CIO layer without the champion in the room.
If there is one habit to take from those Phase-2 decks, it is this: before you write a single slide, decide which of the three readers each fact is for, and refuse to put a fact in front of a reader who cannot act on it. Write the F1 scores for the people who will argue with them. Write the compute ladder for the people who will pay for it. Write the impact and the RAID log for the people who will fund it or kill it. Same update, three payloads, one deck. That is the deck nobody teaches you to write, and it is the one that keeps the work alive up the whole chain.
Limitations
This is a communication pattern drawn from one engagement's board decks, not a controlled study of what makes programmes fundable. The three-layer split worked in a setting with a technical operator, an engaged CIO function, and a board already briefed on the data-governance stakes; a flatter organisation or a purely financial board may need a different cut. The compute-tier figures are the hardware envelope the programme planned and reported against, not a claim that every rung was provisioned at once. And the greyed-out convention reads clearly in a live room with a presenter walking the deck; a slide read cold, without narration, needs the layer boundaries stated more explicitly than a dimmed colour can carry.
References
[1] NVIDIA, DGX A100 system architecture and specifications (GPU memory, PFLOPS, NVSwitch topology). https://www.nvidia.com/en-us/data-center/dgx-a100/
[2] NVIDIA, DGX SuperPOD reference architecture. https://www.nvidia.com/en-us/data-center/dgx-superpod/
