High-Stakes Analytics & Decision Lab: an evidence-gated analytics Skill that can refuse to recommend
A platform-neutral analytical Skill that profiles messy data, selects case-adaptive methods, and produces source-backed visual reports for high-stakes decisions.
At a glance
- What is it?
- A platform-neutral Agent Skill that profiles messy data before any model runs, picks analytical routes the evidence supports, and ships source-backed reports. Its most interesting feature is the permission to stop.
- Who is it for?
- Adopt it if your decisions carry real cost and you want the analytical process itself to be reviewable, because the fixed evidence spine (question, population, grain, target quantity, horizon, lineage, claim boundary) is declared before any method is chosen. Do not adopt it if you want a fast report generator or a notebook replacement; the README states the result is not a fixed report generator, and a valid outcome can be an evidence request or no recommendation at all.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 21, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: analysis that fails before the model runs
The README lists the failure modes it was built against, and they are all upstream of modelling: an underspecified question, an implicit data contract, hidden cleaning choices, uncertainty treated as independent, and a recommendation written because the template expects one. That last item is the sharpest. Most analytics tooling assumes a deliverable exists and works backwards from it. This project assumes the opposite, and treats "no recommendation" as a legitimate terminal state.
The intended user is someone whose decision has consequences: a risk analyst, a research engineer, a data team lead who has to defend a number in front of people who will act on it. The repository is described as a platform-neutral Agent Skill and a reproducible research portfolio. It is not a dashboard product and not a library you import into a pipeline. It is a procedure, packaged so an agent can follow it.
A fixed evidence spine with an adaptive case layer
The architecture splits into two parts. The fixed evidence spine holds the question, population, unit, target quantity and horizon, plus source lineage, quality status and reproducibility, plus uncertainty, limitations and claim boundary. The adaptive case layer holds the route, fields, methods, validation, figures, report sections and decision criteria. The spine does not move between cases. The layer does.
The data gate is where this becomes concrete. According to the README, uploaded row-level data do not go directly into a model. The system preserves the original, establishes a contract, checks grain and keys, and profiles quality and privacy. Material transformations cause a pause rather than a silent rewrite. Only after that does route selection happen, and routes are added incrementally: descriptive, diagnostic, predictive or prescriptive work appears only when justified.
Uncertainty handling is the design choice I find most defensible. The README says shared time, market, participant, campaign, operational and spatial shocks are retained rather than assumed away. Treating observations as independent is the single most common way an analysis overstates its own confidence, and building the dependency into the spine rather than a footnote is unusual.
Every complete project keeps four artifacts together: report.md, results.json, chart-map.json and figures/*.svg. A justified decision layer adds decision-report.md and decision-results.json, and the README is explicit that this layer never replaces the primary evidence product. The chart map is the part worth noting: it is a figure-to-question and source contract, so a chart cannot exist without a stated question it answers.
Installing the Skill and running the 60-second walkthrough
The README gives one install command. It uses the Agent Skills installer and pulls the compact package rather than the whole research portfolio.
npx skills add limingrui679-design/high-stakes-analytics-decision-lab -gThe README states the installer discovers the package under skills/high-stakes-analytics-decision-lab/, which it describes as 39 files and about 472 KiB. The machine-readable file and hash contract lives in bundle-manifest.json inside that directory. For Codex-specific and no-install options, the README points to docs/getting-started.md.
If you would rather not install anything, the repository has direct entry points through scripts/hsadl.py. The safest first run is the demo, which the README describes as a 60-second walkthrough over synthetic data that produces source preservation, a contract, a quality gate, a route and accessible SVGs, with no model and no recommendation.
python3 scripts/hsadl.py demo --output-dir build/demoBefore either of those, the environment audit tells you whether your machine can run the rest. It checks Python, the runtime, templates, write access and the Skill footprint.
python3 scripts/hsadl.py doctorOnce the doctor passes, the two entry points that matter are a question alone, which returns an evidence and method blueprint with no invented result, and a question plus data, which preserves the source and produces a draft contract, a readiness profile and a list of unresolved decisions.
python3 scripts/hsadl.py route "<question>" --scope full --output-dir <path>
python3 scripts/hsadl.py start <data.csv> --question "<question>" --output-dir <path>For an existing decision case, the README specifies a two-step sequence: validate the case file, then run it. The validated outputs cover expected, tail, sensitivity, provenance and group-impact results.
python3 scripts/hsadl.py validate <case.json>
python3 scripts/hsadl.py run <case.json> --output-dir <path>Inside an agent, the invocation is a single prompt that names the Skill and asks for the readiness gate first.
The stopping states are the point, and also the friction
A valid result here can be a bounded action, a pilot requirement, targeted diligence, an evidence request, negative validation, or do_not_deploy. That list is the project's identity. It is also the reason a lot of teams will bounce off it.
If you need a chart by Friday and the data gate finds that the grain is ambiguous or the keys do not hold, this tool will tell you that instead of producing the chart. That is correct behaviour for a high-stakes decision and wrong behaviour for a weekly reporting cadence. The README does not document an override that skips the readiness gate, and it does not document rollback semantics for a transformation that has already been applied. Those are real gaps for anyone planning to run this unattended.
The other constraint is environmental. The Makefile's check-python target exits with "Python 3.11 or newer is required" on anything older, and pyproject.toml sets mypy to python_version 3.11 and Ruff to target-version py311. So the tooling is pinned to a modern interpreter, and a team on 3.9 or 3.10 has an upgrade in front of it before the first useful command runs.
Scope is the third limit. This is a Skill plus a portfolio of worked cases, not a service. There is no homepage listed for the repository, and the README's own framing is that the result is not a fixed report generator. If you want a hosted analytics platform, this is not one.
How it differs from a notebook-plus-checklist workflow
The obvious alternative is the standard one: a Jupyter notebook, a data-quality library such as Great Expectations or pandera, and a written template for the report. That stack can cover the same ground, and for many teams it already does.
The difference is where the enforcement lives. In a notebook stack, the quality check is a cell someone may delete, and the report template is a document a human chooses to follow. Here the sequence is the artifact. The route is selected after the readiness profile, the figure set is bound to questions through chart-map.json, and the terminal status can be a refusal. You can reproduce that discipline in a notebook, but you have to reproduce it yourself every time, and nothing in the notebook will stop you from skipping it.
The second difference is packaging. A notebook is not installable into an agent. The compact package here is, through a single npx skills add command, which means the same procedure runs whether a human or an agent is driving. That portability is the reason to choose this over a well-maintained internal template, and the reason not to choose it if your team has no agent workflow at all.
Maintenance, verification targets and the MIT licence
The last push to the default branch was on 2026-09-07, and the repository is not archived. Three releases landed in August 2026: v1.1.0 on 2026-08-19, v1.1.1 on 2026-08-19, and v1.1.2 on 2026-08-23.
The upgrade surface is larger than a single package version. The Makefile exposes separate targets for the runtime audit, the demo, the compact bundle rebuild, the regression suite, the fifteen-project portfolio rebuild, the combined verify target, the quality gate and the visual regeneration. The quality target chains a tracked-secret check, Ruff, mypy and codespell across README, CHANGELOG, CONTRIBUTING, SECURITY, VERSIONING, demo, docs, references, scripts, skills and tests. If you fork this, that chain is what you inherit: three requirements files (requirements-dev.txt, requirements-maintenance.txt, requirements-security.txt) and a prose linter that will fail your documentation on spelling.
The licence is MIT, per LICENSE.txt and the README badge. That is permissive and places few obligations on reuse. It also means no warranty and no support commitment, which matters more than usual here because the tool's output may feed a consequential decision. Whether an MIT-licensed analytical procedure meets your organisation's model-risk or audit requirements is a question for your own reviewers, not something the repository settles.
Editorial conclusion
Adopt it if your decisions carry real cost and you want the analytical process itself to be reviewable, because the fixed evidence spine (question, population, grain, target quantity, horizon, lineage, claim boundary) is declared before any method is chosen. Do not adopt it if you want a fast report generator or a notebook replacement; the README states the result is not a fixed report generator, and a valid outcome can be an evidence request or no recommendation at all. Verify three things first: that your Python is 3.11 or newer, since the Makefile's check-python target refuses older interpreters; that the compact Skill package under skills/high-stakes-analytics-decision-lab/ is what you actually want, since it is 39 files and about 472 KiB rather than the full portfolio; and that your team can live with a workflow whose default answer may be that the evidence does not support a decision yet.
Frequently asked questions
What are the four main types of data analytics, and how does High-Stakes Analytics & Decision Lab use them?
The README describes descriptive, diagnostic, predictive and prescriptive work as routes that are added only when the evidence justifies them. They sit in the adaptive case layer, on top of a fixed evidence spine that does not change between cases.
What is analytics-based decision-making in the context of High-Stakes Analytics & Decision Lab?
The README frames it as a sequence: declare the question, population, grain, target quantity, horizon, lineage and claim boundary first, then add analytical routes the evidence supports. A Decision Intelligence Brief is added only when the evidence and decision context justify one.
What Python version does High-Stakes Analytics & Decision Lab require?
Python 3.11 or newer. The Makefile's check-python target exits with an error below that, and pyproject.toml sets Ruff to target-version py311 and mypy to python_version 3.11.
Can High-Stakes Analytics & Decision Lab run without installing anything?
Yes. The README lists direct repository entry points through scripts/hsadl.py, including doctor, demo, route, start, validate and run, and points to docs/getting-started.md for no-install options.
What files does a complete High-Stakes Analytics & Decision Lab project produce?
The README lists report.md, results.json, chart-map.json and figures/*.svg. A justified decision layer adds decision-report.md, decision-results.json and its own figure contract, without replacing the primary evidence product.
Community notes