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