“The data changed.”
So the workflow had to.

A vague request.
A very different problem.

The request was brief: the data had changed, and we needed to fix it.

Talking with a power user revealed what that meant. The initial school dataset had anonymized names and no supplied primary keys. A later dataset contained a different population of students. A proposal based on the earlier file could no longer stand in for the new roster.

The team needed a way to create a revised tutoring proposal while retaining the context behind the original one. I designed the scenario-mutation userflow and worked with Claude to implement it.

Give the change
a clear decision structure.

A replacement roster can change the resources needed to reach a target. It can also change what outcome the existing resources could support.

Keep the target, or keep the resource limits?

I brought that choice into the flow. Operators can preserve the target and examine the revised tutoring requirements, preserve the resource caps and examine the projected outcome, or generate both alternatives for comparison.

The earlier scenario remains available with its source upload and calculation records. The new population produces a new scenario, giving the team a reference point for the conversation.

Review first.
Present deliberately.

Generating a new result does not immediately make it the school-facing plan. That is a separate action after the operator has reviewed the replacement.

1. Choose the replacement population.Use the complete updated enrollment file as the source for the new scenario.
2. Choose what to preserve.Keep the target, the resource limits, or generate both alternatives.
3. Review the implications.Inspect the revised selection, tutoring hours, and projected academic-growth score.
4. Present the revised plan.Deliberately update the scenario shown to the school, with the earlier result retained.

A useful first step,
with an explicit boundary.

This was a short-term solution to an immediate operational problem. The implemented Supersede flow recalculates a scenario from a complete replacement roster.

An incremental Update flow—keeping previously selected students and adding support around them—is separate, planned work. I would approach ongoing roster revisions differently with more time to develop that lifecycle.

There is also a calculation boundary worth making visible. Selection, tutoring requirements, and projected D2A are refreshed from the replacement file; some current-state and overall-rating values still reference the earlier population. The interface discloses that limitation.

The team could
move the conversation forward.

Sales and post-sales were able to show revised student lists to schools. The result addressed the immediate need while retaining the earlier scenario for context.

This is the kind of work I want to keep doing: uncover the decisions inside an underspecified request, give them a clear experience, and stay close to the implementation until people can use it.