DHS Tutor: an exam tutor that can only quote the book

A general-purpose assistant will answer any dental hygiene question put to it, confidently, from training data the student cannot see and cannot check against the material they will actually be examined on.

Everything in DHS Tutor follows from them.

Each one protects the student’s ability to check an answer, or keeps the interface from competing with the page it is quoting.

Three surfaces, one book underneath all of them.

A developer handoff arrived for the student experience: 44 screens with a restyled counterpart, 15 that existed only as a new idea, and 56 admin screens that were never restyled at all. Each one was a flat image with a paragraph under it saying roughly what should go where.

That paragraph is the whole brief for the screen. It names the furniture: what to take out, what to put where, what to call it. It cannot say what the screen does before anything has been answered, when the clock runs out, when the question fails to load, at 375 pixels wide, or in the dark theme. Those are most of a screen, and none of them can be approved from a picture.

So I built the rest of it. The high-fidelity screens first, then a working prototype, then the front end itself: thirteen pages covering the reader, the tutor, quizzes, flashcards, questions, case studies, lectures and the account, over seven shared components and one stylesheet, running against a real API rather than clicking between frames. It was written in Claude Code, and one stylesheet carries two brands, the original purple and the Dental Hygiene Seminars green, without a second design.

The same handoff had a palette problem running through it: teal, purple, lime, indigo and red rotating across card bands, icon tiles, page heroes and even the A–D answer letters. It could not be argued with on taste, so I reviewed it screen by screen and wrote up what was there.

Twelve patterns came out of it, each severity-rated and listed against every screen it appeared on. Colour carries no meaning ran across 27 screens. Lime does too many jobs across 45. The quiz screen in the build section shows both at once: its answer letters run teal, purple, lime and indigo, so the lime C reads as the correct answer before the student has chosen. Elsewhere, red marked a section called “Your focus areas”, which is not an error condition. Colour that changes with position cannot signal state, and the palette was telling students things that were not true.

Patterns at that frequency are a system fault, not a set of instances. Patching them one at a time would have left the fault in place, so the audit became the brief for the system that replaced it.

The system is defined by what it refuses. Each hard rule answers a pattern the audit named.

Writing the rules down was not enough on its own. A written system describes components; it does not demonstrate them, and with one person designing and building, a specification and a stylesheet drift apart quietly. So the live page is generated from the source, and the generated regions are not hand-editable. Its samples cannot show behaviour the code does not have.

A system is only worth writing down if it survives the twenty-fifth screen. Twenty-five were designed and built, covering the dashboard, the chat, the reader, flashcards, quizzes, questions, case studies, lectures, search, notifications and the account. None of them introduced a new component. Six are below; the three the page has already walked through are left out.

The same rule runs through all of them. A flashcard carries its page and a way to open it. Missed quiz questions lead the review, each with its rationale and the page the answer is on. A case study holds its scenario at the top and explains every answer in place. Even the questions screen counts by chapter, because a chapter is the unit a page belongs to. Every page reference on every screen is a link back to the book. That is the product, repeated twenty-five times.

All twenty-five exist in both themes. Dark is where a token system is actually tested, because nothing is allowed to be a hard-coded colour. The same components hold, with no second layout. Only the token values change: the accent lifts so it still reads against near-black, and the score colours move from orange and red to amber and pink, which keep their distance from the background and from each other where the light-theme pair does not.

One surface does not invert. The book page stays white in both themes, because it is a reproduction of a printed page, the thing the student is being examined on. Inverting it would mean the page they check an answer against is not the page the examiner set.

I audited before I had a replacement: I named twelve faults across 103 screens before writing the rules that answer them. It worked, but in the wrong order. Several findings were the same missing rule observed five times, and drafting the system first would have found that faster.

A refusal is a feature: the hardest thing to design was not the answer, it was what happens when the book has nothing to say. Getting that wrong makes the product look broken; getting it right makes it trustworthy.

Restraint is an argument: the flat, white, single-accent system is not a taste preference. It is what makes a page reference and a highlighted passage the loudest things on the screen.