Finding and fixing a real FinOps gap in my own org

Expected question

"Tell me about a time you audited something you'd built or claimed publicly, found it didn't hold up, and fixed it."

Variant forms

Interviewers often probe the same competency with different framing — recognize the archetype and answer with your story:

"Tell me about a time you discovered your own cost or usage claims were wrong — what did you do?"
"Describe finding a FinOps gap with no external pressure to look — why did you dig?"
"Tell me about publishing a fix after realizing a portfolio demo or metric was incomplete."
"How do you handle intellectual honesty when the audit would make your prior work look worse?"
"Tell me about turning a one-time cost surprise into a durable tracking system."
"Describe aligning engineering incentives with cloud spend without becoming 'the no team.'"
"Tell me about a time chargeback or attribution broke trust — how did you repair it?"
"Walk me through making LLM/token spend visible per team or tenant after a bill spike."

The question, as it might actually be asked

"Tell me about a time you audited something you'd built or claimed publicly, found it didn't hold up, and fixed it." Nobody was forcing this audit. The signal is whether you go looking for the gap between what you claim and what you shipped when no one's checking. This story is portfolio O evidence — not a Lucid P claim.

Situation

I'd written a Substack piece arguing AI cost governance belongs in the architecture — not bolted on as a dashboard after traffic shows up. Easy thesis. Harder to prove I actually live by it.

Task

Audit my own platforms against that thesis. Not treat the essay as thought leadership floating above systems that were quietly faking their numbers.

Action

I read the real LLM-client code in AegisAI and AegisLoop — both had a "FinOps" module. Both were faking it, differently. AegisAI's registry computed monthly cost from static seed data that never updated after the seed. AegisLoop guessed token counts from output character length, even on the path making a real OpenAI-compatible call whose response already had prompt_tokens / completion_tokens. Discarded. Never read.

First draft of the fix: patch the logic into each repo. Mid-plan that felt wrong — two repos each computing "their own" cost can never produce a real cross-tenant total. So I changed the plan: build a third, standalone service (agent-finops), same single-purpose pattern as the rest of the org. Built it. Verified end-to-end against a live instance — real usage, real budget, real breach over real HTTP — before wiring either consumer. Then AegisAI got a real kill-switch on breach; AegisLoop halted dispatch inside the mission. Fabricated numbers out; per-call token metering in.

Result

Both platforms report metered cost instead of guesses. The audit-and-fix itself became the proof for the essay: not "I believe cost is an architecture problem," but "I found my own gap and shipped the shared ledger."

The follow-up question you should expect

"Why didn't you just patch the two existing repos instead of building a third?" Because the thing I actually needed — one cross-repo budget total, not two fragments — needs a shared ledger. Two repos each with "real" local cost still can't answer "what's our total AI spend right now." That requirement only got clear mid-plan. Honest answer: I changed course when I saw it, instead of defending the first approach because I'd already started.

Candidate-owned evidence prompts

Which cost figures are portfolio/demo measurements versus employer P results?
What baseline window, categories, and owners define the savings claim?
What organizational mechanism remained after the candidate left the critical path?
What objection or setback changed the FinOps approach?

Author reference (do not memorize)

Treat any STAR-shaped narrative in this file as an author reference / interview template. Do not memorize it as autobiography. Convert a sentence into an "I" claim only after the evidence ledger records metric provenance, personal contribution, and public-speak boundaries.

Staff+/Principal signal rubric

Mid-level: describes finding a problem and fixing it; may frame the fix as the first idea considered, without discussing alternatives or why they were rejected.
Senior: names at least one alternative approach considered and why it was rejected, with a concrete technical detail about what was actually wrong — not just "it was broken."
Staff+: explains a requirement that only became clear mid-plan, not from the original ask, and how that requirement changed the architecture (not just the implementation details).
Principal: connects the specific fix to a durable process or structural change that would catch the same class of problem next time, treating the audit itself as evidence for a broader claim rather than a one-off correction.