If the commands can be split into two parts, you can use prefix/suffix to manage them.
The way I do this is to treat the suffix like a database lookup, in a sense; The prefix does most of the logic, while the suffix provides the data.
This is accomplished by using jumping into the suffix to read the required data, then jumping back into the prefix to do something with that data:
(Prefix) "Is there data on "
Jump to Marker: SetType
Marker: TypeSet
Begin Boolean Compare : [~~data] Equals True
Write '[Blue] There is data' to log
Else
Write '[Blue] There is no data' to log
End Condition
Exit Command
Note the "Exit Command" action, which prevents execution from going back into the suffix and causing a loop.
(Suffix) "something"
Marker: SetType
Set Boolean [~~data] to True
Jump to Marker: TypeSet
You can pass any number of variables. I find it's best to work out which data you need to store/process, and set up a template you can duplicate.
If you want to speak the subject in the suffix instead, it becomes much simpler, as you don't need to jump back and forth at all(set data in the prefix, process in the suffix), but I find it's more natural to speak the operation before the subject(E.G. "what is lettuce" rather than "lettuce, what is it") in most situations.
Logically, this is the equivalent of a long conditional chain, but UI-wise it makes managing and adding values less of a hassle.
If subroutines are implemented, this sort of thing could be managed that way instead, but currently I believe this is a reasonable balance between functionality and complexity.
If you really want to make it complex, you could store your values as a list or even in an actual database, and dynamically build a "when I say" phrase for a command that looks up the relevant data at the time of execution instead, but then editing the data could become cumbersome.