AI that
earns its
place.

Students writing long 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 draft will be kept or used to train a model, and that AI-written words will creep in and look like cheating.

Quaestio is a web app that schools authorise for their students. A student uploads a draft, checks a preview with their personal details already removed, and gets back questions in the margin, each tied to a passage of their own text. They can accept, reject or ask to understand a question, but there is no chat box and the system cannot write anything they could paste in. When the session ends, the draft is gone. Its tagline: Questions, never answers. I wrote the full product specification and am now developing Quaestio with a channel partner.

• Specification first: five product principles, more than 230 numbered, testable requirements, 28 acceptance criteria and a dated decision log, completed before any code.
• Guardrails enforced by structure: nine master guardrails no console can switch off. No free-text channel to the model, a fixed output schema, and every question checked by a rule validator and a second model before it is shown. Any failure withholds output.
• Privacy by architecture: drafts are processed in memory in isolated workers and never stored or used for training. Identity is redacted before any model call, the student confirms what is sent, and schools see who, when and where, never what.
• Model routing and unit economics: a frontier model for the main review and smaller models for readiness and safety checks, with per-student licensing designed around a costed review. Singapore hosting at launch.

Feedback Without Fear · Building Quaestio · What Does a Question Cost? · Who Taught It What to Ask?

University students short on time and money often don't know what to cook with what they already have. Recipe apps are built for browsing, not quick decisions. A general-purpose chatbot can invent recipes that don't work with a student's limited equipment, such as a rice cooker, an air fryer and a blender.

MealPartner runs on WhatsApp, an app students already use. A short guided chat asks what they feel like eating and what they have on hand. It then suggests the single best-fitting idea from a curated recipe library, with prep time, a budget note and a link to a video recipe. If nothing fits, it says so honestly and logs the request so the library grows where demand is.

• Small model, tightly limited: the local 4B LLM never writes recipe content or links. Replies are assembled in code from curated content and templates. The model only handles schema-constrained fallbacks such as intent detection and input normalisation, which limits both hallucination and prompt-injection risk.
• Hybrid retrieval with confidence tiers: hard filters run in code, then a weighted score blends tag matches with embedding similarity. Strong matches are shown, partial matches come with a note on what differs, and weak matches are never shown.
• Conversation state machine: intent is detected before onboarding, users can answer several questions in one message, and free text is matched in stages: exact, then fuzzy, then a constrained LLM.
• Closed feedback loop and swap-ready design: unmet requests go into a ranked queue for the recipe curator, and silence counts as failure. The model and messaging layers are abstracted, so it can move to a hosted LLM or the official WhatsApp API as it grows from one user to 100+.

Consultants, advisors and analysts win business through visible expertise. Staying visible means tracking industry and regulatory news every week and turning it into articles and posts, which takes hours they rarely have. Generic AI writing tools fill the gap with bland content that can misstate facts, a real risk in regulated fields such as financial services.

A team of specialised AI roles runs the weekly campaign. They watch the user's domain, suggest topics worth having a view on, and draft from the user's own opinion, not a generic one. The user picks the topic and states their view, the system writes a long-form article and adapts it into shorter formats, and every piece is fact-checked and compliance-checked before the user approves a publish-ready pack. The user stays the author, and the system never posts on their behalf.

• Five-layer agent pipeline: Sense (regulatory and research watch), Decide (editor-in-chief), Produce (writer, repurposer, visual designer), Assure (fact and compliance check) and Package. One orchestrator is the only component that calls the roles.
• Mandatory human checkpoints: the user approves the topic and their view up front, and the final output at the end. There is no auto-approve and no skip flag.
• Citation-enforced output: every factual claim links to a stored source and excerpt. Uncited claims cannot be approved.
• Built for audit: all model calls go through one logged client, prompts are versioned per role, and data contracts are typed. Quality is measured against golden-dataset evals. Hard rules (no auto-posting, no scraping of login-walled sites, robots.txt respected) are enforced by tests.

Inboxes fill with newsletters, promotions and notifications faster than people can sort them. Rule-based filters are tedious to set up and break easily. Handing an AI agent free access to your email is risky, because one wrong action could delete or bury something important.

Users describe in plain English how they want their inbox tidied. An AI agent reviews recent emails and proposes what to archive, label or keep, as a preview. Nothing changes in Gmail until the user approves. Firm safety rules (never delete, protect emails from real people, limit how many emails change at once) are enforced by the system whatever the AI suggests.

• Defence in depth: the LLM returns structured proposals, which the server re-checks against fixed guardrails. Those guardrails cannot be removed or disabled, even through crafted API calls.
• Hallucination-resistant references: the model sees a numbered catalogue of email metadata, never raw Gmail IDs, so a misquoted ID cannot misfire. Every rejected proposal is reported with a reason.
• Conservative actions: the apply step only adds labels, and archive and delete stay preview-only. Failures are reported per email without stopping the batch.
• Engineering practice: Google OAuth 2.0 sign-in, a configuration per user, and a partial-update REST API. Unit tests mock the Gmail and LLM calls, and static checks keep the front end and back end consistent.