The Lab

Where the code is the deliverable

Everywhere else on this site, code is a means: the pages, the demos, the documents. Here it is the thing itself. Three artifacts, all MIT licensed, all running in the open — because a designer claiming to ship code should hand you some rather than describe the experience of having done so.

Where the line sits. I ship the front-end of what I design, in the PR under my name, with senior engineers reviewing. I do not claim the backend or complex state architecture, and nothing here pretends otherwise: these are pure functions and the interfaces around them. That is the honest boundary, and it is the same one I give on the technical screen.

Why a lab at all

A principle with no failing state is a preference

The eight patterns in the pattern library came out of production work, and for years they lived where design principles usually live: in slides, in review comments, in my head. Reasonable people agreed with all of them and then shipped the naked confidence score anyway — because a principle you can nod at costs nothing to ignore.

Written as code, the same rules acquire a failing state. decide() reports review-without-reasons as a violation rather than a suggestion. calibrate() returns insufficient-data instead of a flattering number when the sample is thin. trustlint refuses to score truthfulness at all, and says why in its own output.

That is what The Lab is for: taking judgements I keep making in review and giving them somewhere to fail, so they can run without me in the room.