A translation and normalisation layer across BSS, OSS, CDR/xDR and mediation feeds — one subscriber ID, one code set and one format network-wide, so billing, assurance, analytics and AI all work from the same records.
The pressureLegacy BSS/OSS describes the same subscriber a dozen ways — and every project re-solves the mapping.
Why it matters to an operator executiveNormalising once is what lets every later AI use case go live in weeks instead of quarters, and it de-risks BSS modernisation. It is the least glamorous and most reused investment on the roadmap.
A foundation capability: it serves every stage, so later use cases go faster.
The fraud and revenue-assurance use cases come together in the SENTINEL command centre →
We start from the KPI an executive owns, not from the technology — then work back to the decisions, data and agents that move it.
Source and identifier landscape; value case
Canonical telecom data model and rule families
2–3 sources normalised into a golden subscriber record
First consumer — billing, RA or analytics — live
Add sources in sprints; DataOps under SLA
Same five phases on every engagement; the pilot (phase 3) runs on your data with your team. How the methodology works →
Operators run decades of BSS and OSS side by side. The same customer, product and event arrive in different formats, codes and identifiers — and every downstream team re-solves the mapping.
MSISDN, IMSI, billing account and CRM party IDs rarely line up, so a single customer view needs custom joins in every project.
COBOL copybooks, fixed-width mediation files, CSV extracts and JSON APIs all feed billing, assurance and analytics.
Bad codes and duplicates are found at invoice time or in revenue-assurance reports, long after they entered the data.
UNIFY runs as a governed pipeline on the SCIKIQ Data Fabric. Rules are configuration, not code, and every record keeps its lineage back to the source file.
Six agents do the routine normalisation work; data engineers own the rules and approve new mappings.
Rule pass rates, failures by source and normalisation volumes by format — the screens a data engineering team works from.
Figures load live from the demo platform (quality rules and normalisation runs). Source names reflect the demo data set.
| Rule | Type | Source | Processed | Failed | Pass rate |
|---|---|---|---|---|---|
Format and validation rules pass at the highest rates. Correlation rules — matching the same subscriber across systems — and enrichment rules fail most often: the classic subscriber-ID problem. Legacy CSV extracts and COBOL copybooks carry the largest volumes and the most failed records.
Two or three sources normalised into one canonical model, with a measured rise in rule pass rates and a first consumer live.
UNIFY serves the teams who build on subscriber data and the teams who depend on it.
Technology leadership
Data governance
Architecture
Revenue teams
How a governed normalisation hub compares with the approaches operators typically use today.
| Capability | UNIFY | ETL tools | Custom scripts | Manual process |
|---|---|---|---|---|
| Legacy format support | 50+ formats, configurable | Limited connectors | Custom coding per format | Manual parsing |
| Subscriber ID correlation | Fuzzy and rule-based matching | Exact match only | Custom logic | Manual lookup |
| Validation | Rules plus ML anomaly checks | Rule-based only | Basic checks | Manual review |
| Lineage | Automatic, source to output | Partial | Documentation only | None |
| Change a mapping | Configuration, versioned | Developer change | Code release | Spreadsheet update |
UNIFY sits in the Connect and Curate layers of the framework and publishes canonical data to every consumer. About the framework →
Capabilities, not promises: the outcome depends on your source landscape, which we size in discovery.
Every team and accelerator reads the same correlated subscriber, account and device records.
New analytics and AI work starts from canonical data instead of another round of source mapping.
Rule pass rates and failures by source are measured continuously, not discovered at invoice time.
Each output record traces back to its source file, rule version and correlation decision.
Most UNIFY engagements start with two or three source systems and one downstream consumer, then add sources in sprints.
Map source systems, formats and identifier schemes; agree the canonical model and the first consumer.
Weeks 1-2Connect two or three sources, configure parsing, validation and correlation rules, and publish canonical records with lineage.
30-45 daysAdd sources and consumers in sprints; hand over to DataOps under our managed service if you choose.
Ongoing