ReasonFirst

ReasonFirst makes student reasoning visible and assessable, so equally polished AI-assisted work can earn different marks based on who directed, challenged, and verified the process.

Comment

Ho ridotto sensibilmente il testo e integrato gli elementi reali, mantenendo un tono personale ma professionale.

Inspiration

ReasonFirst began with a practical discussion about my graduate course in Quantitative Methods for Finance.

I spoke with two colleagues, one of whom will teach part of the course with me. Both were sceptical about allowing students to use generative AI to solve course exercises. Their concern was reasonable: if instructors cannot observe how much of the reasoning has been delegated, AI risks losing its educational value. A polished final notebook does not reveal whether the student understood the problem or simply asked the model to solve it.

This discussion changed the question I was asking. Instead of focusing only on the final result, I began to focus on the intellectual contribution that students make through their prompts.

From this starting point, several ideas developed in sequence.

First, a complex exercise should be decomposed into a bounded number of ordered analytical stages. This prevents the student from requesting the entire solution in a single prompt and requires them to structure the problem before asking for assistance.

Second, prompts should be semi-structured. Each prompt contains a fixed part written by the instructor and a variable part written by the student. The fixed instructions constrain the AI so that it provides neither more nor less assistance than the stage allows. The variable part makes the student's reasoning visible.

Third, prompt quality can be assessed through a transparent rubric with distinct criteria and predetermined weights.

ReasonFirst emerged from this process.

The opportunity to turn the method into a working product arrived unexpectedly, through an email inviting me to participate in the OpenAI Build Week.

What it does

ReasonFirst is an educational workflow for using AI without making the student a passive recipient of generated solutions.

Every exercise begins with an immutable Case Sheet defining the variables, formulas, assumptions, parameters, required outputs, and mandatory controls. The AI may assist with the case, but it cannot silently redefine it.

The exercise is then decomposed into a sequence of analytical and computational stages. For each stage, the student interacts with the AI through a semi-structured prompt:

complete prompt
  = fixed instructor opening
  + variable student contribution
  + fixed instructor instructions

The fixed sections define the permitted scope of assistance. The variable section contains the student's own interpretation, proposed reasoning, computational plan, doubt, or correction.

ReasonFirst distinguishes three interaction regimes:

  • Regime A — Analysis and model reasoning: the student proposes the theoretical route; the AI may verify and organize it, but cannot write code.
  • Regime B — Computational translation: the AI translates one previously validated stage into candidate Markdown and Python cells.
  • Regime C — Critical verification: the student challenges a result or proposes a correction, and the AI must explicitly accept or reject the criticism.

The model's response remains a proposal until the student decides how it should be used.

At the end, ReasonFirst produces two linked artifacts:

  1. a clean executable Jupyter Notebook;
  2. an interaction trace containing prompts, student contributions, model responses, decisions, and corrections.

The final assessment therefore considers both the technical product and the intellectual process that produced it.

The demonstration compares two students working on the same quantitative-finance case. The validated technical product is held constant, but the delegation-dominant process receives 50/100, while the student-directed process receives 78/100.

ReasonFirst is not an AI detector. It makes student responsibility visible while the work is taking place.

How I built it

The pedagogical method existed before the Build Week and was developed for my university teaching. During the event, I transformed it into a runnable application.

The project is a lightweight Python web application. It manages:

  • immutable Case Sheet constraints;
  • fixed and variable prompt components;
  • response provenance;
  • structured JSON outputs;
  • deterministic assessment;
  • trusted computational execution;
  • notebook and interaction-trace exports.

In live mode, GPT-5.6 supports theoretical reasoning, computational translation, and critical verification through the OpenAI Responses API.

Model-generated Python is never executed automatically. GPT-5.6 returns candidate cells for review, while the prototype executes only trusted application code.

The application also provides a credential-free deterministic mode, allowing judges to complete the demonstration without an API key. Deterministic responses are clearly labelled and are never presented as live model calls.

Codex helped me transform the methodological design into a working product. I used it to inspect the larger teaching repository, consolidate requirements, implement the interaction engine and API adapter, develop tests, refine the interface, and prepare the demonstration.

The central pedagogical decisions remained mine: the staged decomposition, the A/B/C regimes, the immutable Case Sheet, the fixed-versus-variable prompt architecture, and the process-based assessment rubric.

The current test suite contains 62 passing automated tests.

Challenges

The main challenge was avoiding merely superficial restrictions.

A system that asks the student one preliminary question and then generates the complete solution may appear interactive, but it does not preserve genuine intellectual responsibility.

The entire workflow therefore had to be structured so that each AI intervention corresponded to:

  • a precise stage of the exercise;
  • a declared type of assistance;
  • an identifiable student contribution;
  • an explicit student decision.

A second challenge was making the process assessable. A raw chat transcript is not sufficient. The system had to distinguish clearly between instructor instructions, student reasoning, and model-generated content, and then connect them to predetermined assessment criteria.

A third challenge was methodological complexity. As the framework became more abstract and structured, aligning fully with my colleagues would have required more time than was available. I therefore developed the Build Week implementation independently, while continuing to discuss its educational purpose with them.

What I learned

The most important lesson is that educational AI is not primarily a detection problem. It is an interaction-design problem.

The relevant question is not simply whether a student used AI, but which intellectual responsibilities remained with the student.

I also learned that prompts can become assessment evidence. When their fixed and variable components are clearly separated, prompts can simultaneously constrain AI assistance and reveal the quality of the student's reasoning.

Finally, the project confirmed the value of combining human methodological design with AI-assisted software development. Codex accelerated implementation, while GPT-5.6 operates within a pedagogical structure that prevents it from replacing the student.

What's next

I have already piloted the method in a laboratory setting. The next step is to test it with students when the course begins in October 2026.

Further development will include:

  • a teacher-facing Case Sheet and prompt-sequence builder;
  • configurable assessment rubrics;
  • complete multi-stage notebook workflows;
  • LMS integration;
  • instructor dashboards;
  • a controlled evaluation of delegation-oriented and student-directed AI use.

The objective is not to exclude AI from education. It is to make AI-supported learning rigorous, attributable, and genuinely educational.

Built With

Share this project:

Updates