How this is built
Every tool on this site runs in production and handles files from the public. This page describes how the tools are built and how your data is handled. The last two sections cover T3AM, a separate platform.
Your data
Files are processed per-request and held only in memory for the seconds it takes to build your result. It is not written to storage, used to train models, or sold. The AI vendor (Anthropic) processes each request under its API terms, which exclude training on API data. When your session ends, your data is gone. That also means I cannot recover your result for you, so download it before you close the tab.
Uncertainty flags
The models are told to flag what they are unsure about instead of guessing. Blurry cells get a CHECK flag. Ambiguous list merges are kept separate and marked “possible duplicate.” If a meeting transcript does not say who took a task, the owner field comes back empty and flagged. On the document Q&A tool, citations are verbatim source quotes extracted by Anthropic's citation grounding, so a citation cannot be made up.
You check the result
No result is final until you have seen it. Every table is editable in place, and removals are listed for review. The “needs more work” button takes plain English, such as “rows 2 and 5 are different people,” and reports back what changed, or says that nothing needed to. You decide whether the result is right before you download it.
Cost and abuse limits
Every API route is metered: per-IP rate limits (20 jobs an hour), per-job size caps (8 images, 6 documents, ~50k characters of list, ~2 hours of transcript), and a correction-round cap per job. The model and its spend are pinned server-side, with no client-side model access. Limits are stated on each tool before you reach them, and reaching one routes you to me.
Failure handling
I do not trust model output. Every response is validated against a strict schema before it reaches you, and malformed output shows an error instead of wrong data. When the source material is poor, such as an unreadable image or garbled auto-captions, the tools say so in their notes.
What may reach an AI prompt
T3AM, a youth-sports team platform at t3am.app, sorts its data into three tiers. Tier 1 is public information, such as standings and final scores that leagues already post. Tier 2 belongs to one team, such as its schedule, roster, and practice plans. The T3AM assistant only sees tier 2 data that the person asking could already read on screen. Tier 3 never enters an AI prompt in any feature. It covers contact details, medical and form answers, fee balances and payment records, private parent and coach messages, character moments, and credential records.
The tier is set on the data model itself, so a field added later cannot expose private data to a prompt. Character moments stay out of prompts even when the person asking can see them, so the assistant cannot be asked to rank one child against another.
The AI systems I built at my day job follow a data classification as well. It decides what may enter a prompt, it was set before any feature was built, and mail is excluded from what the operations dashboard's model can see.
How T3AM is checked
Every change goes through a pull request, and CI blocks the merge unless type check, lint, and the full test suite pass. Tests fail the build when the shared library imports a domain module, or when two parts of the system that must stay separate share a foreign key.
A harness replays published games through the scoring engine and compares the output to the official box scores. It covers 1,400 NHL games, 300 MLB, 300 NCAA football, and 250 Premier League, plus rulebook cases for volleyball. It found five bugs across six sports that the unit tests had passed.
Deliberately small
These tools are metered for small jobs on purpose. Vector indexes for large document sets, queues and batch processing for volume, and direct audio transcription are scoped and priced, and get built when a real workload needs them. A job larger than the meters allow can be scoped as a project: hello@steverolfe.co.
What it runs on
Next.js 15 on Vercel serverless. Anthropic Claude for all model work, server-side only and version pinned. Zod schema validation. CI/CD via GitHub Actions - every push to main builds, typechecks, and deploys in about two minutes.
Questions about any of this: hello@steverolfe.co