I’m trying to figure out how viable an idea I had is. I’m working on a project where we have a large and expanding set of subjects the bot can converse about. I was thinking, instead of building a new topic for each one, I could write a general topic and load a data structure containing the specific information about the subject as well as responses. The topic would parse the data, and possibly even use rules stored in the data for dealing with specific cases.
  This would greatly streamline our authoring process, and allow us to integrate more conversation ability more quickly. What do people think? Could this be done? Also, what would the resource impact be of handling data like this? I assume we could preload common or expected subjects.
  I’m pretty new to chatscript, so all advice is appreciated.

Our entire bot is data driven apart from a few simple rules dealing with “hello”, “how are you” things.
Everything from the names of the tasks that the bot can respond to and how to conduct the dialog from that point is loaded from JSON served up from our server. That JSON includes the text returning to the user.

Some of this data is loaded during the boot process via the ^cs_boot() macro.
Some of it is loaded for a user and saved in the topic file so that it is instantly available on the next volley, and is periodically refreshed.
Some of it is loaded for the specific volley and is transient.

We use some of the data to create concepts, which if they are done in the boot or loaded from the topic file will be available to the preparation phase and so we can have general rules to look for the best matching task.
We have CS patterns in the data to allow for very specific matching. You can use the ^match() function to dynamically find matches.

Needless to say we have a lot of script, but that CS processing has never been a defining factor in our response times. It is time spent by external service requests that take the biggest proportion of time.

Thank you, it’s good to know other people have done thins and it works.

I would imagine that you have a pretty extensive control script for handling all of the data, is that right? How is that structured?

Also, do you handle expansion or alteration of data in CS, or externally?

Thanks for your help!

Yes, our control script is not the default one!
Though it has some of the same elements - check for rejoinders before responders/gambits for example. It is just that the topic we run to see how to respond to the input is mainly script that slices and dices and comes up with a “score” for each possible intent. We pick the best one from that. But we also test to see if a topic has valid responders for the input so that we know if some fallback topic is possible, e.g. some kind of greeting.

We also have pretty extensive entity extraction so if an intent needs a date for example, we can either get it from the original input, or prompt for it if not. All done via CS and we post the results back to a server.

One of the keys to success is to do things in pieces, don’t try and do it all in one rule. So for example, we have our own topics to correct the initial parse by CS to our liking. We have a topic to store that parse data in JSON to make it easier to process later on. We have another layer of topics to detect formatting data, e.g. numbers and dates. The ^mark() and ^unmark() functions are very useful and make later patterns much simpler.