You open an application. Something does not work. You ask your AI assistant for help.
The answer sounds reassuringly precise: open this menu, enable that option, run this command.
There is just one problem. The menu does not exist.
Anyone who has asked an AI about unfamiliar software may recognise the experience. It knows what an application like this might do. That is not the same as knowing what this application actually does.
Portable AI Support Documentation (PASD) begins with a simple question: what if the developer gave you the knowledge your assistant needs, instead of asking you to trust its guess?
Bring your own AI
The usual approach is to put another chatbot on another website. Another interface, another conversation, another service deciding how you get help.
Sometimes that is exactly what is needed. But not every software question requires a dedicated chatbot.
PASD proposes something simpler: the application comes with a file called AI-SUPPORT.md. It contains verified information about how the software works, what it supports, what it does not support, and what to check when something goes wrong.
You give that file to the AI assistant you prefer and ask your question in your own words.
The developer supplies the knowledge. You choose the assistant.
That choice matters. You might already have an assistant you find useful, need an interface that works better for you, or prefer a compatible local model rather than sending your questions to a cloud service. Getting help should not automatically mean giving up that choice.
Knowing what it does—and what it doesn't
A useful support file cannot just be a sales pitch or a list of features. It needs to describe the actual application, including the awkward parts.
Which version are you using? Does that setting really exist? Is the problem in this application, or in an external tool it relies on?
And, crucially, when should the assistant stop pretending it knows?
PASD asks it to distinguish three situations:
- Yes, this is supported. Here is the documented way to do it.
- No, this is explicitly unsupported. There is no hidden setting to discover.
- The documentation does not establish the answer. We need more information.
The third answer is important. Something missing from a manual is not necessarily missing from the software. Silence should not become an invented feature—or a confident but equally invented “no”.
An honest “I need the error message first” can be far more helpful than five beautifully written steps towards a button that isn't there.
Help that leaves you in control
This is where a seemingly small documentation proposal connects with a larger Meaningfulness concern: agency.
Having agency is not just being allowed to click something. It includes understanding your options well enough to decide what to do.
If an assistant invents a setting, hides uncertainty, or casually recommends deleting your configuration, you may technically remain in charge—but your decision is being shaped by bad information.
PASD therefore puts limits and safety alongside instructions. Before suggesting a destructive reset, the reference should explain what could be lost and what needs backing up. If the problem cannot be resolved, it should explain how to report it without exposing passwords, tokens, or private information.
The point is not to make an assistant sound more authoritative. It is to give you better grounds for trusting—or questioning—its advice.
A file, not another platform
For the person asking for help, the idea is straightforward: get the support file for your software version, attach it to an assistant that can read it, and describe what happened.
For an independent developer, it offers a way to make product knowledge available without running a dedicated AI service. There is still work involved: the file needs to be accurate and kept up to date.
And there are limits. A support file cannot guarantee that an AI will interpret it correctly. It cannot fix a software bug. Using a cloud assistant still means considering what information you share with that provider.
PASD is a public-draft specification, not a claim that these problems have been solved. The paper includes a way to test whether the approach improves answers; it does not report completed benchmark results.
But the direction is worth exploring: make the knowledge portable, make the boundaries explicit, and leave the choice of assistant with the user.
Better support should help people regain control of what they are doing—not require them to give up control of how they ask.