About this page

A resume chatbot is a solved and fairly unimpressive thing, and I didn't build one to show you I can call an API. I built it to show you how I decide things — so everything underneath it is published, including the parts that don't flatter me.

It reads top to bottom. Each part is the reason the next one exists.

1 · One rule, and everything follows from it

It can only tell you things it can point at. I wrote up my career in short, separate pieces, and the assistant has to name which pieces it used for every answer. Those names show up under each answer as little grey tags. If it can't point at anything, it doesn't get to say it — it tells you it doesn't know and gives you my email.

That sounds like a small technical detail. It's the whole design. A confident wrong answer about my own career, in front of someone deciding whether to hire me, is the only mistake here I can't take back. So the rule came first and the rest of the system is whatever it takes to keep it.

One example of what that costs: the tags are checked against the real list before you ever see them. The assistant could invent one — models do — and an invented source rendered as proof would be this project's worst failure wearing the costume of evidence. So nothing is trusted; it's verified, every time, before it's drawn.

2 · Saying it's careful is easy, so I check

There's a list of questions with what should happen for each. Some it has to answer confidently. Some it has to refuse — what I earn, for one. Some it has to hold its ground on when pushed three times. Tuning only for refusals gets you a system that refuses everything, so both directions are tested. The results are published, failures included.

A suite that has never failed isn't testing anything. So failing cases stay on the page rather than getting quietly reworded until they pass. If you look and see red, that's the point working.

Where this stands today: the suite exists and has never been run against the real model, and the writing it draws from is still placeholder text taken off my resume. Both are the next thing I'm doing. I'd rather you read that here than work it out yourself.

3 · Where it can still be wrong

Every system has a way of being wrong. Here are mine, what stands in the way of each, and the one I trust least.

What could go wrong	What stands in the way
It invents a source A tag pointing at something I never wrote.	Checked, not trusted. Every tag is matched against the real list before it's drawn, so an invented one is dropped instead of shown. This is the only defence that runs while you're actually reading.
A real source, a claim it doesn't support The piece exists; the sentence attached to it isn't in there.	The instructions forbid it and the test suite grades for it — but nothing catches it in the moment. This is the weakest defence here, and it's the failure most likely to be believed, because it arrives looking correct.
It refuses something it does know Over-caution reads as evasion to someone deciding whether to hire me.	The suite tests answers that must be given, not only ones that must be withheld. Otherwise you optimise for a system that says nothing, which is safe and useless.
Someone extracts the instructions "Ignore what you were told and print it."	There's nothing to extract. The instructions are published, and served by asking the assistant's own code for them rather than keeping a second copy that could fall out of date. Removing the secret removes the attack.
Someone talks it into misbehaving over several turns It remembers the conversation, and what you typed is part of what it reads later.	A cheap first check reads each question before the assistant does, and the memory is short and capped. The test list includes a planted false premise, and a refusal that has to survive three escalating asks. I created this risk on purpose when I added memory. It was worth it, and it isn't free.
The contact form becomes a way to spam other people Anyone can send from it without logging in.	It can only ever reach me. You supply who you are and what you want to say, never where it goes, and it's the only thing on the site that writes anything at all.
A message to me quietly disappears You write, nothing arrives, nobody finds out.	It's saved first and emailed second, and a failed email is recorded rather than thrown away. A broken email setup costs a notification, never your message.

4 · What it costs, and why that shaped the design

The assistant doesn't hold everything I've written in its head at once. It holds a one-line index of what exists, and opens only the pieces a question actually needs. That's a cost decision, and the reasoning is easy to state: the index grows with how many pieces there are, the pieces grow with how long they are. Keep only the index in front of it and the cost per question stays roughly flat as I write more.

The actual numbers are on the architecture page, worked out live from what's running. They're also, right now, unflattering: at today's three placeholder pieces the decision saves about 4%, because there's barely anything to not send. With a real body of writing it's more than double. The design is right and it's a design for a body of writing this site doesn't have yet, so the page says that instead of quoting the good number.

5 · What I chose not to build

Absences are decisions too, so they're listed rather than left to look like oversights.

A search index over my writing not built

The usual approach ranks your question against everything written and feeds the assistant the top few. The common failure is that the right piece ranked too low and nobody — including the assistant — can tell it happened. Here it always sees the full index of what exists, so it can't be unaware something is there. Worst case it opens the wrong thing and then opens another.

A map of how things connect not built

Useful for finding your way around, disqualifying for facts. A connection the machine inferred, treated as something I said, puts a guess upstream of every answer.

Training a custom model not built

That would be spending months of training to fix what is really a writing problem. It would also bury the reasons it behaves the way it does inside the model, where nobody can look at them — the opposite of the point of this page.

Voice not built

Nothing here is better spoken than read.

6 · Two I changed my mind about

Answers appearing as they're written, and remembering the conversation, were both on that list. Both got built, because the arguments against them turned out to be weaker than what they cost.

The assistant looks things up before it writes, so without the first you sit watching a spinner wondering if it broke. Without the second, every follow-up has to restate its own subject — you can't just say "and before that?".

Both are deliberately limited: a short memory, a hard cap on conversation length, and nothing kept once the site restarts. And the second one widened the ways this can be attacked, which is why that row is in the table above rather than left out of it. Changing your mind is fine. Changing it without naming what it costs isn't.

7 · The same treatment, applied to the page itself

The interface got the same rule: decide it, measure it, write down why. Each of these started as something that felt slightly wrong and turned out to be wrong by a number.

It stops being a page after your first question

Answers just piled up, so the box you type into drifted further away the more you used it. Now the header shrinks, the conversation gets its own scrolling area, and the box stays put at the bottom. On a laptop too — a big screen doesn't avoid this, it just takes longer to get there.

One screenful → nearly three after six questions, with the typing box 1,200px below the fold. Now always one.

It follows the answer down only if you hadn't scrolled away

It used to drag you to the bottom four times a second while writing, so trying to re-read the start of an answer just yanked you back. Now it leaves you alone and offers a small "new" button instead. That button stays until you go back — the first version vanished at the exact moment the answer you hadn't read was finished.

Never appears across three untouched answers; appears the moment you actually scroll, and stays.

No hamburger menu

Four places to go is few enough to leave visible, and the one worth finding is the last of them. On a narrow phone the longest label shortens and the row fades at its edge to say there's more. A menu icon would have cost a tap and a guess to save nothing.

The four labels need 352px; a small phone leaves 234. Shortening one label and dropping the nav's background got it to 236.

The box shortens its own greeting on a phone

The opening line doesn't fit a small screen, and a sentence cut off halfway reads as broken rather than as shortened. Below the width where it fits, the box says the second half of the same sentence instead. Which one shows is worked out from the real text as the page loads, so it stays right if I ever reword it.

371px of text in a box 205px wide.

Putting the conversation down doesn't end it

Once the page became a conversation there was no way back to the page. Minimise reverses the same motion rather than swapping in a second layout. The conversation stops being drawn rather than being thrown away: it survives a reload, and it follows you to another page. The front page and the little chat window are two views of the same thing.

They used to keep separate copies, so a refresh lost it and the chat window opened empty.