learning is a separate deliverable

while building truevitamin, i built elvyn, a system that uses ai to turn a health profile into a nutrition and supplement plan. it had separate stages for interpreting the profile, retrieving research, generating the plan, and checking the output.

i also built meal-photo analysis and supplement-label recognition. the work spread across several repositories. i built workbench to start and sync them as one local development environment.

there was a lot to learn in that work. i was interested in how the system was built as well as what someone would use it for. a project like that gives me plenty of reasons to keep exploring.

learning by building is part of why i take these projects on. an experiment can be worth the time even if none of its code belongs in the release.

an interesting technical question can also become a requirement for shipping without an explicit decision. then a release depends on satisfying my curiosity about something the person using the product may never encounter.

i'd give the exploration its own purpose: what i want to understand and the smallest thing i need to build to understand it. separately, i'd name what a person should be able to do with the release. the same work might serve both purposes. i want to be able to explain when it does.

with truevitamin, research retrieval could be an experiment of its own. i could inspect which papers came back for a particular question and whether they supported the proposed answer. connecting that experiment to a person's plan would require separate checks on the information supplied and the output they receive.