Building in the Fog, Part 1: The Spreadsheet

Part 1 of "Building in the Fog" — a series about building Ridgeline, a provisioning decision engine for Outward Bound Hong Kong.

The cocktail party

Wilson takes me to the 55th anniversary event at the Hong Kong Club. I'm his plus-one — Ms. Augustin Chan, according to the invitation. We're there for the drinks and the food.

A tall white man approaches us. Wilson immediately pivots: let's get some food. I'm thinking — this guy was nice enough to walk over, we don't know anyone in the room, let's just talk to him.

He turns out to be Aaron Funnell, the executive director of Outward Bound Hong Kong.

I mention Digital Rain, my company. I mention AI Tinkerers HKGBA, the community I'm part of. I pitch what I actually came to pitch: workshops for youth, AI literacy, preparing the next generation. Aaron listens. He's polite. But OBHK is about the outdoors — kayaking, hiking, camping. Not hackathons.

Then he says something like: You know what we actually struggle with? Our food supply chain.

Two weeks later, Aaron emails his team. The gist: a pro-bono project to improve OBHK's field rations system — menus, ordering, packing, dietary needs, calorie tracking, food waste. He copies Rocky, their operations supervisor, and a few other staff. The email asks for a site visit — a walk-through of the rations system, how meals are packed, carried, and cooked. Lunch at the dining hall.

I have no idea what I'm walking into.

The site visit

A taxi takes me up an unmarked road that ends at a beautiful beach and a view I wasn't expecting. The OBHK facility sits right on the water.

There's a group meeting first — Aaron's team, introductions, the story of how I ended up here via the cocktail party. Then, just before lunch, Rocky pulls me aside.

Rocky is a long-time instructor who's relatively new to the operations supervisor role. He's been put in charge of modernizing how things run behind the scenes — the supply room, the ordering, the packing. There's a supply officer who handles the day-to-day, but Rocky is the one trying to bring structure to the process.

The spreadsheet is his — his attempt to systematize provisioning into something others can follow. It's an Excel file that calculates how much food to buy for 14 teenagers on a 5-day expedition. It covers 4 dinners, 3 lunches, 4 breakfasts, and a shared snack pack. Day 1 starts at dinner (participants arrive with lunch already eaten). Day 5 ends after breakfast. The basics — quantities and costs. No dietary handling yet.

He walks me through the supply room, the packing station, the supplier relationships. I set up my phone to record in a small office next to the supply room while he explains everything — the constraints, the seasonality, the shelf-life logic. Six recordings, in Cantonese and English. I transcribe them later with Whisper and process them into structured notes.¹

The meal design Rocky describes is clever. Early days get fresh ingredients and full cooking — spaghetti bolognese, curry udon. Later days shift to instant carbs and boiling water — instant rice, instant noodles. Lunches are cold assembly: bread and salad, tortilla wraps. There's an intelligence embedded in the sequence that I don't immediately appreciate.

It's shelf-life sequencing. No field refrigeration. Campsites have generators but they don't run 24 hours. So the menu degrades gracefully:

Day	Fresh Veg	Protein	Complexity
1	High (5 types)	Fresh (sausage, pork burger)	Full cook
2	Medium (leafy + hardy)	Mixed (ham, fish ball)	Medium
3	Low (hardy only)	Preserved (tuna, canned pork)	Low
4	Minimal (cabbage, onion)	Preserved (luncheon meat)	Boil water
5	None	Preserved (shredded pork)	Boil water

This is not arbitrary. This is years of field experience that Rocky is trying to capture in cells and formulas.

The problem that isn't a problem

Here's the thing. The spreadsheet works — for what it does. It handles the basics: quantities and costs for a standard group of 14. But it's Rocky's first pass at systematizing the process. It doesn't handle dietary restrictions. It doesn't adjust well for different group sizes. It doesn't capture why Day 3 uses canned protein instead of fresh, or which suppliers carry what.

This is requirements gathering that nobody warns you about: sometimes you can't get complete requirements because nobody has them. The knowledge is distributed — some in the spreadsheet, some in the supply officer's habits, some in Rocky's head from years as an instructor leading the journeys. Requirements gathering is painful for everyone involved, so you get just enough to make a reasonable design decision, and you move.

The spreadsheet says "Spaghetti: 1.5kg." It doesn't say whether that 1.5kg is for 14 people (and should scale linearly with group size) or for one pot (and stays fixed until you need a second pot). The intent behind each number isn't recorded — just the number. So we end up doing a lot of first-principles work: they're buying N packs of spaghetti for a group of 14, so we assume they must be splitting it evenly per person. That kind of reasoning, applied to every item on the menu.

After the site visit, I write back to the team. My first instinct: build a lightweight brainstorming and data collection tool — something Rocky and others can use to find patterns and recommendations immediately. Not prescriptive. There are too many unknowns, too many constraints around how food has to be packaged and designed for the field.

I name the project Ridgeline. A ridgeline is the line you walk along the top of a mountain range — the path of highest exposure, where every decision matters because you're committed. You can't carry too much (weight kills pace), you can't carry too little (running out is dangerous).

It fits the Outward Bound context. It also fits how I feel about the project — exposed, committed, uncertain about what's ahead.

What the tool needs to understand

After processing my recordings from the site visit, the assessment document, and the spreadsheet, I write a shaping doc. The core requirements:

R0: Support exploratory thinking about provisioning — not prescriptive optimization.

R1: Useful from day one with zero field data.

R2: Grows more useful as real data — waste, consumption, feedback — accumulates.

R3: Makes the existing menu template's implicit logic explicit and queryable.

R4: Handles "what if" scenarios — different group sizes, menu swaps, dietary overlays.

That last one is the seed of everything that goes wrong later (in instructive ways). "What if I change the group size from 14 to 20?" seems like a simple question. It turns out to be the question that exposes every hidden assumption in the spreadsheet.²

The first commit

I set up the project: Next.js 15, Supabase, Google Auth, bilingual support (English and Traditional Chinese, because Rocky's Cantonese and not every OBHK staffer reads English comfortably). I give the team @ridgeline.works email accounts for auth.

The first real feature is an ingredient database — 67 items seeded from the spreadsheet. Each ingredient has a category (carb, protein, fresh veg, preserved, condiment), a unit type, and a perishability tier. The second feature is a menu template viewer: the spreadsheet's 5-day menu, digitized into menu_templates, meals, and meal_items tables, viewable as a day-by-day breakdown.

 clients/outward-bound-hk/assessment.md             | 222 +++
 clients/outward-bound-hk/shaping.md                | 461 ++++++
 clients/outward-bound-hk/ration-menu-assessment.md | 139 +++
 14 files changed, 3129 insertions(+)

3,129 lines of documentation before a single line of application code. That ratio feels right for a project where the hardest part isn't building — it's understanding what to build.

What I don't know yet

At this point, the spreadsheet is digitized. The ingredients are in a database. The menu template renders nicely on a phone. It looks like progress.

But I haven't touched scaling. I haven't asked what happens when you change the group size. I haven't looked at the calories. I haven't thought about how to handle the dietary restrictions that the spreadsheet doesn't touch at all — halal, vegetarian, the kid who's both.

Each of those questions will break something I think I understand.

Next: Part 2 — The Scaling Problem, in which changing the group size from 14 to 20 changes almost nothing in the output, and 35 items get reclassified.

Footnotes

1. Whisper does a passable job with Cantonese — I wrote about the zh-not-yue problem separately. The transcriptions needed heavy manual editing, but they preserved Rocky walking me through constraints you'd never find in documentation. ↩

2. R0 through R4 are from the formal shaping document. The numbering is deliberate — R0 is the meta-requirement that the tool should help think, not prescribe. Everything downstream depends on that frame. ↩