Self-amplifying data requirements description

I have a rough use case (I thought I had submitted user stories for this, but I can't refind them) that I think belongs in this panel, even though I'm not sure it has a clear home in a project right now. The point of the exercise is to find effects that can accellerate the usefulness of having your data in a Pod.

Concrete case: I'm booking a crossing with a large car-deck ferry, and apart from the usual profile information that will typically reside in a Pod, they will also ask for my passport number, any allergies, and the length and registration number of the caravan that is drawn by my car.

This illustrates that some information is common and of no particular interest in accellerating the usefulness of a Pod. However, when I am asked my passport number for the first time, I will enter that only once, and then when I am asked that again (e.g. for a flight), it will be reused from my Pod, not entered again manually. Likewise with allergies, when that has been entered once, it can be reused in for example restaurant search. This amplifies the usefulness of the Pod. This amplification does not happen in current networks, within data silos, and without personal data control, the data aren't shared (and we should be happy about that). Nor does it happen if you define a profile or even an extended profile, that use case provides no incentive for users to enter them.

So, the unique point of this use case is that it provides an incentive for you to enter the data, it is required by an external party for completing a reservation, but the data remains yours and can be shared with other actors.

Interestingly, it also provides an incentive to start entering more obscure data, like the registration number and length of the caravan. That provides and incentive to start maintaining a more extensive record of an item, or to Link Open Data. This again sets off more network effects.

So, the consumer defines the shape of the data they require, and then the user enters data to comply with the shape.

In the future, this could be extended to encompass legal requirements for data sharing, but for now, I think the most important aspect is the way this use case amplifies the usefulness of a Pod.

The issue names no file, test, or entry point. Start by reviewing how the panel currently captures use cases and requirements, then determine whether this scenario has an appropriate home. Done means the use case has an agreed scope and location in the project documentation.