← All work Case study · On-device LLM · Output validation

PrinciPAL: AI that isn't allowed to put words in your mouth

An iPhone app for principals. Dictate a quick note after a classroom visit; an on-device model structures it into a log entry and follow-up, and a validator rejects any AI rewrite that changes what actually happened.

Audience
School principals
Platform
iOS · SwiftUI · SwiftData
AI
Apple Foundation Models (on-device)
Status
Pilot build
Never include student names; say "a student". Reject any rewrite that adds a number, invents a name, or flips who did what.
The rules the app enforces. Every AI rewrite is checked against them before it is shown.

The problem

Principals make dozens of informal observations a week and lose track of the follow-ups. AI could help structure quick notes, but these are personnel records. An AI that "improves" a note by adding a detail, a number or a name creates a record of something that never happened.

What I built

  • Voice-first capture that turns a dictated note into a structured entry with follow-up reminders and nudges
  • Four AI rewrite styles for polishing notes, each with its own allowed amount of growth or shrinkage
  • Backup to Google Sheets using only the narrow drive.file scope, or to iCloud
  • A keyword-rule fallback when Apple Intelligence is unavailable, and the UI says so honestly

The AI design

Structured output with field-level rules

The model fills a typed schema (@Generable / @Guide), and the privacy rules live in the schema itself:

Schema guide
"Never include student names; say 'a student'."
CaptureParser.swift

A validator that treats every rewrite as unverified

Before any AI rewrite is shown, problem(with:) checks it against the original and rejects it if it:

  • Adds a number that wasn't in the note (it even parses "sixty-two" as 62)
  • Introduces a name not present in the original
  • Swaps who did what, e.g. "she did it" → "I did it"
  • Drifts in length beyond the chosen style's limit

Rejected rewrites are logged, the original is kept, and the principal can undo or try another style. Decoding is greedy (no sampling), so results are repeatable.

Then I tested the tester. I wrote a rubric and 52 graded cases to find what this validator misses. Read the evaluation →

Quote checking

The follow-up phrase must be copied word for word from the note, and code confirms that it actually appears there. The model can't paraphrase a commitment into something the principal never said.

How I verified it

  • The validator runs on every output, not just on examples during development
  • The v1 connector had 245 test assertions (47 end-to-end, 198 unit)
  • A fallback path is always available so a model refusal or outage never loses a note

v1 → v2: from cloud to on-device

v1 was a ChatGPT plugin backed by an 8-tool MCP connector I built on a Cloudflare Worker (get_dashboard, create_entry, schedule_meeting…), limited to verified district accounts. It came with an agent skill I wrote containing non-negotiable safeguards:

Agent skill · principal-tracker
"Never claim that an entry… was saved unless the corresponding write succeeded."

The skill also replaced student names with "Student A" and cited Connecticut's confidentiality law for evaluation records. For v2 I moved everything on-device so personnel notes never leave the phone at all.

What this shows for AI training roles

  • Defining exactly what makes a model output "unfaithful", then enforcing it in code
  • Writing agent skills with explicit, testable safety rules
  • Tool-use design (8-tool MCP server) and honest reporting of tool results
  • Letting privacy requirements drive architecture decisions