Quorum is a specialization of Ethereum. My answer and approach applies to both platforms as it does not touch on Quorum-only matters like privateFor.
The way the question is framed suggests some conceptual matters to clear up. Let's start with the low-hanging fruit. Data lineage is a given in both cases. These are append-only systems where nothing can exist without a chain of transactions (and inputs) signed by externally owned accounts.
I think it's fair to say the details are about who/what needs lineage information and for what purpose. As you have described, it's not especially developer-friendly to rummage around in raw data. My point is that lineage is there, as a given, from a blockchain perspective. Whatever we build out will be aimed at a specific user and purpose.
I would suggest that you possibly underestimate the importance of Logs. The word "Log" might suggest something informal and unimportant but they are a powerful tool. They are roughly analogous to tables with specific columns. They can be indexed. They are searchable. They are low-cost immutable storage. Nothing can get into the Log unless a contract function emits it. They enable interested clients to "watch" and respond.
A good default design pattern and practice is to emit an event for every state change that occurs in the contract such that it would be theoretically possible to completely reconstruct the state history of the contract using nothing but event logs read back in the correct order. If you do that, lineage is a given, but also convenient and organized around a specific application.
Another good default habit is to make the current state completely discoverable. That is, a client should be able to learn every detail of the current state without wading through logs to reassemble everything brick by brick.
With both methods implemented as a sort of standard operating procedure, client software has two ways to inquire and can even explore what the "current" state would have looked like in a prior block. Event logs provide an immutable and reliable way to discover the state-changing transactions, who signed them, the data payload, etc. that made the current state the way we find it.
There is a limitation. Contracts cannot (easily) explore logs, although I've seen some experimental work with assembler that claims to make that possible.
This limitation is not normally a concern because contracts themselves are usually concerned with the present state and what comes next. They seldom need to explore the past. As I've tried to describe, by emitting events into the logs, most contracts have completed their task, enabling any interested software client to explore the past at their leisure.
Here are some heuristics to consider.
If contract logic depends on a piece of state information, then log storage is insufficient. The data needs to be stored in the contract state.
Contract logic is mostly concerned with considering proposed state changes, going forward. You will start to see that when contract logic is involved, it's seldom about the past.
It's not that I can't imagine how to organize a structure of lineage inside contract state. I imagine it isn't necessary to do so in order to achieve all the deliverables. It would probably be unnecessarily complex and expensive to operate. Or, it's a very rare use-case.
Hope it helps.
