Do We Need Referential Integrity for Prompts?

Problem

I ran into a problem at work that I suspect will become increasingly common as products allow end users to write and save their own prompts.

These prompts rarely exist in isolation. They refer to things in the application: a location, a form field, a role, a workflow step, a report, a policy, or even a particular person.

Imagine a hotel group with several properties. Each hotel manager can create a prompt that runs every Monday:

Summarize last week’s guest satisfaction scores for the Rosebridge Hotel London and compare them with the previous week.

At the time the prompt is written, “Rosebridge Hotel London” is the name of a real location in the system. Six months later, the property is renamed “The Rosebridge Kensington.” The hotel itself has not changed, and it may still have the same internal database ID, but the saved prompt continues to use its old name.

Eventually the prompt and the application drift apart.

The difficult part is that this does not necessarily produce a clean failure. The prompt is still valid text, so the model will try to interpret it. It may guess that the old and new names refer to the same hotel, fail to find any matching location, or confidently use data from the wrong one. Each outcome wastes tokens and time, but more importantly, it gives the hotel manager an unreliable experience without making the underlying problem obvious.

Of course, someone can update the prompt. That is manageable when there is one prompt and everyone remembers it exists. It becomes much harder when customers have created hundreds of prompts across an organization. The application may not know which prompts depend on the entity that changed, so nobody learns about the breakage until users start seeing bad results.

Databases have a name for the property that prevents this class of problem: referential integrity. If one record points to another, the database can preserve that relationship or reject a change that would break it. A plain-text prompt has no such protection. It can continue referring to a field, role, or workflow that no longer exists.

That led me to this question:

If prompts can refer to real entities in a product, do they need something like referential integrity?

I explored a few possible approaches, but never arrived at a solution that I found both reliable over time and capable of preserving the simplicity and flexibility of natural-language prompts.