Work samples

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

Leadership artifacts 15 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.

The rest of it

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 21 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.