Statistical Decision Tree — Evidence-Aware Analysis Guidance

Turn a research question into a defensible statistical analysis plan.

Comment

Statistical Decision Tree

Inspiration

As a primary-school educator and PhD candidate in Educational Research, I work with quantitative research questions that sit at the intersection of education, social and emotional learning, and self-regulated learning. I repeatedly encountered the same practical problem: researchers may know how to run a familiar command in a statistical package, but still be uncertain whether that analysis actually answers their research question.

Choosing a method is rarely a one-variable decision. A defensible analysis depends on the research goal, study design, measurement structure, outcome type, sample, model components, assumptions, and the quantity that the hypothesis implies. For example, a mediation hypothesis is about an indirect effect; a standard linear regression alone does not estimate the bootstrap confidence interval for that indirect effect. I wanted to make this reasoning visible, teachable, and actionable rather than leaving users with a generic answer or a list of test names.

That is why I created Statistical Decision Tree: a bilingual English-Greek application that turns a research question into a transparent analysis plan, while showing the reasoning behind the recommendation.

What it does

Statistical Decision Tree guides a user through a short, six-step interview:

  1. research question and analytical goal;
  2. study design and measurement structure;
  3. outcome type and model components;
  4. sample size and assumptions;
  5. originally planned analysis; and
  6. an auditable decision report.

The report provides a primary recommendation, explains why it fits the design, identifies an alternative, audits the analysis originally planned by the user, and lists assumptions that must be checked before reporting results. It also turns the recommendation into practical next steps through SPSS and Jamovi menu paths and runnable R code. Users can copy the report, download an audit log, and print or save it as a PDF.

The built-in example uses a realistic education-research question: whether self-regulated learning mediates the relationship between achievement goals and social-emotional learning in a sample of 94 participants. The application recommends bootstrap mediation analysis with PROCESS Model 4 and explains why conventional linear regression does not directly estimate the indirect effect required by the hypothesis.

The interface is available in English and Greek. It does not require raw datasets, participant-level information, account creation, payment details, or API credentials for the core workflow.

How I built it

I built the project through an intentionally hybrid workflow that combines domain expertise, deterministic software logic, low-code interface design, and carefully scoped generative AI.

First, I used GPT-5.6 during the development process to refine the product concept, clarify the research-methods language, explore the interaction flow, and review how generative AI could be used responsibly in a statistical decision-support tool.

Next, I used Codex as the primary engineering agent. Codex helped translate the specification into a TypeScript application, implement the deterministic decision engine, encode the core decision rules, create the mediation example, add automated tests, debug the application, verify production builds, and document installation and testing. Codex also implemented a secure server-side GPT-5.6 explanation layer using the OpenAI Responses API and a strict JSON schema.

I used Lovable to design and refine the responsive bilingual user interface: the landing page, six-step interview, report view, statistical auditor, assumptions checklist, software tabs, and export controls. The Lovable code was exported and then merged back into the Codex-managed GitHub repository. When the final visual update was ready, Codex compared the Lovable export with the existing codebase and selectively merged the new homepage and image without losing the deterministic engine, tests, or GPT-5.6 integration.

The architecture has two deliberately separate layers:

  • A deterministic TypeScript engine selects the statistical method from explicit research-design rules. This makes the core result reproducible and auditable: the same inputs produce the same recommendation.
  • An optional GPT-5.6 explanation layer receives the already-selected recommendation and produces a concise explanation, missing information, cautions, and one practical next step. It is explicitly instructed not to choose, replace, or contradict the statistical method.

This separation is central to the project: AI adds communication and educational value without becoming the unaccountable source of a high-stakes methodological decision.

Challenges I faced

The main challenge was balancing usability with methodological responsibility. A tool that is too simple can recommend a test based on only one feature, such as the number of groups. A tool that is too detailed can overwhelm the people who most need guidance. The six-step structure was designed to collect the minimum information needed for a defensible first recommendation while making uncertainty explicit through an assumptions checklist and safe fallback guidance.

Another challenge was preserving scientific transparency while integrating GPT-5.6. I addressed this by keeping the core recommendation deterministic, using structured outputs for the AI layer, and ensuring that the API key is server-side only. The public demo intentionally keeps the deterministic experience fully usable without exposing a key or requiring paid API access. The optional GPT-5.6 integration and secure activation instructions are available in the public repository.

Finally, maintaining a bilingual interface required more than literal translation. Statistical terms, software guidance, report labels, and the user flow all needed to remain clear and consistent in both English and Greek.

What I learned

This project taught me that the strongest educational AI applications do not have to let a language model control every decision. A more trustworthy design can combine explicit, inspectable rules for the parts that require reproducibility with AI-generated explanation for the parts that benefit from clear, contextual communication.

I also learned how a real development workflow can move productively between ChatGPT, Codex, Lovable, GitHub, and a live deployment: from defining the idea and architecture, to implementing and testing the logic, to refining the interface, integrating changes safely, and documenting the work for others to run and evaluate.

What’s next

Future versions will expand the decision engine to cover multilevel, longitudinal, repeated-measures, survival, Bayesian, psychometric, and advanced causal models. I also plan to add power and sample-size guidance, methodological references and reporting standards, preregistration templates, saved analysis plans, visual decision paths, and user testing with postgraduate students and research-methods instructors.

Built With

  • ai
  • api
  • bilingual
  • codex
  • desktop
  • education
  • github
  • gpt-5.6
  • jamovi
  • lovable
  • low-code
  • openai
  • r
  • react
  • router
  • spss
  • start
  • tailwind
  • tanstack
  • typescript
  • vite
  • web
Share this project:

Updates