Read the explanation
The access matrix requires four header names: chain, model, auth and payment underscore asset. It trims field values and rejects empty fields. In the saved illustrative sample, five rows contain five distinct chain strings, three distinct model strings and three distinct payment asset strings. The bars use seventy pixels per counted item: five networks spans three hundred fifty pixels, while three models and three assets each span two hundred ten. These sets describe supplied configuration labels. They do not verify a live network, balance, provider, permission or completed payment. Offline parsing requires the external Papa Parse library; a missing parser prevents a successful new audit. For model reach, the code groups chain labels into a separate set for each model. In the sample, Model A has TRON, Ethereum and Base, so its reach is three. Models B and C each have one chain. The three bars use seventy pixels per distinct chain. Appending an exact duplicate of a Model A route would increase row count from five to six, but it would not increase the number of distinct chains in that model set. The row count increases, while the model reach bars remain unchanged. Sorting chooses largest reach first, with model name as a tie breaker. Repeated configuration rows are not independent evidence of broader access. The wallet count uses case insensitive equality on the auth field. Other distinct-set keys keep their trimmed string spelling, so case differences can create different labels. After a successful audit, the JSON export is the saved canonical object, including source rows, metrics, model reach, assumptions and limitations. Export does not perform a fresh external check. If a new audit fails, the handler clears its canonical value and disables export, but can leave an earlier visible result on screen. Read the error and export state rather than treating a stale result as a new pass. No model API, chain transaction or backend request is made by this local explainer.