As mentioned in my comment on MDL-79112, this is something that we'll need to build in order to support tool instances in places outside of mod_lti. Right now, an instance is synonymous with an mdl_lti record.

Right now, the notion of 'instance' in mod_lti means, 'tool instance', which currently translates 100% of the time to mdl_lti table records - because right now, that's the only kind of tool instance we support. So, you'll see a bunch of instance and instanceid params littered around the place in locallib and in table definitions, etc. These various bits of code use the instance or instanceid the same way: to get the mdl_lti record and to access 'instance' data from that record. So, what we end up with is a mdl_lti table that contains roughly two types of data:

• data pertaining specifically to the lti activity, such as course, name, intro, etc. and;
• data which pertains to the lti tool instance, such as debuglaunch, launchcontainer, servicesalt and others.

Additionally, tools will store the instanceid and use it in things like the service calls (they receive it via things like the sourcedid string). When Moodle receives a service request, it looks up the instance (right now, that means looking up an mdl_lti record) and does something with the instance-specific data. This is just one example, of course.

So, when we start supporting more and more tool instances in different areas of Moodle (again, this is the eventual plan and what's driving this migration work), we need a way to have this instance data be retrievable outside of mod_lti.

The way I currently see this working is roughly as follows:

1. Split out the instance fields from the mdl_lti table, into a core 'lti_tool_instance' table, or something like that. This should support linking to anything in moodle via the usual {component, itemtype, itemid, contextid}tuple, as we do in a lot of other areas.
2. Migrate instance-specific data from the mdl_lti table to this new table, retaining the ids - this last part is important so that we guarantee that existing tools can continue to use their existing, stored instanceids. The following will be useful for this as we need to retain existing ids.

   $DB->import_record('lti_tool_instance', $instancedata);

   $DB->get_manager()->reset_sequence('lti_tool_instance');

3. Add a core_lti API allowing us to store the relevant instance data. This would be called from anywhere a tool is configured in future. For now, that'll only be from mod_lti, but when asset processor comes along next, we'll need a way to store the instance of that tool when it's configured in places like assignment and quiz.
4. Update any code that used to fetch the instance-specific data from mdl_lti table records and instead get it from the new core table. Most, if not all of these methods should have been moved to core_lti already, but there may be methods in mod_lti still too.
5. Clean up superfluous data in mdl_lti table. We won't need this any more because core_lti will now store this.