We keep coming back to one question. Why can a financial institution model credit or liquidity risk before acting, but not the regulatory consequences of a product decision?
Most software sold to compliance functions assumes the decision has already been made. Obligations exist; they have to be tracked, evidenced and reported. That is real work. It is not the work of choosing.
Two different questions
"Are we meeting our obligations?" is a monitoring question. "What would this decision do to our regulatory position?" is a simulation question. Better monitoring cannot answer the second, because the thing being asked about does not exist yet.
Institutions answer the second question today with meetings, memos and specialist hours. It works, at a price: management time, counsel cost, and no comparable record of the options that were considered and dropped.
What a category needs to be real
A vocabulary, first: regulatory simulation, Regulatory Delta, regulated business decision, continuous regulatory testing. Then a buyer — the executive who owns the decision, not only the function that documents it. Then an output management can act on: consequences, alternative configurations, and an honest statement of where judgement is required.
Our thesis is that the temporal distinction is the whole argument. One category operates after the decision. The other has to operate before it, which makes it a different product with a different customer.
What the product still has to prove is that the before-the-decision reasoning can be reproduced reliably enough for an institution to rely on it. That is the regulatory decision problem we are trying to make computational.