diff --git a/content/post/smart-rice-cooker.md b/content/post/smart-rice-cooker.md
index 6c08822..37ad241 100644
--- a/content/post/smart-rice-cooker.md
+++ b/content/post/smart-rice-cooker.md
@@ -44,6 +44,22 @@ Everything about it is like any other hot pot, it's just tuned for cooking rice.
 Thus, once I convert the thing to being smart, I will be able to use it for, say, ramen, or any number of other things.
 The possibility of steaming things only furthers this goal.
 
+## Recipes
+
+The question is raised, how should I deal with parametric recipes, and more specifically, internally governed parametric recipes.
+That is, recipes that have no prior knowledge of the volume of rice and water added, but infer it from the time it takes to reach temperature.
+This value, that is, the duration taken to reach temperature, only holds value when a set heating cycle is used, such as full heat, or constant PWM.
+Typically however, no PWM is required during initial heat, only once at heat.
+
+As such, a value that any directive may rely upon should be the duration taken by some prior directive.
+This then leads me to say that each and every step in a recipe must have a unique identity, so that later directives may rely on them.
+
+This, then, immediately appears to be far more complicated than I should worry about, instead, this behaviour aught to be offloaded to Lua or some other scripting system.
+As such, the NodeMCU should be ideal, as it supports a variation of Lua.
+Ideally, this will allow branching logic also, and storing of values, simplifying my technical burden.
+
+Alternatively, it does not sound impossible to write a simple translator to emit both a Lua scripted version of a recipe, and a version that may be embedded directly into the compiled code (so that non-Lua boards may be used).
+
 ## Heating
 
 The contents of the rice cooker should be considered when heating/cooling, as they will absorb the heat and thermal lag will be an issue.
@@ -92,7 +108,19 @@ I tentatively (with no real experience designing them) plan on my API being some
 
 Directives are distinct actions to be taken.
 
-They include:
+They may be catagorised as follows:
+
+#### Primary Directives
+
+* Sleep
+* Heat
+* Cooling
+
+#### Secondary Directives
+
+* Temperature
+
+These are defined as such:
 
 ### Sleep
 Just wait for given duration, or until a given condition is met.
@@ -106,7 +134,7 @@ If I someday choose to use a fan, this should be an active feature.
 Instead, it's the same as `Sleep` for now.
 
 ### Temperature
-Heat/cool to given temperature, optionally at a given rate of change (may be difficult for cooling if no fan is included).
+Heat/cool to given temperature, optionally at a given rate of change (may be difficult for cooling if no fan is included), or percentage load (which will set a PWM rate, or if full, run constant).
 This should just be a proxy directive to `Heat`, `Cool`, and `Sleep`.
 For now that should work, but in due course, with tuning and benchmarks, this should run cooling at a variable rate (using a fan, I wouldn't want to cut on and off all the time).
 Heating should be fine be fine with fairly large PWM, as the thermal lag I expect to be significant, and we want to try to hit our deadline as quickly as possible.