I work on applied AI and backend systems. Some notes here are about those systems; others are about the quieter parts of shipping software: naming a value, reading a repository, handling an error or keeping a build understandable.

The format can stay small. A useful note might contain the question, a minimal example, the condition under which the answer works, and a link to the source. It does not need to become a comprehensive guide to the entire subject.

Separate an example from a result

There is a difference between showing how a design could work and reporting what happened in a project. The project pages describe implementations that can be inspected in the linked repositories. General notes use examples to explain an idea.

When a project has no measured outcome yet, I want the page to say so. A confidence threshold is not an accuracy result, and an estimated saving is not a business impact measurement. Being clear about those distinctions makes the useful parts of the work easier to assess.

Leave room for corrections

A short note is allowed to have a narrow scope. If I learn that an example misses an important condition, I can update the page and explain the correction. The aim is to leave a better reference than the fragment I would otherwise have to rediscover.

The project case studies are a good place to start if you want the application context. The rest of the notebook is available through the homepage and the RSS feed.