Starting Point
On the evening of 20 March 2026, during an aromatherapy class, we were working through essential oil dilution percentages. The difficulty was not the calculation itself. It was the process around it.
Checking safe dermal limits required flipping through reference books. Values were scattered. Consistency depended on memory. The friction was small, but repeated.
Most useful systems are not built because something is broken. They are built because something is slow.
Observation, 20 March 2026That was enough. The friction was small, but repeated. Repeated friction is not a minor inconvenience — it is a design problem.
The working skeleton
The first version began as an experiment. Using Claude, I constructed a simple calculator — input volume, define oils, calculate drops. At this stage, the challenge was not logic, but data.
Although the model attempted to recall safety limits, the results were inconsistent. JSON-based references failed to stabilise the outputs. So the approach changed: instead of relying on internal recall, the system was anchored to source material — the textbook (PDF). A constraint was introduced: limited oils, explicit disclaimer. Accuracy was no longer assumed. It was bounded.
- Basic calculator: volume input, oil selection, drops output
- AI recall for safety limits — inconsistent, later replaced
- Anchored to PDF textbook as primary reference
- Scope constrained to a defined oil list
- Explicit disclaimer added — accuracy bounded, not assumed
Recognition over recall
On 21 March, the focus shifted from function to clarity. Each oil was no longer just a name. The question became: how does a person actually think about these things?
Latin names were added. Visual markers — simple emojis — were introduced to indicate plant type: flower, leaf, fruit. This was not aesthetic. It was recognition. A system becomes easier to use when it reflects how people already think.
- Latin names added alongside common names
- Plant-type visual markers introduced (flower, leaf, fruit)
- Improved legibility — oils easier to scan and identify
- No logic changes — structure was the work
Boundaries that respond
On 24 March, a classmate tested the tool. Two responses stood out: "Safety limit exceeded" and "Oil not in database."
These were not features. They were boundaries. And they worked. The system was no longer just calculating — it was responding. A system that communicates its own limits is more trustworthy than one that silently produces an answer.
- Safety limit exceeded — boundary message surfaced clearly
- Oil not in database — explicit out-of-scope response
- First real-user test conducted with a classmate
- System behaviour validated against actual usage patterns
When names are ambiguous
On 27 March, a flaw appeared. Lemongrass was interpreted as Citrus limon. The result: incorrect dilution percentage. This was not a UI issue. It was a mapping problem. Names, without structure, are ambiguous.
To resolve this, NotebookLM was used — extracting structured data from a second primary textbook. The system expanded. More importantly, it became more precise. The lesson was not about data volume. It was about data clarity.
- Lemongrass → Citrus limon mapping error identified
- NotebookLM used to extract structured data from second textbook
- Oil taxonomy restructured — names anchored to Latin identifiers
- Database expanded with greater precision, not just breadth
A name is not an identifier. A Latin binomial is. Ambiguity at the data layer propagates into every calculation downstream.
Refinement through friction
On 28 March, further adjustments were made: a feedback comment box was introduced, and visual refinements were attempted — including background and logo handling.
Not all of these were successful. But they revealed something else: a system is not finished when it works. It evolves through friction. The feedback mechanism was not about collecting data. It was about keeping the loop open.
- Feedback comment box added to each output
- Visual refinements — background handling, logo integration
- Some visual changes reverted — function preserved over form
- System remains open — further iteration expected
What this is, and what it is not
This is not just a calculator. It is a small system. Inputs are defined. Constraints are explicit. Outputs are repeatable. The calculation itself is trivial. The structure is not.
What this demonstrates
This build was not about speed. It was about coordination. Between domain knowledge, structure, and execution — each playing a distinct role.
The model generates. The human defines. The system holds.
Most useful systems are not complex. They simply make thinking visible.
Closing noteDomain knowledge shaped the constraints — what the safe limits are, how oils are identified, what a valid output looks like. Structure determined how that knowledge was organised — taxonomy, naming, data references, error states. Execution was the act of building — AI-assisted, iterative, grounded.
When these three layers work together, the result is not a clever tool. It is a coherent system. And once thinking is structured, execution follows.