Level 12 · Professional Portfolio and Capstone

Formula Design and Iteration Log

Design the capstone formula in stages and keep a log in which each version states its hypothesis, change, result and decision, so a reader can follow the path.

In short

A perfume iteration log records each version of a formula with its hypothesis, its exact change, the result and the decision that followed, so a reader can follow how you got there. It is the backbone of your capstone. When you have finished, the log will show what you did, including the wrong turns, which a finished formula never can.

What you will learn

  • Plan a capstone formula in stages
  • Keep a log where each version has a hypothesis and decision
  • Know when to stop iterating

Before this lesson: Concept Development

Design in stages

  1. Skeleton. Build each main cue or sub-accord separately, in small batches.
  2. Assembly. Combine them in a first draft that totals 100%. Use your unit method if it is long.
  3. Structure. Fix how it evolves. Check the handover between stages, as in balancing volatility.
  4. Character. Make the small changes that give it identity.
  5. Constraints. Bring cost, restrictions and allergens into range. Do this throughout, and not only at the end.
  6. Refinement. Remove what isn't working, using removal tests.

The log format

The columns of an iteration log, with an invented example entry
FieldExample
Version and dateV5, November 3
Parent versionV4
HypothesisRemoving the benzoin will reduce sweetness at 2 hours without losing warmth
ChangeBenzoin resinoid from 3.0 to 0 parts; solvent adjusted to keep the total
TestBlind against V4, on strips, at 15 minutes, 2 hours and 8 hours
ResultLess sweet at 2 hours, as expected; thinner at 8 hours, which I did not expect
DecisionKeep, then address the 8-hour warmth in V6
Cost and constraint effectCost down slightly; no new restriction concern

The full formula for each version lives in your formula record. The log points to it. RUŌOD Lab keeps formula versions and notes, and a spreadsheet or notebook can do the same as long as you can retrieve the exact formula for any entry.

Rules that keep the log honest

  • Write the hypothesis first. Once you have smelled the result, you can't recover what you expected.
  • One change per version where possible. If you make several, say so, and accept that you can't separate their effects.
  • Date everything. A later comparison might be testing age rather than formula.
  • Retain samples. Keep a labeled sample of each version until the capstone is finished.
  • Do not rewrite history. Correct an entry with a dated note, leaving the original readable.

Backtracking

Good logs have branches. If V7 is worse than V5, make V8 from V5 and record that V8's parent is V5. Run a blind comparison of your current version against an earlier one every few rounds. Your memory of V3 cannot be trusted, and your nose has adapted to your direction of travel.

Knowing when to stop

Stop when one of these is true:

  • It meets the success test on your concept page.
  • Your last two rounds did not produce a change that was reliably better in a blind comparison.
  • You have reached your stated time limit. In that case, record where it stands.

Unresolved flaws can be listed in your case study. An honest "what I would do next" is more impressive than a claim of perfection, as the finished formula lesson explains.

Practical exercise: At least six logged versions

About 300 minutes · You will have: a capstone formula with at least six logged versions and a stated stopping reason

  1. Build your skeleton, then assemble a first draft.
  2. Make at least six logged versions, using the table's fields.
  3. Include at least one blind comparison with an earlier version, and one backtrack if warranted.
  4. Run at least two removal tests.
  5. Write your stopping reason.

You have done this well if someone could rebuild any version from your records, and they could follow why each change was made, including those that did not work. Keep this as a study composition until the later reviews are done.

Common mistakes

  • Writing the log afterward. It then becomes a story and stops being a record.
  • Testing only against the previous version. Drift can go unnoticed.
  • Hiding failures. They are evidence of real work.

Knowledge check

1. What should each log entry state before the version is made?
Show the answer

The hypothesis and the single change. You want to record what you expected, so you can learn when reality disagrees.

2. Why log a version that failed?
Show the answer

It records what you learned and stops you repeating it. Failures are often the most useful entries, and your case study needs them.

3. How do you know to stop iterating?
Show the answer

It meets your success test, or a further round isn't improving it. Check the criteria you wrote earlier, and compare against earlier versions blind.

Written and reviewed by the RUŌOD Lab team. This is general education, not legal, regulatory, medical or safety advice. Example dilutions and exercises are for learning, are not validated products, and have not been safety-assessed. Completing a lesson confers no qualification. How we check these lessons.