Work samples

Written by a person. Last read by a person on 2026-09-07, 21 days ago.

These are deliverables, not descriptions of deliverables. Each set is the kind of document the job actually produces, written to be used rather than to be admired.

Every page states who it is for before it starts, records when a person last read it, and names which of its claims a build checks rather than asserting they are true.

Start here

Technical curriculum Lab (interactive) 1 document

For a technical enablement, curriculum or developer-education hire.

One topic chosen by a needs analysis and a ranked inventory of 1,830 pages, and the hands-on lab it produced: an explorable model of a Claude workload that a rep can use on a call and an engineer can read as code, with every figure traced to its source.

End-to-End AI Enablement 16 documents

Start here if you are deciding whether someone can fund, buy, scale and defend a program rather than only build one.

A strategy, an executive deck, a project plan, a statement of work, budget and vendor analysis, a first 90 days, a literature review, and the objections a sponsor will actually raise.

Retrieval-augmented archive Live demo

For a role building or evaluating retrieval-augmented generation, not just talking about it.

A real RAG system over sixteen public-domain magazine issues: hybrid retrieval, grounded answers with citations, honest refusal, and the rate limiting and health-gated deploys that keep a small, self-funded demo cheap and always up.

Developer documentation 4 documents

For an engineering or developer relations hire.

One API workflow documented end to end: a quickstart, a reference, retry behavior, and troubleshooting that starts from what the reader can see rather than from what went wrong.

Support content

For a support or education role.

Help written from the reader's situation. It opens by asking which problem you have, because someone who is stuck cannot yet name the thing they need.

Concept explanations

For anyone assessing teaching, not just writing.

The same idea explained more than one way, because a reader who learned it elsewhere needs the words lined up with what they already know.

Accessibility statement

For a team with a procurement or compliance question.

What this site does against WCAG 2.1 AA, separating the claims a build checks from the ones a person is vouching for.

Published rubrics 24 documents

For anyone who wants to check the work rather than take it on trust.

The rubrics the set is graded against, published so a claim can be argued with.

How this set stays true

For anyone who has watched documentation rot.

The argument behind the machinery. Facts live in one place, prose references them, and the build fails when a page repeats a value it should have looked up.