This paper sets out the reference architecture for governing communication identifiers as a single estate, covering telephone numbers, SIP identities, messaging sender IDs, SIM and eSIM profiles and the identifier types still emerging, rather than as disconnected inventories, one per system that happens to touch them.
The design problem
An enterprise identifier estate is heterogeneous by nature. Identifiers live across multiple carriers, in UC and CPaaS platforms, in device management tools, and in the registries and attestation systems that vouch for them. Each of those systems is legitimate, does real work, and is not going away. Any architecture that proposes to govern the estate therefore faces a constraint that shapes everything else: it must add a governance layer without becoming another silo, and without replacing the systems that actually execute the service.
Most attempts fail on one side of that constraint or the other. Consolidation projects create another partial inventory. Rip-and-replace platforms ask the enterprise to abandon working carrier and platform relationships. The architecture described here is built to do neither.
The operating model: a layer, not a stage
The second shaping decision is about when governance happens. Treated as a stage, whether an approval step, a quarterly audit or a cleanup project, governance is always either a bottleneck or out of date. The operating model this architecture implements treats governance as a continuous layer: ownership, policy, validation and evidence apply as part of every change, across every layer of the platform, rather than as a checkpoint changes queue behind.
One consequence is that the same stack can be read two ways, and both readings are true. Read top-down, it is the product an enterprise buys: one place to see, control and prove the identifier estate. Read bottom-up, it is the technology platform that makes that product possible. The architecture is one stack serving both readings.
The four layers
Control Surface: the layer every team shares. Operations, compliance, security and executive views over the same governed record, so that "what do we have, who owns it, what changed" has one answer regardless of who is asking.
Governance Services is the governance engine itself: the policy engine, lifecycle automation, compliance posture and evidence store, cost analytics and trust intelligence. One engine applied across every identifier domain, which is what keeps governance consistent rather than re-implemented per identifier type.
Identifier Graph: the governed model of every communication identifier and the relationships between them, providing a single source of truth for ownership, policy, lifecycle and execution. The graph is the layer the fragmented inventories connect to: not another list alongside carrier portals and admin consoles, but the canonical record of identifiers, owners, platforms and policies that everything above and below it reads and writes.
Execution Integrations: API-native, bidirectional connectors to the systems that deliver the service: carriers and operators, UCaaS platforms, CPaaS providers, registries and attestation, the identity and security stack, and ITSM and GRC operations. Coverage, not replacement.
Holding the authoritative record is only half the work; the other half is making the estate match it. In operation, that means the platform provisions into the carrier and call-control systems that deliver the service, configures the trunks and routing that sit between them, and draws numbers from several upstream providers rather than one, so a governed decision becomes a live configuration, not a ticket asking somebody to go and make one. That is the difference between a record of what ought to be true and a platform that makes it true.
Govern, don't replace
The integration posture deserves its own emphasis, because it is where this architecture differs most from what enterprises have been offered before. Where the systems that deliver service sit outside the platform boundary, the connectors are deliberately bidirectional: governed instructions flow out, current state flows back, and those external platforms keep their own systems of record. The platform's job there is to govern the estate without requiring the existing operational systems to be replaced. Where a deployment instead gives the platform direct ownership of particular operational state, or has it drive execution itself, that sits within the same governance model: what stays constant is the authority, policy and validation applied to a change, not which component physically holds each fact. The ecosystem is larger than any one vendor, Telesmart included, and the architecture is drawn to respect that.
This is also what makes adoption tractable. Nothing has to be migrated off a working platform for governance to begin; the estate comes under governance where it already lives.
What operates today
A reference architecture describes what a platform is built to carry. That is a different question from what each layer does today, and separating the two is a fair test to apply to any vendor in a category this young, including this one.
Operating in production now, in live customer estates, on real carrier and network integrations: the governed record itself, holding every identifier with its owner, state, provider and market as one working record rather than reconciling between systems; the full lifecycle state set of reserved, activated, quarantined, retired, suspended, cancelled and reactivated, executed under governed control without leaving the governance layer; porting carried through with the documentation and status tracking a regulator expects; compliance-sensitive changes routed to the right approver by role before they execute; onboarding as a document-verification workflow rather than an email trail; in-line rule enforcement that declines work breaching the rules the platform holds, at the moment that work is attempted; and the carrier, routing and trunk-configuration connectors that turn each of those decisions into live configuration.
Planned rather than delivered: the parts of Governance Services that generalise the model across every domain at once: the canonical policy engine, the evidence architecture that turns audit trails into audit-ready reporting on demand, cost attribution and utilisation analytics, and trust intelligence for outbound identity. The architecture is drawn for them. The layer does not carry them yet, and this paper does not pretend otherwise.
Where the boundary sits is a deployment decision rather than a fixed property of the platform. Telesmart governs the configuration that makes communication work, and in some deployments carries live traffic as well; traffic carriage is a real capability, but it is not the core proposition. The platform is designed to coexist with the carrier, UCaaS and CPaaS systems a provider keeps, while taking on more of the operating stack where a provider needs that. Commercial authority varies in the same way: the platform can manage tariffs, charging, invoicing and credit where those functions are in scope, while a customer's retained systems stay authoritative wherever the customer chooses to keep them. What does not vary is that the platform is authoritative for what identifiers exist, who owns them and how they may change. Governance is a layer with defined edges, not a claim to own everything an estate contains.
Where adoption starts
In practice, governance enters through telephone numbers, the identifier class with the longest regulatory history, the most accumulated fragmentation, and the fastest payback, since a first governed reconciliation typically surfaces the orphaned and unbilled portion of the estate immediately. The same architecture then extends across the broader estate as further identifier domains are brought under governance, in a deliberate, outcome-justified sequence. The discipline stays constant; the scope grows.
What to read next
For the category argument underneath this architecture, start with what Communication Identifier Governance actually means. For the cost of the fragmentation this architecture exists to end, read seeing the whole identifier estate at once. For the board-level framing of the operating model, see the governance operating model brief.
For the status of each capability individually, rather than the summary above, the capability publication states what every one of the thirteen does today and what is planned. And for the criteria to test any vendor in this category against, this one included, read how to evaluate a Communication Identifier Governance platform.