Best practices

Mizura can run code, organize evidence, and prepare research outputs. You remain responsible for the research design, data meaning, and conclusions. These habits make the work easier to review and reproduce.

Frame a question the analysis can answer

Include the outcome, predictors or comparison groups, population, time window, and unit of observation. Describe whether the data are paired, clustered, weighted, longitudinal, or observational. Say whether you need an estimate, test, plot, or prediction, and name any decision already made, such as the significance level.

Among [population] during [period], how is [outcome] associated with [predictor]? The unit is [unit]. The data are [design]. Estimate [target], show [outputs], and check [assumptions]. Treat this as [descriptive/causal/predictive] work.

If the design does not identify a causal effect, do not ask for causal language. A model can estimate an association without resolving confounding or selection bias.

Check data meaning before analysis

Confirm that the first sheet or table is the intended dataset.
Inspect column names, types, missingness, and summary values.
Check codebooks for sentinel values, labelled categories, and units.
Resolve ambiguous exclusions, recodes, and missing-value rules explicitly.

A file that imports successfully may still have the wrong coding or sampling structure. Mizura profiles can flag suspicious patterns, but they cannot determine what a code means without documentation. Large dataset profiles may use a repeatable sample. See Your data.

Review the method before a substantial run

Ask for a plan when the work has several analytic choices or when you want to approve the approach before execution. Check that it states why the method fits, which assumptions matter, how those assumptions will be assessed, and what outputs will answer the question. Revise it in chat if needed; press Go only when the plan is acceptable. A normal message does not approve a plan.

For multi-step analysis, the Plan panel can also show a progress checklist and logged decisions. These help track work; they do not validate a study design. See Workflow & plans and Methods.

Inspect the run behind every conclusion

Open the Python script and confirm it used the intended data and variables.
Check the tables and figures, including sample sizes and missingness.
Read the diagnostics named by the chosen method and judge whether they support its assumptions.
Trace reported statistics to tool output. If a number is flagged or absent, ask for it to be computed or remove it.
Review uncertainty, practical size, exclusions, and limitations alongside statistical significance.

Number grounding checks whether a statistic appeared in executed output. It does not prove the code, method, or conclusion is correct. R, Stata, SPSS, and SAS code may be supplied as a translation, but it is not executed by Mizura. See Evidence & literature and How code runs.

Use literature as evidence, not decoration

Treat search results as candidates. Open the source before relying on it, check that its title, author, and year match, and make sure the text supports the claim. Distinguish a source's abstract from its full text. Reports apply stricter checks to citations and quotations than chat answers do.

Use a separate saved dataset version for cleaning, keep meaningful decisions in the session, and export a notebook or replication package when you need a record of the analysis. Read the exported files before sharing them: they may include the original dataset, code, tables, figures, and report. Deleting the local session does not delete copies exported elsewhere. See Reports & exports.

Analysis code runs in a confined local sandbox, while prompts and analysis context are sent to the model service to generate responses. Search and source retrieval also contact external services. Review the installation and data-location notes and privacy policy before using sensitive data.