Analysis Authoring Conventions
Goal
Produce exploratory notebooks and analytical dashboards whose structure, visualization choices, and scale handling are deliberate rather than incidental. This skill supplies the editorial judgment that generic file, notebook, terminal, and browser tooling does not carry.
Flow
- Confirm the analysis question, the datasets in scope, and the deliverable shape: notebook, dashboard, or both.
- Read the available profile and objectives artifacts rather than re-deriving column semantics.
data-catalog owns the profile contract and semantic roles.
- Select the deliverable's section sequence from the matching reference, including only the conditional sections the data supports.
- Choose each visualization from its analytical goal, applying the scale thresholds rather than plotting whole datasets by default.
- Record interpretation next to each figure so a reader learns what the figure answers, not only what it shows.
- Validate the deliverable against its completeness expectations, and for dashboards apply the responsiveness budgets as project-adjustable defaults.
Inputs
- The analysis question and intended audience
- Dataset locations and, when available, an existing data profile and declared objectives
- The deliverable shape and its destination
- Any project-specific performance budget that overrides the defaults here
Success criteria
- The deliverable follows the section sequence for its shape, and conditional sections appear only when the data supports them.
- Every figure is preceded by the question it answers and is followed by an interpretation placeholder or an actual reading.
- Visualization selection matches the analytical goal, and dense or high-cardinality data is sampled, binned, or truncated deliberately.
- Every meaningful distinction is encoded in a channel besides colour, and categorical and continuous scales use colourblind-safe palettes.
- Notebook code stays modular, with repeated transformation logic extracted rather than duplicated across cells.
- Dashboard caching distinguishes serializable data from global resources, and cross-page interaction state is explicit.
- Dashboard validation reports functional, data, and responsiveness findings against stated budgets.
- Uncertainty, data limitations, and open questions are written down rather than implied.
Constraints
- Describe judgment, not tool mechanics. Notebook creation, cell execution, output inspection, browser navigation, and screenshots are native tool capabilities and are not narrated here.
- Reference profile and objectives artifacts instead of copying their contents into the deliverable.
- Keep persistence format and dataset versioning with
dataops, which owns pipeline invariants and storage conventions.
- Keep entity semantics, relationships, and semantic roles with
data-catalog.
- Treat the performance budgets as defaults. A project-stated budget supersedes them.
- Do not embed environment-specific absolute paths in a deliverable.
Ownership boundaries
| Concern |
Owner |
| Column semantics, semantic roles, profile and objectives contracts |
data-catalog |
| Persistence format, dataset versioning, pipeline and validation placement |
dataops |
| Accessibility conformance criteria and assistive-technology review |
accessibility |
| Evaluation dataset design for AI systems |
evaluation-design |
| Trained-model evaluation, tracking, and readiness |
ml-experimentation |
Stop rules
- Stop and ask when the analysis question is unstated, because section selection and visualization choice both depend on it.
- Stop and record a limitation rather than inventing an explanation for a pattern the data does not support.
- Stop and route to
data-catalog when column meaning, grain, or relationships are ambiguous.
- Stop and route accessibility conformance work to the
accessibility skill rather than restating criteria here.
Package resources
| Resource |
Use |
| eda-notebook-authoring.md |
Read when composing or reviewing an exploratory notebook |
| dashboard-authoring-and-validation.md |
Read when composing, reviewing, or validating an analytical dashboard |
Attribution
This package is repository-original content licensed CC BY 4.0. The section sequences, selection thresholds, completeness expectations, and default budgets are HVE Core conventions rather than reproductions of an upstream specification.
1---2name: analysis-authoring3description: Authoring conventions for exploratory data analysis notebooks and analytical dashboards, covering section sequence, visualization selection, scale thresholds, caching and state, and dashboard validation budgets. Use when composing or reviewing an EDA notebook, an analytical dashboard, or a dashboard test pass.4license: CC-BY-4.05---6
7# Analysis Authoring Conventions
8
9## Goal
10
11Produce exploratory notebooks and analytical dashboards whose structure, visualization choices, and scale handling are deliberate rather than incidental. This skill supplies the editorial judgment that generic file, notebook, terminal, and browser tooling does not carry.
12
13## Flow
14
151. Confirm the analysis question, the datasets in scope, and the deliverable shape: notebook, dashboard, or both.
162. Read the available profile and objectives artifacts rather than re-deriving column semantics. `data-catalog` owns the profile contract and semantic roles.
173. Select the deliverable's section sequence from the matching reference, including only the conditional sections the data supports.
184. Choose each visualization from its analytical goal, applying the scale thresholds rather than plotting whole datasets by default.
195. Record interpretation next to each figure so a reader learns what the figure answers, not only what it shows.
206. Validate the deliverable against its completeness expectations, and for dashboards apply the responsiveness budgets as project-adjustable defaults.
21
22## Inputs
23
24* The analysis question and intended audience
25* Dataset locations and, when available, an existing data profile and declared objectives
26* The deliverable shape and its destination
27* Any project-specific performance budget that overrides the defaults here
28
29## Success criteria
30
31* The deliverable follows the section sequence for its shape, and conditional sections appear only when the data supports them.
32* Every figure is preceded by the question it answers and is followed by an interpretation placeholder or an actual reading.
33* Visualization selection matches the analytical goal, and dense or high-cardinality data is sampled, binned, or truncated deliberately.
34* Every meaningful distinction is encoded in a channel besides colour, and categorical and continuous scales use colourblind-safe palettes.
35* Notebook code stays modular, with repeated transformation logic extracted rather than duplicated across cells.
36* Dashboard caching distinguishes serializable data from global resources, and cross-page interaction state is explicit.
37* Dashboard validation reports functional, data, and responsiveness findings against stated budgets.
38* Uncertainty, data limitations, and open questions are written down rather than implied.
39
40## Constraints
41
42* Describe judgment, not tool mechanics. Notebook creation, cell execution, output inspection, browser navigation, and screenshots are native tool capabilities and are not narrated here.
43* Reference profile and objectives artifacts instead of copying their contents into the deliverable.
44* Keep persistence format and dataset versioning with `dataops`, which owns pipeline invariants and storage conventions.
45* Keep entity semantics, relationships, and semantic roles with `data-catalog`.
46* Treat the performance budgets as defaults. A project-stated budget supersedes them.
47* Do not embed environment-specific absolute paths in a deliverable.
48
49## Ownership boundaries
50
51| Concern | Owner |
52|---------------------------------------------------------------------------|----------------------|
53| Column semantics, semantic roles, profile and objectives contracts | `data-catalog` |
54| Persistence format, dataset versioning, pipeline and validation placement | `dataops` |
55| Accessibility conformance criteria and assistive-technology review | `accessibility` |
56| Evaluation dataset design for AI systems | `evaluation-design` |
57| Trained-model evaluation, tracking, and readiness | `ml-experimentation` |
58
59## Stop rules
60
61* Stop and ask when the analysis question is unstated, because section selection and visualization choice both depend on it.
62* Stop and record a limitation rather than inventing an explanation for a pattern the data does not support.
63* Stop and route to `data-catalog` when column meaning, grain, or relationships are ambiguous.
64* Stop and route accessibility conformance work to the `accessibility` skill rather than restating criteria here.
65
66## Package resources
67
68| Resource | Use |
69|-------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
70| [eda-notebook-authoring.md](references/eda-notebook-authoring.md) | Read when composing or reviewing an exploratory notebook |
71| [dashboard-authoring-and-validation.md](references/dashboard-authoring-and-validation.md) | Read when composing, reviewing, or validating an analytical dashboard |
72
73## Attribution
74
75This package is repository-original content licensed CC BY 4.0. The section sequences, selection thresholds, completeness expectations, and default budgets are HVE Core conventions rather than reproductions of an upstream specification.
gabrielmoreira