DoorDash Business Intelligence Analyst (Mid-Level) Interview Preparation Guide

Direct answer

A workable set of signals for whether stakeholders are genuinely aligned on a long-running initiative mixes a few things people actually DO (not just what they say) with a small number of honest, qualitative check-ins, and each signal needs a stated "worrying" threshold and a concrete next step, or the exercise becomes measurement for its own sake.

Structured elaboration

1. Behavioral signals over stated sentiment. Whether stakeholders show up prepared to meetings, act on agreed decisions without re-litigating them later, and proactively surface risks rather than waiting to be asked, are stronger signals than a survey score, because behavior is harder to fake than a rating.
2. A small number of qualitative check-ins. A short, direct question asked periodically ("is there anything about this initiative you're currently worried about that hasn't come up") surfaces concerns a satisfaction score would miss, especially from quieter stakeholders.
3. Decision follow-through rate. Tracking whether agreed decisions actually get implemented as agreed, versus quietly reversed or ignored, is a concrete, checkable proxy for real alignment versus polite agreement in the room.
4. A stated threshold and action for each signal. "If more than one of the last three decisions has been quietly reversed, that's worth a direct conversation" is actionable; a dashboard of numbers with no defined action if they look bad is not.

Worked example

For a multi-quarter initiative, tracking whether the last five cross-team decisions were implemented as agreed (a concrete, checkable number) alongside a brief, honest monthly check-in question to each key stakeholder produces a more reliable read than a generic satisfaction survey. If two of the last five decisions were quietly reworked without discussion, that's a specific, actionable signal of misalignment worth a direct conversation, rather than a vague sense that "something feels off."

Trade-offs and pitfalls

Over-instrumenting this with too many metrics creates its own overhead and can feel like surveillance rather than genuine check-in; keep the signal set small, and make sure the qualitative check-ins are genuinely safe for a stakeholder to answer honestly, or they'll just produce polite, uninformative responses.

Direct answer

The underlying finding stays identical, but you change altitude, vocabulary, and level of supporting detail. An executive gets the headline, the business impact, and the recommended decision in one or two lines up front. The implementation team gets the mechanism, the caveats, and enough of the underlying data to act on it correctly.

Structured elaboration

• Altitude: conclusion-first for the executive, versus enough method detail for the team to trust and reproduce the diagnosis.
• Vocabulary: business-impact language (revenue, risk, timeline) for the executive, technical specifics (segments, funnels, thresholds) for the team.
• Format: a one-slide or one-paragraph summary versus a working document with a data appendix.
• What must never change: the number itself and the direction of the conclusion, in both versions.

Worked example

Finding: onboarding drop-off at step 3 is costing an estimated 6% of new signups per month.
Executive version: "we're losing about 6 of every 100 new signups at the step-3 confirmation screen, fixing it could recover meaningful revenue this quarter, recommend prioritizing it."
Team version: "62% of that drop-off happens on mobile between form submit and confirmation render, median time to abandon is 9 seconds, this looks like a loading-state issue on mobile specifically."
Both versions agree on the 6% headline number and the recommendation to prioritize the fix.

Trade-offs and pitfalls

The two versions can quietly drift into different conclusions if you're not careful, always trace both back to the same underlying analysis. Over-simplifying for the executive can also strip out the one caveat that would have changed their decision, so pick what to omit deliberately, not by default.

What the interviewer probes next

Expect a question about what happens when the executive summary gets forwarded on without you in the room, and how you prevent it from being read out of context.

Direct answer

I take notes that separate what people said from what I saw and what I think it means, and I keep a running list of decisions, assumptions, open questions and action items with owners. I send a clean version the same day (at the latest within 24 hours) and ask for corrections by a named date. Notes that sit in a personal notebook cannot be checked by anyone else.

What I capture, beyond the words

Alongside that: decisions made, assumptions I am relying on, open questions, and actions with owner and date. Keep verbatim quotes and inferred needs apart, so a reader can tell the stakeholder's words from my guess.

A findings record (CRM-style, one row per finding)

Customer relationship management (CRM) tools store a structured record for each contact, account or deal, with every interaction logged against it. The same idea works here, with one row per finding: ID, date, source (person and role), the finding, its type (need, constraint or assumption), the supporting quote, confidence, status and owner. Searching "all constraints from finance" is then easy.

For business intelligence (BI) requirements meetings

A fixed template helps: the report's purpose and audience, the metric definitions, filters, refresh frequency, source tables, and who signs off. Add reproducibility notes: which dashboard or data snapshot (with its date) we looked at, the query or its version, and the assumptions behind any number quoted in the room. Someone should be able to rerun what was shown.

Worked example

Said: "Active customer means anyone who ordered recently." (Priya, finance). Observed: she opened a spreadsheet that excludes refunds. Inferred (mine): "recently" may be 90 days, to confirm. Open question: is 90 days the agreed window? Action: I confirm the window with Priya by Friday.

How soon to share

The same day, while people still remember the conversation. Include the line "Reply by Friday if anything is wrong; otherwise I will treat this as agreed." That line covers the recorded decisions and quotes. Items marked Inferred or Open question stay open until the named person confirms them, so silence never turns a guess into a requirement.

Trade-offs and pitfalls

• Transcribing everything instead of marking what matters.
• Mixing quotes and inference, so guesses harden into "requirements".
• Actions without owners or dates.
• Writing in private shorthand nobody else can read.

Requirements & constraints:

• Manage Power BI, Tableau, LookML artifacts across dev/test/prod.
• Version control, automated data & visualization tests, deploy & rollback, integrate with Git, secure secrets/service accounts, minimal disruption to business users.

High-level architecture:
Developer Git workflow (feature branches → PR → main) → CI server (GitHub Actions/GitLab CI/Bitbucket Pipelines) → automated tests → CD orchestrator (Argo CD/Octopus/ custom scripts) → environment-specific artifact stores (Power BI workspace, Tableau Server/Cloud projects, Looker projects) → monitoring & rollback.

Core components and responsibilities:

1. Git repo(s): store pbix/parameters, Tableau TWB/TDSX or workbook XML exports, LookML files. Use one mono-repo or per-tool repos with consistent branching policy and protected main branches.
2. CI (GitHub Actions): on PR run:
   • Lint LookML, validate Tableau XML schema, check pbix metadata.
   • Run unit/data tests: dbt tests or SQL-based row-counts, schema checks against dev database.
   • Visualization tests: use Snapshot testing (Selenium/Playwright + image diffs) or Assertive tests (check presence of fields, filters, no broken queries).
3. CD: on merge to main:
   • Deploy to dev workspace automatically; run integration tests against dev data.
   • Manual approval gates for test → prod (use pull-request or environment approvals in CD tool).
   • Deployment steps: push LookML via Looker API/git integration; publish Tableau workbook via Tabcmd/REST API to target project; publish Power BI via Power BI REST API/PowerShell (upload dataset, set parameters, refresh).
4. Rollback:
   • Maintain release tags and artifact snapshots in Git and artifact storage.
   • CD tool supports "promote previous tag" or re-deploy earlier commit; for Power BI/Tableau, use API to republish previous file and trigger refresh; for Looker, git revert & deploy.
5. Secrets & service accounts:
   • Use vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) integrated with CI/CD. CI uses short-lived tokens; never store creds in repo.
   • Create least-privilege service accounts for APIs with scoped permissions per environment. Rotate keys regularly and use OIDC where supported (GitHub Actions OIDC to Azure AD).
6. Observability & testing feedback:
   • Log deployments, test results, dataset refresh history.
   • Alerts for failed refreshes, schema drift, visual regressions.
     Trade-offs:

• Image diff visual tests catch layout regressions but are brittle; combine with DOM/assertion tests.
• Full automation to prod increases speed but requires strong approval/gating for exec dashboards.

This pipeline balances reproducibility, test coverage, and safe deployments for BI artifacts.

The mediocre version of this answer jumps straight from "feedback mentions friction" to a fix, like "simplify checkout," without checking whether the quantitative data actually corroborates it. That produces a plausible-sounding recommendation that may not move the metric that matters at all.

Framework: triangulate before you recommend.

1. Quantify the funnel with what you have. Even partial sales data usually has enough to build a rough funnel (session started, checkout started, payment step reached, purchase completed) and find where the drop is steepest.
2. Code the qualitative feedback into themes. Count how often each friction theme appears rather than reacting to a few vivid quotes.
3. Triangulate. Only treat a friction theme as high-confidence if it both appears as a real drop in the quantitative funnel at a matching step, and recurs across multiple independent qualitative sources.
4. For each corroborated theme, propose the lowest-cost intervention that plausibly closes it, not the most sophisticated one available.

Analyses to run: funnel drop-off by step, segment cuts by device and by new-versus-returning customer, a theme-frequency count on the written feedback, and a comparison of theme frequency against which funnel step drops hardest.

Worked example: partial sales data shows that of 10,000 sessions that started checkout, 6,200 reached the payment step (62%), and only 3,100 completed a purchase, meaning half of everyone who reached payment dropped there. Eighty written customer comments mention "shipping cost surprise" 22 times, "too many form fields" 14 times, and "no guest checkout option" 9 times, and all three themes cluster around the payment step. Because the qualitative theme frequency and the quantitative drop-off point at the same step, that is a triangulated, high-confidence signal, not a guess. Recommendations, low-cost and high-confidence:

1. Show estimated shipping cost on the cart page before checkout starts. Addresses the most-cited theme, needs no backend change, just surfacing an existing shipping-rate lookup earlier.
2. Add a guest-checkout option. Addresses the third theme directly and removes a hard blocker for customers who explicitly said they abandoned rather than create an account.
3. Trim the payment-step form to card number, expiry, CVV (Card Verification Value), and billing zip only, deferring optional fields like a full billing address to after purchase.

Extra data you'd request if available: session replays or clickstream data at the payment step to see the exact moment of abandonment, A/B testing capacity to validate the shipping-cost fix on a slice of traffic before full rollout, a device and browser breakdown of the drop to rule out a technical bug rather than a UX cause, and cohort data (new versus returning) to check whether the friction differs by segment.

The same triangulate-before-recommend approach works outside e-commerce. An engineering manager investigating a 20% drop in a recruiting pipeline's offer-acceptance rate would build the same funnel (applied, interviewed, offered, accepted), code exit-interview themes the same way, and only act on a theme like "compensation below expectation" once it lines up with an actual drop concentrated at the offer stage, not just because it is the loudest complaint in the exit interviews.

Direct answer

Once you know a partner function is measured on something different from you (speed versus quality or risk, for example), you scope your asks to be small and cheap under their metric, and you change what "status" means when you talk to them: short, action-oriented signals instead of the detailed risk narrative you'd give your own stakeholders. You're not changing what you need, you're changing how you package it so it doesn't read as a tax on the thing they're rewarded for.

Structured elaboration

1. Diagnose the incentive, don't assume it. Confirm what the partner function is actually measured on (deploy velocity, ticket close time, uptime, cost) rather than inferring it from how they push back. Different sub-teams within the "same" function can be measured differently.
2. Scope the ask to the smallest unit that gets you what you need. If they're speed-measured, don't ask for a broad, standing review of everything; ask for a narrow, well-bounded check on the specific surface that carries the risk you actually care about, and let everything else pass without friction.
3. Translate the ask into their currency. Instead of framing a request around your risk language, frame it around what it costs (or saves) them in their terms: incident response hours avoided, rework avoided, a compliance gate they'd otherwise hit later and more expensively.
4. Change the shape of status, not just the ask. For a speed-measured partner, give a compact signal (blocked/not blocked, a count, a single risk flag) they can act on in seconds. Save the fuller narrative for your own stakeholders who need the detail. Sharing the same long-form update with both audiences under-serves the partner who needs to move fast.
5. Keep a floor. Adapting your ask to their incentive has a limit: there's a minimum you can't compromise below without failing your own mandate. Know that floor before the conversation so "scoping down" doesn't quietly become "giving up the requirement."
6. Revisit as trust builds. Early asks are necessarily narrow and low-trust. As the partner sees your asks are well-scoped and your status updates are reliable, you can often widen the ask (a slightly broader review surface, more lead time) because they've learned you're not going to slow them down for nothing.

Worked example

A platform team is measured on release velocity; a security-minded partner function is measured on defect and incident rates. Rather than asking the platform team to route every change through manual security review (a direct tax on their velocity metric), the ask is scoped to only changes that touch a named risk surface, such as authentication or payment code. Everything else ships without added friction. Status to the platform team is a single weekly line: "2 changes in the review queue, 0 blocking, both cleared by Thursday." The fuller write-up, with rationale and residual risk, goes to the security function's own leadership, not to the platform team, because that's not the audience that needs it to act.

Trade-offs & pitfalls

• Pitfall: scoping the ask down so far it stops actually managing the risk it exists to manage. Know your floor before you negotiate.
• Pitfall: assuming the incentive instead of confirming it. Guessing wrong (e.g., treating a team as purely speed-driven when they're also on the hook for a compliance metric) leads to asks that miss what would actually land.
• Pitfall: sending the same status update to every audience. It either over-informs the speed-measured partner (who tunes it out) or under-informs your own stakeholders (who need the detail to make decisions).
• Senior differentiator: treating the ask size and the status format as things you design deliberately around the incentive gap, and revisiting that design as trust changes, rather than a fixed communication style you use with everyone.

Direct answer

Keep the blended north-star metric as the single headline number, since it still has real organizational value, but never publish it without a fixed, small decomposition by user tenure attached to the same dashboard on the same cadence. The reason a healthy-looking aggregate can hide two opposite trends is that it is a weighted average across the user base, and a shift in the mix of who makes up that average can offset a real change in each segment almost exactly, the same mechanism as Simpson's paradox playing out gradually rather than in one before/after snapshot.

Structured elaboration

Why this is structurally possible, not just a coincidence

The aggregate is a weighted average: $\text{blend} = p \cdot e_{\text{power}} + (1-p) \cdot e_{\text{new}}$, where $p$ is the share of power users and $e$ is each segment's average engagement. If $e_{\text{power}}$ rises while $e_{\text{new}}$ falls, the blend can stay fixed if the mix $p$ shifts by just the right amount, and mix shift is exactly the kind of change a single top-line number cannot reveal on its own.

Framework

• Track the north-star metric within a small, fixed set of segments (tenure buckets are a natural first cut: 0-30 days, 30-90 days, 90-plus days) on the same dashboard and cadence as the aggregate, not as a separate ad hoc report.
• Track the segment mix (share of total users in each bucket) alongside the segment-level metric, because a mix shift with stable segment-level numbers is a different problem (a growth or onboarding-funnel issue) than declining segment-level numbers with a stable mix.
• Set an explicit trigger: if any segment's trend diverges from the aggregate's trend by more than an agreed threshold for two consecutive reporting periods, that forces a mandatory segment review, independent of whether the aggregate itself moved at all.
• Cap the tracked dimensions at two or three (tenure, plan tier, acquisition channel) so the decomposition does not become its own form of metric overload.

Worked example

Month 1: power users are 20% of the base with average engagement 50 (arbitrary weekly engagement units), and new users are 80% of the base with average engagement 12.5:

Suppose over the following months power-user engagement genuinely rises to 70 while new-user engagement genuinely falls to 5, and the mix shifts to a power-user share $p_2$. Solve for the mix shift that would keep the blend exactly at 20:

So a mix shift from 20% power users to about 23.1% power users, combined with power-user engagement rising from 50 to 70 and new-user engagement falling from 12.5 to 5, reproduces the exact same blended value of 20 both times:

A relatively small, easy-to-miss mix shift is enough to fully cancel two large, opposite-direction segment trends in the headline number.

Trade-offs & pitfalls

Adding a mandatory segment decomposition to every report increases dashboard and analyst overhead, and tracking too many dimensions dilutes attention the same way too many top-level metrics would, so the dimension cap matters as much as the decomposition itself. A poorly chosen divergence threshold either triggers so often that the mandatory review becomes noise, or is set so loosely that a real multi-month divergence like this one still slips through before anyone is forced to look. The segment-level view should become the operative signal for decision-making once a real divergence is confirmed, but announcing that the north-star metric is "currently misleading" without also showing the decomposition that explains why can undermine trust in the metric more than the underlying problem warrants.

Direct answer. HAVING filters AFTER the GROUP BY has already computed every group's aggregate, so a condition that could have excluded rows BEFORE grouping, if it were expressed as a WHERE clause instead, forces the database to do the full grouping work for every group first and only discard the unwanted ones afterward; moving any predicate that doesn't actually depend on the aggregate itself into WHERE lets the engine filter rows out before the expensive grouping work happens at all.

Structured elaboration. WHERE filters individual rows before grouping; HAVING filters GROUPS after aggregation, and can only reference conditions involving the aggregate result itself (like a computed count or sum), since individual row values are no longer available at that stage. A predicate that's genuinely about the aggregate (HAVING COUNT(*) > 5, filtering on how many rows ended up in a group) has to stay in HAVING, there's no way to know a group's count before you've grouped it. But a predicate that's actually about individual ROWS, and happens to be written after GROUP BY out of habit or oversight, belongs in WHERE, moving it there lets the engine discard non-matching rows before doing any grouping work on them at all, rather than grouping everything first and throwing entire groups away afterward.

Worked example. I verified the semantics with 2,000 orders spread across 20 customers, filtered to status = 'completed' and grouped with HAVING COUNT(*) > 5:

-- correct as written: the row-level filter is already in WHERE
SELECT customer_id, COUNT(*) AS c
FROM orders
WHERE status = 'completed'
GROUP BY customer_id
HAVING COUNT(*) > 5;

This returned all 20 customers, each with roughly 33-34 completed orders (consistent with 2,000 orders split across 20 customers at a completion rate that clears the threshold of 5), confirming the pattern itself is correct here; the actual anti-pattern this survivor is testing shows up when a query moves a genuinely ROW-LEVEL condition, like the status = 'completed' filter itself, INTO the HAVING clause instead (for example HAVING status = 'completed' AND COUNT(*) > 5), which forces the engine to group ALL orders (completed and not) before discarding the non-completed ones, rather than filtering them out first.

Trade-offs and pitfalls. The fix is purely about WHERE the filtering happens, not about changing what the query logically returns; verify a rewrite moving a condition from HAVING to WHERE produces the identical result set before trusting it, since a condition that mixes row-level and aggregate-level logic in one HAVING clause needs to be split carefully, not just relocated wholesale.

Complexity

Filtering rows in WHERE before grouping reduces the INPUT to the grouping step; filtering in HAVING after grouping means the grouping step processed rows that were always going to be discarded, extra work with no benefit.

Edge cases

A condition that references BOTH a raw column and an aggregate in the same clause needs to be split: the raw-column part moves to WHERE, and only the aggregate-referencing part stays in HAVING.

Direct answer

Give the executive-dashboard path and the ad-hoc, lower-priority path separate directed acyclic graphs (DAGs), or at minimum no shared edges between them, so a failure or slow run in the low-priority branch can never block, delay retries for, or consume retry budget from the critical branch. Where both paths need the same upstream source, fan out from a single shared ingestion step into two independent downstream graphs, rather than making one branch depend on the other's completion.

Structured elaboration

Dependency structure: any task on the critical path should have zero downstream or upstream edges to a non-critical task. If both branches read the same raw table, model that as two independent consumers of one producer, not a chain. A shared DAG where the low-priority branch is simply further along the same line means a slow ad-hoc stage delays the scheduler's view of whether the run is complete, even when the actual dashboard output was never late.

Retries: give the critical path a short retry interval with a small number of aggressive retries, so a transient failure resolves fast. The ad-hoc path can use longer backoff, more retries, or no automatic retry at all (a rerun-on-demand model), since it is acceptable for it to take longer or wait for manual attention.

Service-level agreements (SLAs): define the SLA only against the critical path's own tasks. If the SLA calculation looks at when the whole DAG finished instead of when the tasks feeding the dashboard finished, a slow ad-hoc branch can falsely trip an SLA alert for a dashboard that was actually delivered on time.

Resource contention: the two paths can compete for the same execution resources (worker slots, warehouse compute) even when they are structurally independent DAGs. Give the critical path its own resource pool or a higher-priority queue slot so it is never queued behind ad-hoc work.

Worked example

A cohort or retention dashboard needs a daily active-user rollup ready by a fixed review time, while the same raw event stream also feeds a separate ad-hoc analysis DAG (funnel breakdowns, one-off segment cuts) with no fixed deadline. The structure: one shared ingestion task lands raw events; two independent downstream DAGs both consume it. The cohort/retention DAG (aggregate, compute the retention window, publish to the dashboard) carries a tight SLA and fast retries. The ad-hoc DAG (exploratory transforms) has its own scheduling and no SLA. If the ad-hoc DAG's exploratory job hangs because of a runaway query, the cohort/retention DAG is unaffected, because it was never downstream of it, only downstream of the shared ingestion task, which had already completed. Because the cohort DAG's own compute only processes the day's new partition rather than the full history, its SLA can reasonably be set tight precisely because it has been structurally decoupled from anything the ad-hoc path might do; a shared-DAG design would force that same SLA to account for the ad-hoc branch's unpredictable runtime too.

flowchart LR
  ingest["shared ingestion"] --> critical["critical: retention rollup"]
  ingest --> adhoc["ad-hoc: exploratory transforms"]
  critical --> dashboard["executive dashboard"]
  adhoc --> analysis["ad-hoc analysis output"]

Trade-offs & pitfalls

Fully separate DAGs mean the shared ingestion logic is maintained once but consumed twice, which is fine, but if the two teams then diverge and each patches its own copy of ingestion, the coupling problem reappears in a different shape; ingestion should stay single-owned. Separate resource pools or queues cost real reserved infrastructure that can sit idle when the critical path is not running, that is the price of guaranteeing it is never queued behind ad-hoc work. The most common wrong turn is assuming task-level retry configuration alone solves this: if the DAG structure itself couples the two paths through a shared edge, no retry policy or priority setting fixes the fact that the scheduler still sees one graph.

Direct answer
A marketing-budget-allocation executive dashboard needs a small set of trusted, reconciled per-channel and per-region numbers (LTV/CAC point estimates, a customer's predicted lifetime value divided by what it costs to acquire them, together with uncertainty ranges), a clear data-lineage story tying those model outputs back to the raw spend/conversion feeds, and visuals (marginal-ROAS curves, scenario simulation) chosen to make the reallocation trade-off actionable rather than merely descriptive.

Structured elaboration

1. Required data sources: the per-channel and per-region ad-spend and conversion feeds from each ad platform, the LTV/CAC model's own output table (point estimate plus uncertainty interval per channel and region), a historical spend-versus-response dataset used to estimate diminishing returns, and the finance-approved total budget-constraint record.
2. Source validation and reconciliation: validate that the per-channel spend figures tie back to each ad platform's own reported spend within an acceptable tolerance, and that the model output table's total predicted spend matches the actual budget-constraint record, so a channel's uncertainty range is never computed against stale or unreconciled spend data.
3. Model outputs to surface: always show the point estimate AND the uncertainty range for LTV/CAC per channel/region, never a bare point estimate, since an allocation decision made on a point estimate alone hides how confident the model actually is.
4. Decision rule for reallocating budget: reallocate from a channel/region only when its marginal ROAS (the model's forecasted return on the NEXT incremental dollar, not its average historical ROAS) falls below the portfolio's target hurdle rate (the minimum acceptable return, typically set by finance, below which a dollar isn't worth investing further in that channel), and only into a channel/region whose marginal ROAS is comfortably above that hurdle after accounting for the uncertainty range, not just the point estimate; where two candidates' uncertainty ranges overlap substantially, treat the reallocation as a hypothesis to test at smaller scale first, not a full-budget move.
5. Visualization choices: marginal-ROAS curves per channel/region (showing how ROAS declines with each additional dollar, the direct evidence for diminishing returns) plotted with a shaded uncertainty band around each curve, and a scenario-simulation view letting the executive test a candidate reallocation amount between two channels/regions and see the projected blended LTV/CAC outcome and its range before committing.
6. Decision framing: every visual should make the trade-off explicit (e.g. "reallocating $200K from Channel A to Channel B is projected to increase blended LTV/CAC by X, within a stated uncertainty range") rather than just displaying historical figures.

Worked example
Region C's Paid Social channel shows a marginal ROAS of 1.1x (90% CI: 0.8x-1.4x) against a portfolio hurdle rate of 1.5x, flagging it as a reallocation-from candidate; Region A's Search channel shows a marginal ROAS of 2.3x (90% CI: 1.9x-2.7x), comfortably above hurdle. The scenario-simulation view lets the executive test moving $200K from Region C/Paid Social to Region A/Search and see the projected blended LTV/CAC and its uncertainty range before approving the actual budget change.

Trade-offs and pitfalls
Skipping the spend-reconciliation step is the most common and most damaging shortcut on a budget-allocation dashboard: a model output that looks right but doesn't tie back to actual ad-platform spend or the finance-approved budget constraint can quietly justify a reallocation that finance later rejects, undermining trust in the model the first time the discrepancy surfaces.