Build a domain analytics capstone from a vague business question

A strong analytics capstone begins with a decision the available evidence can support. “Improve sales” is a business ambition, not yet an analytical specification. Convert it into a bounded question, state what data can answer it and make the analysis reproducible for another person.

The finished project should contain more than a dashboard: data definitions, validation, expected results, limitations and a clear next action.

Narrow the request without losing its purpose

Consider a fictional retail manager asking, “Why are we losing sales, and what should we fix first?” The supplied data contain daily sales and availability snapshots for two products over four dates. They do not contain unconstrained demand or the counterfactual sales that would have occurred with full availability.

A defensible first question is: “Can we measure availability reliably, and which observed zero-stock snapshots should operations investigate?” That question preserves the business purpose while avoiding an unsupported lost-sales estimate.

The accompanying complete capstone case records the scope, decision memo and proposed assessment rubric. It is an original synthetic teaching resource, not a real client outcome.

Make the expected population independent of the extract

Declare products A and B and four scheduled observation dates. That creates eight expected product-date snapshots. A missing row must remain part of the expected population; otherwise deleting data can make coverage look better.

Require one row per product and date. Known availability has a nonnegative integer quantity. Unknown availability has no quantity. A recorded zero is an observed stockout snapshot, not a generic replacement for missing data.

The capstone script validates those rules before producing a result. It rejects duplicate keys, out-of-scope records and contradictory coverage values.

Run the workflow and verify expected results

From the domain-operations lab directory, run python capstone.py. It reads the supplied CSV, calculates the coverage and stockout measures, runs five checks and writes capstone-result.json with source and code hashes.

The following smaller example exercises the same analysis functions:

from capstone import read_rows, analyze, verify

rows = read_rows()
report = analyze(rows)
assert report['scheduled_snapshots']==8
assert report['known_snapshots']==6 and report['unknown_snapshots']==2
assert report['observed_stockouts']==2 and report['coverage']==.75
assert report['all_snapshot_lower_bound']==.25
assert report['all_snapshot_upper_bound']==.5
damaged = analyze(rows[1:])
assert damaged['scheduled_snapshots']==8
assert damaged['known_snapshots']==5
assert damaged['missing_rows']==[['A','2026-01-01']]
assert verify()['checks_passed']==5
print(report)

The missing-row mutation is particularly useful: it tests a failure that a report built only from received records could miss. The expected denominator stays eight while coverage falls.

Hashes help identify the exact input and code used. They do not prove that the source is complete or truthful; those claims require separate provenance and operational evidence.

Write a decision memo with an honest boundary

The completed example finds six known observations, two unknown and two observed zero-stock snapshots. Coverage is 75%. Among known snapshots, stockout incidence is 33.3%. Across all scheduled snapshots, the missing-data bounds are 25%–50%.

The recommended next action is to repair coverage and inspect the confirmed zero-stock observations against replenishment records. The data do not identify lost demand, stockout duration or the effect of a replenishment intervention.

That limitation is part of the result. A capstone is stronger when it identifies exactly what additional evidence would answer the next question than when it fills the gap with a confident invented estimate.

Assess correctness and decision quality

The supplied rubric weights decision definition, data quality, reproducibility, interpretation and communication. A visually polished submission that turns unknown stock into zero should fail the relevant correctness criteria.

Require expected outputs and at least one meaningful failure case. Also ask a reviewer to change an input and explain how the result should respond before rerunning the code. That checks understanding beyond copying a notebook.

Keep public portfolio data synthetic or appropriately permitted and de-identified. Do not imply that fictional results came from a real employer or customer. Label proposed interventions separately from actions that were actually implemented and evaluated.

Exercise: extend the case with intraday stock transitions. Write a separate duration contract and identify which missing intervals prevent a complete calculation. Keep the original snapshot metric reproducible alongside the new measure.

NeuraPath's Data Analytics with Generative AI course is the relevant course path for this combination of SQL population design, Python validation, descriptive analysis and business communication. The capstone demonstrates the depth a reviewable analytics project should make visible.

Continue learning

This article is part of the Domain analytics and business cases sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the preceding task in Analyze marketplace seller performance with comparable cohorts.
• Return to the cluster foundation in Retail sales analysis: separate price, volume and mix.