From school data
to a tutoring plan.

A score is only the beginning.

A school’s accountability data can describe where it stands. The next question is harder: which students could benefit from tutoring, how much support would the plan require, and what outcome does the model project?

I created Papaya’s accountability platform around that decision. It takes assessment data and turns it into scenarios that the team can compare and use to propose a tutoring roster. Papaya now uses the product in its tutoring business.

The work connected product discovery, the user experience, and the engineering of the recommendation. A calculation becomes useful when someone can understand its assumptions, inspect its implications, and act on the result.

What does this school need to decide—and what would make that decision easier?

Designing the decision,
from input to action.

The experience brings a sequence of technical steps into one workflow. Each step has a clear job, and its output becomes context for the next decision.

1. Understand the school’s data.Import assessment records, validate their structure, and establish the school context.
2. Make the goal explicit.Set an academic-growth target and the resource limits the proposed intervention must respect.
3. Compare possible plans.Generate a proposed roster or evaluate one the team has already selected.
4. Move from the model to the work.Inspect the recommendation and export an actionable student list.

Giving people the option to evaluate their own roster matters. The operator can bring school knowledge and practical constraints to the decision, then use the model to examine the implications.

Three perspectives, kept distinct.

The comparison separates current performance, a no-intervention projection, and the modeled intervention. The no-intervention projection assumes students retain their present performance levels on their next assessments. The intervention scenario models specified improvements.

Inside the recommendation.

The current optimization engine uses a deterministic heuristic. It evaluates different candidate orderings, removes unnecessary selections, and tests bounded swaps to improve a proposed plan.

It seeks a target-reaching result with fewer tutoring hours. When it cannot find one within the limits, it returns the strongest result it finds. That distinction is part of communicating the model honestly: a heuristic does not prove that a solution is globally optimal, or that no better solution exists.

The useful output is more than a score. It includes the proposed student–subject interventions, estimated tutoring requirements, and the context needed to assess the recommendation.

The result needs a history.

Source uploads, conflicting records, assumptions, and concurrent calculations can all affect what a result means. The implementation ties runs to a defined source, checks conflicts, retains policy context, and preserves completed scenarios.

That became particularly important when a school supplied a replacement roster. I designed a separate workflow for calculating and reviewing a revised plan while retaining the earlier scenario.

Read the scenario-mutation case →

The operational value is concrete: the team can move from school data to a reviewable tutoring proposal. Quantifying forecast accuracy and the quality of the allocations remains work to evaluate explicitly.

The next question is
how to prove it.

I plan to develop the platform’s optimization problem into my engineering thesis, focused on operations research. The research question and methodology are still being defined.

One possible direction is comparing the current heuristic with an exact optimization formulation on controlled datasets. Another is exploring how uncertainty in the assumptions changes the recommended allocation.

The product gives that research a practical foundation: an existing decision, explicit constraints, and people who need to understand the trade-offs. The thesis will be a way to investigate those decisions rigorously.