Building Quaestio: How I Specified an AI Product Schools Can Trust

In my last post I described a student who closed her laptop rather than ask an AI for feedback on her research. This is the sequel: how I turned that moment into a product, the decisions that shaped it, and what I learned as a product manager along the way.

If you haven't read Feedback Without Fear, the short version is this. Students doing independent research coursework need a critical reader, and the help they get depends on luck: which school, which supervisor, how much time that supervisor has. AI could level the field, but students are afraid to use it. They worry their work will be kept, that AI words will creep into it, and that using AI at all will look like cheating.

That post was about the why. This one is about the how.

Meet Quaestio

The product now has a name. Quaestio (say it KWY-stee-oh) was how medieval universities taught: by working through hard questions rather than handing out conclusions. That is exactly what the product does, so the tagline wrote itself: Questions, never answers.

Quaestio is a web application that a school authorises for its students. A student uploads a draft, checks a preview with their personal details already removed, and gets back a set of questions in the margin, each tied to a passage of their own text. They can accept a question, reject it with a reason, or ask to understand it better. They can't chat with it, and it can't write anything they could paste into their work. When the session ends, their draft is gone.

How the requirements took shape

I followed the same discipline I described in Spontaneous vs Deliberate: requirements are the product until every open question is closed. For Quaestio, that meant working outwards from the student's fear, not inwards from a feature list.

1. Principles first. Before any feature, I wrote five principles that every requirement had to respect: coach, never co-author; never train, never remember; the school owns the rules within a locked baseline; prove it; and independent of teachers. When two requirements conflicted later, the principles settled it.
2. Roles, with a "cannot do" column. The roles table lists what each user can do and, just as carefully, what they cannot. The school's coordinator can tighten the rules but never loosen them. School admins can track usage but never see a student's draft or feedback. Even the provider's own administrators cannot read student work, because none is stored.
3. Every requirement numbered and testable. "Students' work is safe" isn't a requirement. "No document, payload, feedback or drill-down text exists in storage, logs, error reports or analytics after a review" is, because a test can check it. Each trust claim in the specification maps to an automated test or an acceptance criterion.
4. A dated decision log. Each open question was closed with a dated decision, the reason, and the section it changed. That log turned out to be the most useful page in the document.
5. Then the architecture and the business case. Only once the requirements were stable did I work through a proposed architecture and a use case written for the people who will actually approve it: a school's data protection officer and IT security team.

The decisions that shaped it

A product is the sum of its decisions. These are the ones that changed Quaestio most, with the options I weighed. Some are technical, some are commercial, and the interesting ones are both.

Working with Claude

I want to be open about how this was made, because it's part of the story. I developed Quaestio in conversation with Claude, Anthropic's AI assistant, from the first rough idea to the final use case.

Two moments stood out. When I chose the name, Claude didn't just suggest options; it checked for clashes and told me that one of its own favourites was already taken in exactly my market. And when it wrote the use case, it wouldn't let the document claim more than the requirements commit to. The architecture sketch said "zero-retention arrangement" as if it were done; the use case says it must be confirmed in writing before launch, because that is the truth.

Seven things I learned

1. Trust is a requirement, and it needs someone to sign for it. The strongest trust signal turned out not to be technical at all. "Am I allowed to use this?" becomes "my school gave me this" the moment a school authorises the tool. Designing for the school as the buyer, and the student as the user, made the trust question much easier to answer.
2. My best pitch was the wrong product. My first idea was a small model running offline on the student's laptop: "turn your wifi off and nothing leaves your machine." It was a great line, but it didn't survive contact with the real problem. Asking students to install software from a developer they'd never heard of wouldn't win their trust, and feedback on a whole argument needs a far more capable model than a laptop can run. The final specification goes further and forbids the opposite mistake: Quaestio must never claim that documents don't leave the student's device. A precise promise beats a catchy one.
3. Write the "never" list first. The out-of-scope list and the master guardrails shaped Quaestio more than any feature did. Removing the chat box solved ghost-writing and prompt injection in one move. Saying no early is cheaper than building filters later.
4. Business rules are product features. Once reviews were part of a paid licence, a whole set of features followed: a readiness check so reviews aren't wasted, a rule that failed reviews don't count, a restore workflow, and a rule that non-payment never cuts students off automatically near a deadline. Pricing isn't something you bolt on after the design; it changes the design.
5. Use the cheapest model that does each job well. Model choice is a routing decision, not a single choice. The frontier model only does the work that needs it; the readiness check gets prose only, with graphs and equations replaced by markers; and some answers need no model at all. That's better for cost, speed and safety.
6. Define "good" in numbers before any code exists. Safe feedback that isn't useful is still a failed product. So the specification sets targets: at least 80% of questions rated relevant by teachers before each release, at least 60% accepted by students in the pilot, and zero document text in any log. If you can't measure good, you can't argue about it productively.
7. AI speeds up drafting; the judgement stays human. Working with Claude, I produced in days what would have taken me weeks as a business analyst. But the speed only helped because I treated every draft as a proposal, kept a dated decision log, and read every line. The skill that mattered most wasn't prompting. It was deciding.

What's next

The specification is complete except for one open item: the pilot school. Before launch, a few things still need to happen, and I'd rather say them plainly than pretend they're done: written confirmation of the model provider's no-training and zero-retention terms, an independent penetration test, and testing that the redaction catches names common in Singapore, which general-purpose tools often miss.

Then comes the part I'm most looking forward to: putting Quaestio in front of real students, measuring whether its questions actually help, and changing it based on what they tell us. Every review gives students three buttons, and every press is a signal about which questions earn their place.