There is a distinction that matters enormously and gets collapsed constantly: being able to see something is not the same as being able to understand how it came to be.
You can view a profile, a feed, a dashboard, a report. You are seeing outputs. What produced them, why this item and not that one, what was excluded and on what basis, remains entirely opaque. Read access without process access is a window, not an explanation, and mistaking one for the other has become an expensive error in at least one very large industry.
The industry that learned the difference
American health insurers covering more than thirty million older adults are paid according to the medical conditions documented for each member. Software reads clinical notes at scale and surfaces conditions that translate into payment.
For years, the outputs of those systems were entirely visible. Insurers could see every code the software suggested, review lists, run reports, audit totals. Read access was complete.
What nobody had was process access. Why did the system suggest this specific code for this specific patient? Which sentence in which note triggered it? What did it consider and reject? Those questions had no stored answers, because visibility of outputs had been mistaken for transparency of process.
Then federal auditors arrived, roughly two thousand certified coders on a rolling quarterly cycle, and asked exclusively process questions. Reviews of three insurance plans published this spring found 81 to 91 percent of certain sampled high-risk diagnosis codes unsupported by the records behind them. A major insurer settled federal claims for 117.7 million dollars. Full read access to the outputs provided no defence whatsoever, because nobody was asking what the system said. They were asking why.
What real transparency requires
The architecture that emerged in response is instructive precisely because it makes the distinction concrete. Modern ai risk adjustment systems pair a neural layer that reads unstructured text with a symbolic layer that validates findings against explicit rules and emits the reasoning as part of the output.
The practical difference shows up in what gets stored. Not just the conclusion, but the source sentence supporting it, the rule it satisfies, the confidence value, and the identity of the human who confirmed it. Model versions and rule sets are pinned so a decision from three years ago reproduces under the logic that existed then.
There is a second requirement that read access could never have been revealed: the system must flag items for removal as diligently as it surfaces items to add. Investigators treated one-directional correction as evidence of intent, which means the transparency that mattered most concerned what the system chose not to do. You cannot see an absence in a list of outputs. You can only see it in the process.
The general form of the mistake
Once you have the distinction, it appears everywhere.
A dashboard that shows every metric but not how metrics are calculated. An audit log that records what happened but not what was evaluated and rejected. A moderation system that tells you a decision was made but not which rule applied. A recommendation feed you can scroll indefinitely without ever learning why these items surfaced. In each case there is abundant read access and almost no transparency, and the abundance of the first tends to suppress demand for the second.
The healthcare case establishes what closing that gap actually requires, and it is not more visibility. It is different data, captured at the moment of decision, because process transparency cannot be reconstructed after the fact. Nobody can tell you three years later why a system did something if the reasoning was never stored.
The useful question
For anyone evaluating a system, a service, or a tool: not can I see the output, but can I see why this output rather than another one, and can I see it later, from records that already exist.
Most systems fail that question comfortably. The interesting thing about the healthcare precedent is that it demonstrates the failure is a design choice rather than a technical inevitability. Systems reading millions of medical records now emit their reasoning as standard, because a regulator required it and the industry discovered it was entirely buildable.
Read access was never the hard part. It just looked enough like transparency that nobody asked for the real thing.
