What gets written here
Build notes
How a piece of the product actually works — the graph model, the settlement path, why guest runs return samples. Written when the thing ships rather than when it is planned, which is why there are fewer of them than there would otherwise be.
Post-mortems
When something breaks in a way that cost somebody their work or their credits: what happened, why the guard that should have caught it did not, and what changed as a result. Named systems, no named individuals.
Craft
Continuity across shots, prompt structure that survives revision, what the models are currently bad at. Findings from real work, not tips.
Company
Rarely. Hiring, a change of direction, a decision that affects what you can rely on. Not funding theatre and not milestone announcements.
Editorial standards
Worth stating, because most company blogs in this field do not hold to them.
- Written by whoever did it
- Posts carry the name of the person who did the work. Nothing here is ghostwritten by marketing and attributed to an engineer.
- No AI-written posts
- We build AI tooling. That is exactly why a post claiming a person's judgement should have one behind it.
- Examples are real
- Screenshots come from real projects. Generated media is labelled as generated, here as in the product.
- Corrections stay visible
- When a post is wrong it gets a correction at the top, not a silent edit. The wrong version is part of the record.
- No competitor takedowns
- Technical comparison with numbers and methodology, yes. A post whose purpose is to make somebody else look bad, no.
While the archive fills up
The most useful writing about this product today is the documentation, and it is kept current with what actually ships rather than with what was planned. If you want to know how the canvas resolves a run, or what the API does under load, that is where it is written down — and it is written to the same standard as anything that would appear here.