Telecom

Revenue assurance exists because the volume defeated inspection.

Service delivered against service rated. Rated against billed. Billed against collected. Your interconnect traffic against theirs. Each is two records that ought to agree, over a stream too long to read — which is why the work was built on samples. Read this page as an architecture: it describes the Runink TIDE platform working with Atlas, an assessment platform from Logical Leap.

Where the decision happens

  1. Records you already keepSpread across the systems you already run.
  2. One finding, with its evidenceDrawn together into a single proposed action.
  3. A person approves itThe drafted action waits; approving is what sends it, under their name.
  4. The work goes outAnd the reason stays on the record.

Where it goes wrong

  • A rating change right for the promotion, wrong for a legacy plan

    The affected population is small. It moves no monthly aggregate, fires no threshold, and rarely turns up in a sample.

  • A sample gives you a rate, not a name

    A monthly sweep produces an estimated error rate. To fix anything, operations needs the affected accounts individually.

  • Two parties, one stream of traffic

    Traffic as you recorded it, as the counterparty recorded it, and the agreement that sets the rates. Three sources, one difference that matters.

  • Rollout across many small sites

    Site builds and equipment purchases follow the plan, approve, procure, spend sequence of any capital programme — spread over many small sites, which makes sampling worse.

Who owns this

One function in telecom already does this work by hand. The rest inherit the same shape.

  • Revenue assurance

    The comparison runs at the transaction, not as a monthly sweep, so the remedy is a configuration correction and a re-rate.

  • Interconnect and partner settlement

    Both parties' records of the same traffic, read against the agreement that sets the rates, continuously rather than at period end.

  • Finance and procurement

    "Where is our risk concentrated across plan to books?" has an answer that updates rather than one that gets compiled.

  • Compliance and data protection

    Rules about subscriber data are applied to the flows, and the evidence that they operated is written as the work happens.

  • Engineering and IT

    Reasoning runs on your servers, your cloud or ours, never at an outside AI service.

What the arrangement changes

  • The population tested is the population, so exceptions come back as named accounts a re-rate can still fix, rather than as an estimated error rate. Reading every rated record against that subscriber's own plan terms is Atlas's work; judging each finding it sends is TIDE's.
  • Each finding that reaches TIDE is gated deterministically before anything is put to a model: it must be complete enough to read, it must carry evidence, at least one piece must be readable, it must be about the subject of the finding rather than something adjacent, it must not be the claim written out a second time, and dated evidence must be recent enough to say something about the present. Each gate that fires ends the matter and states its own reason in a sentence a person reads.
  • A finding claiming a rate is settled by arithmetic on the raw counts, recomputed rather than accepted, and never goes near a model. A count divided by nothing is unable to judge, never a rate of zero. Two readings of the same traffic that disagree are unable to judge, never averaged into a third figure neither party observed — which for interconnect is the whole argument.
  • The judging happens on a different credential from the submitting, enforced by which door the message arrived at rather than by a field the sender fills in. A submitter cannot grade its own work.
  • Unable to judge is a verdict in its own right and never renders as agreement. No evidence, evidence that only restates the claim, evidence about a different subject, evidence past the staleness horizon, an unreadable answer, or a submitter who could not determine the matter either: each ends there, with the reason written next to it, and goes to a person. An assessor whose confident answers and whose guesses look identical is ignored within a week, and this is the discipline that stops that.

How you will know it worked

The figures below are yours, not ours. Write down where you stand today, before anything changes — a baseline stops being recoverable once things start improving. The right-hand column says which way each figure should move, and by what mechanism.

The measure Your figure today What moves it
Rating accuracy, and the usage it under-bills The rating error rate revenue assurance reports upward, and the sample size and month behind it. Then a month of mediated usage against what billing charged. It stops being an estimate: each account's rated output is read against its own plan terms, so under-rated usage arrives as named accounts a re-rate can still fix.
Credit notes and billing disputes — volume, value, days to resolve Credit notes raised against billing errors over the last four quarters, from the billing ledger, with opened and closed dates. Volume down, because the error is caught before the invoice goes out. Days to resolve down, because each item carries the records it came from. Billing-dispute churn follows.
Interconnect and wholesale settlement differences Your last settlement cycle with each major counterparty: value in dispute, open items, age of the oldest. Fewer reach dispute, and those that do age less, because your traffic, the counterparty's and the agreed rates are read against each other while both sides still hold the detail.
Capital committed against equipment in service For the current rollout programme: approved spend, purchase orders, equipment received and sites carrying traffic, side by side. If that view takes a week to assemble, the lag is part of the measure. The gap narrows, because equipment at a site that was never turned up shows as an exception the day the records disagree. Order-to-activation becomes a standing figure.
Time from a control failing to somebody knowing Your last few rating, provisioning or settlement incidents: the date the fault began against the date someone was told. Down — and it governs the rest, since each of them depends on how long a wrong rule ran unnoticed. Comparisons run as the traffic arrives, so the interval is set by the process, not the reporting calendar.

Two things that make the above possible

  • Your machines

    No outside AI service reads your records

    The reasoning runs on your servers, your cloud or ours, never at an outside AI service. Subscriber records, usage detail, contracts and credentials are read where they already live. The judging model is the cluster's own inference plane — one endpoint, no API key, no vendor SDK, no fallback, and no code path that would accept an external model plane.

    What you would notice
    Call-detail and subscriber data sits under telecoms privacy and interception law and mostly cannot leave your estate. Measure this as the length of the security review before work can begin, and as whether a regulator's question about who saw what is answered from a hash-chained record rather than an investigation.
  • Your machines The open web

    Open-web research with no vendor account behind it

    When something has to be checked in public — a competitor's tariff, a supplier, a regulator's notice — the search runs from the machines your plan names through a public search endpoint, and a browser on those same machines then fetches and reads the pages behind the results rather than a research service reading them for you.

    What you would notice
    A search engine sees the query, as it would from any browser. What is absent is the account. Researching a rival's bundle pricing through a vendor's paid service builds that vendor a dated record of what your commercial team was working on, under your name. Here there is no key, no contract and no per-question bill, so nothing accumulates and nothing is capped. Measure it by what your commercial team is willing to check at all.

Who you would be working with

Runink is founder-led. The person in the first meeting is the person who designed the thing being discussed — his track record, what he does here, and the means to check any of it are on the company page.

Who runs it, and how it is built

See whether it fits

Bring one comparison and the agreement that governs it — rating output against plan terms, or a month of interconnect traffic against the settlement. Half an hour is usually enough to see whether the differences that matter are the shape this finds. Bring today's figures for the measures above too; they are your baseline.

The long version of the arrangement on this page, written jointly with Logical Leap: what a finding contains, the checks it passes before anything reaches a model, how a rate is recomputed rather than accepted, and how a second judgement is formed on a separate credential. Start at the chapter on what judging means. No case studies, no customer names and no return-on-investment figures.