The Canonical Model
Why STRAX holds one agreed company data model at the hub, and why mapping every system to it once beats point-to-point translation.
One agreed shape for company data
Every system you run has its own idea of a customer. Splynx calls it a subscriber, HubSpot calls it a contact, Zendesk calls it a requester, and each stores different fields under different names. None of these shapes is wrong. Each is right for its own product, and none of them is your organisation's definition.
STRAX resolves this with a canonical model: one agreed set of business entities, held at the hub, in the shape your organisation chooses. There is one Customer table, one Invoice table, one Service table, each with the fields your business actually cares about. Source systems keep their own shapes untouched. The hub holds the agreed shape, and every system maps to it once.
Why one hub beats N×N translation
Without a hub, systems translate directly into each other. Five systems that all need to share data require up to twenty separate translations, each written, tested and maintained on its own. Add a sixth system and you face up to ten more. Every pair encodes its own assumptions, and no two pairs agree on what a customer is.
With a canonical model, each system needs exactly one mapping: its own shape to the agreed shape. Five systems means five mappings. A sixth system means one more, and it immediately exchanges data with all five others through the hub. Replacing a system means replacing one mapping, while the rest of the estate carries on unchanged.
The arithmetic is the smaller half of the benefit. The larger half is that the agreement about meaning is made once, in one place, visibly. When Demo ISP decides that the billing system owns a customer's payment status and the CRM owns their contact details, that decision lives in the model, and every connected system inherits it.
The model is yours to shape
STRAX does not impose a fixed industry model. Your canonical tables are defined in your own terms, and they can start small. Many customers begin with two or three entities, prove the flow, and grow the model as more systems join. The platform's AI assistant can propose canonical tables from the systems you have connected, and every proposal is yours to review and amend.
Because the hub holds real, current data in the agreed shape, it becomes more than a translation layer. Reports, dashboards and customer portals built on STRAX read the canonical model directly, so they show one consistent version of the truth rather than a stitched-together view of five sources.
Where it fits
The canonical model sits between connecting systems and mapping data. You connect a system, decide which canonical entities its data belongs to, and map it once. From then on, data movement keeps the hub and the sources in step. For the broader picture, see How STRAX works.