First off, I just want you to know I don’t expect to get responses on all of these – they’re just suggestions!
Workflows could be made much more powerful and actually less complicated if instead of a single path, steps could branch out like a decision tree and whether they run could be based on conditions – those conditions being facts about what’s input and/or Thunk’s findings.
This has been a topic of some debate internally. Engineers like tree structured logic. But most real world forms are linear with skippable sections (eg: think of our favorite 1040 tax forms or any other form you fill in at a doctors office, etc). So we’ve sort of adopted the latter.
When we’re building thunks, if some of them should be conditional, we put the condition at the beginning of the prompt.
If we really need branching off into a completely different flow, we use multiple thunks and use the first thunk to route into the appropriate next thunk.
Without a doubt, it adds moving parts, so we’re hoping to learn from usage and then react to it if there’s a lot of requests for branching.
PS: we much appreciate the suggestions and ideas.
Hi Praveen. Skipping a section of a form is kinda like “Is this extra thing True or False?” as opposed to “Are you this thing or that thing?” It makes it seem like one of the options is a special case. (Also, we can’t rely on the Thunk to skip steps because it’s not hard-coded in.)
In our use case, conditional logic would be extremely helpful, because “publications” are very abstract objects and so our publication database is kind of like a “god table” in that not all fields apply to all records.
The biggest example I can think of in terms of “this thing or that thing” (where branching would be super helpful) is whether the AI feels it reliably matched to a real-world object based on the input information (and it can run into roadblocks like maybe the input information is ambiguous [like multiple real-world objects seem to be equally valid matches] or internally inconsistent [like the person put conflicting identifying information there – and if this is the case, is there an obviously dominant candidate that emerges that lets you discard all but one publication’s identifiers in the input?]). I want it to be able to recognize when it cannot make an educated guess as to what the input is trying to look for – and when it cannot, it shouldn’t try to do anything else with it.
The second biggest example I can think of is whether a publication is a serial or a monograph. Depending on the answer, different steps need to be followed. Having to put the conditional logic within the step is more complicated for us and for the AI… and less reliable than hard-coded branching abilities. Also, I can’t even think of how I would write the steps out so that it would methodologically skip serial steps for monographs and vice-versa – that’s much more complicated than hard-coded branching. And there are more branches, and we can’t create a new Thunk for every possibility for every branching point (+1 Thunk for each branching point that would choose which Thunk to choose for that branching point).
(Yeah, our needs are pretty complex…! 
)