Watch a trade compliance analyst work through a sanctions alert: she is tracing an ownership chain, asking whether a sanctioned party controls this counterparty through 50 percent stakes stacked three layers deep. Now watch an internal auditor mapping intercompany exposure, an ethics officer assessing a third party's beneficial owners, and a supply chain manager asking who actually sits behind a struggling supplier.
Four job titles, four software categories, four budgets, four vendor relationships. One computational problem: traverse an ownership graph and decide when indirect control matters.
The dozen problems wearing thirty costumes
Do this exercise across an enterprise and the pattern generalises. Superficially unrelated functions keep resolving to a short list of recurring computational problems:
- Entity resolution. Is this supplier, this counterparty and this hotline subject the same real-world thing? Every function asks it; each buys a different partial answer.
- Ownership and network traversal. The example above, shared by trade, audit, ethics and supplier risk.
- Classification and mapping. Products to tariff codes, obligations to procedures, transactions to accounts, incidents to categories.
- Anomaly detection. The odd expense, the drifting sensor, the unusual override, the outlier shipment. One statistical discipline, bought five times as five features.
- Change-to-document conformance. A regulation changed: which procedures are stale? A plan changed. Which commitments break?
- Alert triage. Too many flags, too few analysts, in screening, monitoring, quality and security alike.
- Forecasting and timing prediction, hierarchical coherence, variance attribution, evidence and lineage, allocation under scarcity, scenario and attribution analysis; the rest of the list runs the same way.
Across the thirty-odd modules of a full enterprise suite, we count roughly a dozen problem classes doing almost all of the real work. Eleven of the twelve recur in more than one function.
What organising around problems changes
Enterprise software is organised around functions because that is how buyers are organised, and the consequence is structural: every module rebuilds its problem solutions from scratch, to whatever standard that module's team reached, with no mechanism for the audit module's anomaly detection to benefit from what the finance module has learnt.
Invert the organisation, build the problem classes once as first-class engine capabilities and let each function configure them with its own vocabulary, and three things follow:
- The second module costs less than the first. Its hard problems arrive already solved, needing configuration rather than construction. The flywheel is economic, and it compounds with every module added.
- Improvements propagate. Sharpen ownership traversal for the trade module and the audit, ethics and supplier modules inherit the sharpening the same day. The same holds for anomaly detection: the statistics that flag an odd expense pattern for audit are the statistics that flag an unusual forecast override for demand planning and a drifting sensor for EHS. Tune the discipline once, against the hardest of the three, and every consumer gets the improvement. Learn once, improve everywhere.
- Quality converges upward. Each problem class is maintained by the standard of its most demanding consumer, not the budget of its weakest one.
A module, on this architecture, is a vocabulary and a set of decisions, not a codebase. The engine has no domain vocabulary at all.
The test a buyer can run
The architecture claim is checkable from outside. Ask a suite vendor: when your screening module improved its entity resolution, what happened in your audit module? If the honest answer is nothing, the suite is thirty products sharing a login page, and each module's intelligence is capped by its own team's capacity.
Ask the same question of a problem-organised platform and the answer is a release note: the improvement landed everywhere the problem class is used, because there is only one of it.
This is the architecture Prophesee is built on. A domain-agnostic engine holding the problem classes, configured per module through vocabulary rather than code. See the flywheel on your own functions. Start here.