As usual, these changes are colour-coded in our full rate files available through the portal as below. Where your account has custom rates, these are now reflected in the rate files. Remember, if you'd like more granular prefixes (inc. NPA-NXX) or a more compact rate file, we've got you covered.

Unlike other operators, we are not passing on UK origin surcharges, relying instead on our advanced technology to protect you and us from this industry's latest sleazy money-grab. We will maintain this position as long as possible so our customers do not need to worry.

Rate files Full rate sheets with codes are now only available through the portal or from our API for active customers. Once logged in to the portal you can find them in the "commercial" section.

The SMS A-Z rate sheet is now available on our portal or via API.

Please contact our sales team if you are not a customer and would like to see our rates.

Ancillary charges (inc. SMS & fax) Our charges for ancillary services can be found here.

100% SLA Our Service Level Agreement (SLA) for our UK carrier services customers is a guarantee of 100% Simwood service availability. Read more here.

MSA Our MSA is here.

Acceptable use policy Our AUP is here.

Hardware supply schedule Our Hardware supply schedule is here.

Hosted pricing Looking for Hosted pricing? Click here.

There are two tests. Capability: do they have what you need, already built, or are you going to build it? Alignment: does their growth depend on winning the same end customers you are trying to win? They are independent, and a supplier has to pass both.

The capability test

If all your supplier sells is lines and minutes, you are going to build everything else. The fraud controls, the number management, the recording, the analytics, the AI layer your customers have started asking about and your roadmap has already slipped. You will build all of it while paying a company whose job it was to have built it once, properly, for everybody.

They are not withholding a roadmap out of spite. I wrote about this two years ago and I would struggle to point at much that has changed since. The people who sold lines and minutes in the nineties are selling the same thing over SIP.

Before you get that far, check whether they have any infrastructure at all. A good number of the companies calling themselves carriers are reselling somebody else’s, and this is the UK, where it is reseller on reseller on reseller. If that is your situation there is a chain behind your supplier and you probably cannot see the top of it. You know who invoices you, which is not the same as knowing whose network you are on.

The alignment test

Now ask where the money you pay your supplier goes. If they also sell direct, or through partners of their own, it goes into a business competing for the customers you are chasing. They can also see your volumes, your growth and your seasonality, because carrying your traffic is how they find out, and in some arrangements they can see which of your end customers holds which number. Some of it you hand over deliberately, because you have to: emergency service records and porting requests are the obvious examples. The rest accumulates as traffic flows and numbers are allocated and ported. Either way your supplier holds a current picture of who your customers are and which numbers are theirs, and no step of it ever felt like handing over a customer list.

None of this requires anybody to behave badly. It is structural.

And it is not only your immediate supplier. In a chain, the conflict may sit two layers above the logo on your invoice, with an operator you have never contracted with, who can see your traffic because it passes through them, and who is chasing your customers with a sales force you have never met. Your supplier may be entirely innocent and entirely powerless, which does not help you.

Now try saying all of that out loud to your NED, your PE backer or your VC. Our strategy is to take share from that company. We fund them out of what our customers pay us. They can see who our customers are. And they turn up across the table in our own pitches. Nobody defends that arrangement out loud, which is why it survives: it is never said to anyone whose job is to ask.

Where we sit, and what it has cost us

The question underneath the alignment test is whose platform the service runs on: yours, in which case you buy carriage and numbering and build the rest yourself, or your supplier’s, sold either under your brand or under theirs. Everyone in this market sells some of each. The weighting is the thing, so here is ours next to our purple radioactive friends’, cut on that axis.

The white-label band in the middle of ours is our platform, sold through partners. It is fully white-labelled, but every supplier says that. The end customer sees your name on the product, the portal, the invoice and the support. We send through your own SMTP servers, so we do not appear in the mail headers. Our apps are named anonymously enough that a good number of the people using them do not know they exist as our products at all.

We want no inbound from those end users and no word of mouth, which is why it is built this way. Years of product work has gone out under other people’s names, and the recognition it earned sits with our customers rather than with us. That is the cost, and we keep choosing it.

Our engineering goes into the layers underneath: the fraud controls, the numbering, the recording, the nuisance call handling that protects your customers’ customers, and the Conversation Intelligence and AI voice work Charles’s team has shipped. You put your own name on all of it.

What we build carries no trace of us to the end user, and the relationship goes to whoever sold it. We have done that for years. That is not a claim to be incapable of anything else: there is a direct band on that graphic, and we hold your traffic data, as does anyone carrying it. Weigh the record rather than the promise.

So

Email your largest supplier today and ask, in writing, whose network your traffic ends up on, who else is in the path, and what they are building next year that you are currently scoping to build yourself and already paying them for.

It is a fair question from a paying customer. If what comes back is a rate sheet, you have your answer to both tests.

Then ask us the same thing.

Here is the short version, for the busy. Your telephone company will shortly be required by law to inspect the contents of your private text messages, check them against a list you will never see, and destroy the ones that match. Nobody has to tell you it happened. If the operator later works out it should not have done it, nobody has to deliver the message, and nobody has to have kept it. You are left with a right to challenge a decision you were never told about.

That reads like hyperbole. It is a summary. What follows is twelve pages, near enough, of receipts: rule numbers, paragraph references, and Ofcom's own words in Ofcom's own documents. The statement runs to 195 pages before you reach the separate guidance, the part that matters is buried in section 7, and the part that settles the argument is the legal instrument bolted on at the back, which is where I eventually found what this actually does. I make no apology for the length. If you read one section, make it the second.

On 15 July, Ofcom published its statement on combatting mobile messaging scams. I have read it, all of it, down to the legal instrument at the back, so that you do not have to, and I can report that somewhere in the drafting a perfectly sensible objective, namely fewer grandparents being fleeced by a fake parcel-delivery text, has been dressed up in the machinery of a surveillance state and sent out into the world with a straight face.

Regular readers will know two things about me. First, that I make my living in the dark compliance arts and have a weakness for a defined term, or, sometimes, for the wonderful world of the ordinary and natural meaning of an undefined one. Second, that I have said, repeatedly and at tedious length, that Ofcom is a child of Parliament. It does not wake up in the morning and decide to be sinister; it executes the will of a Government that would very much like to be seen to be Doing Something about fraud. So this is not a piece about a rogue quango. It is a piece about method, and about the quiet erosion of a principle that ought to survive contact with even the worthiest of causes.

Know Your Traffic

Let me start with the language, because Orwell would have. We already have KYC, Know Your Customer, which is sensible, and which we at Simwood do with rather more rigour than the rules demand. The statement now blesses us with a sequel, KYT, Know Your Traffic: an ongoing obligation to review account activity, monitor volume patterns, watch for new or unusual use of Sender IDs, and investigate what turns up.

I have no quarrel with any of that, and it is important to say why not. KYT attaches to A2P messaging only, the commercial channel, where businesses contract with providers to send appointment reminders and delivery updates. It is a duty about business traffic, it looks at behaviour, volumes, and patterns rather than at what anybody wrote, and we do it already. If the statement had stopped there, this would be a short and rather boring blog.

It does not stop there. There are two blocking duties in this statement, not one, and almost every summary I have read collapses them into each other. The difference between them is the whole point, so let me set them out precisely, from the instrument itself rather than the press release.

The envelope, not the letter

Here is the distinction that matters, and the one that keeps this blog honest. Everything Simwood does today to shun north of 5% of the calls on our network operates on behaviour and metadata. We look at invalid CLI, at dead-number ratios (our beloved UAP), at dialling patterns that no human hand produces, and at what our own systems flag when a suballocated number starts misbehaving. We look at the envelope, not the letter. We have never needed to steam open the correspondence to work out that something is a war-dialler.

Now watch the new rules draw exactly this distinction, and mandate both halves of it. A word on citation, because precision matters here and General Conditions are amended more often than anyone outside this trade would believe: everything I quote below is General Condition C9, as imposed by the Notification at Annex 1 to the 15 July statement. It is not yet in force and it is not what the General Conditions say today. GC C9.3(b) requires providers to block P2P messages sent from telephone numbers they reasonably believe have been used to scam. That is the envelope: who sent it, judged on intelligence about the sender. It is what a careful operator does, and I have no complaint. Then comes sub-paragraph (c), and I am going to quote it in full, because I want no argument about what it says. Providers must “block, via automated means and without undue delay, P2P Messages that contain URLs or Telephone Numbers which they reasonably believe were used as part of a Scam”.

Sit with the word contain for a moment. You cannot know what a message contains without inspecting its contents. All of them, every message, every time, because the offending URL could be anywhere in it. And note the channel. P2P. Person-to-person. The instrument defines it as “a message sent from one SIM to another”, which is to say the text you send your mother. The commercial channel gets the mirror-image duty at GC C9.7. Private correspondence is not the exception to this regime. It is half of it, and, as we shall see, the half that arrives first.

I can hear the answer, so let me make it for them, because it is the best one they have. This is not really reading. Ofcom itself describes what it mandates as, in effect, an exact database matching tool: a lookup against known scam URLs and numbers, with no human required to read anything and no machine interpreting your prose. That is true. It is narrower than the worst thing I could have accused them of, and I am not going to pretend otherwise. It is also beside the point. To find a URL in a message you must parse the message. The narrowness is in what the machine is looking for, not in what it opens. Every envelope is still slit. The clerk simply has a short list and no curiosity.

And Ofcom knows the clerks are already curious, because it says so in the plainest sentence in either document. The guidance states that these are minimum measures, that providers may go further, and that going further expressly includes monitoring messages nobody has reported at all, on probabilistic rules, hunting for anything that looks suspicious. Our rules, it says, neither require nor prevent this. It adds, correctly, that such monitoring is likely to be more intrusive. Then it moves on. The mandate sets the floor. The ceiling is left precisely where it was, and Ofcom has written down that it is leaving it there.

And I know exactly what comes next, because it is what always comes next: if the industry is already doing this, what precisely is your complaint? Three things. Industry practice is not a legal justification, which we put to Ofcom in January in rather blunter terms than that, and which I return to below. What was the practice of some is now the duty of all, including providers who until this moment have only ever looked at the envelope. And whatever the tooling, a regime whose transmission guarantee has been watered down and whose notification duty has been deleted outright is a different animal from one where neither was ever on the table. Narrow tooling does not make a wide mandate narrow.

Mum, it's a scam

Let me make this concrete, because the abstraction flatters it. You text your mother: Mum, whatever you do, do not ring 0330 123 4567, it is a scam. That number is on the list, as by definition it would be, or you would not be warning her about it. Your message therefore contains a telephone number reasonably believed to have been used as part of a scam. C9.3(c) is satisfied. Blocked, by automated means, without undue delay.

Your intention has nothing to do with it, and that is a drafting choice rather than an oversight. Sub-paragraphs (a) and (b) of the same condition both turn on messages intended to Scam the intended recipients; the words are right there on the page. Sub-paragraph (c) carries no such qualifier. The intent test attaches to the number's history, not to your message. And the tool Ofcom has specified, an exact database match, is by design incapable of noticing the word not.

Now, before anyone tells you this is a clever gotcha that Ofcom never considered, it is not, and I want to give them full credit, because the passage is buried in Annex 4 where almost nobody will look. Ofcom sets out the scenario in terms: an individual may copy a scam URL or telephone number to send to a friend, to warn them about a scam. It accepts the message may be blocked. It accepts, expressly, that this interferes with the right to freedom of expression. They saw it coming.

It is the answer that should stop you. Having accepted that your warning will be destroyed, Ofcom reasons that this should not much matter, because the actual scam message containing that same number would also be blocked, so your mother is protected anyway. The warning is redundant, because the danger has already been dealt with.

Hold that against what Ofcom wrote back near the front of the same document, in its own account of how these crimes actually work. The scammer makes first contact by text, and then, in Ofcom's words, may ask the victim to communicate with them using an online messaging app such as WhatsApp or Facebook Messenger. Those are number-independent services. They live under the Online Safety Act, not the Communications Act, and nothing whatsoever in this statement reaches them. So the redundancy argument holds inside one channel only, and Ofcom's own description of the crime has the criminal leaving that channel at the second step.

Follow it all the way through, with your mother rather than with a defined term. The approach comes at her on Facebook, or on WhatsApp, or by email, or as a voice call from the very number you were trying to warn her about, because it is a telephone number and telephone numbers are for ringing. In none of those places has anything been blocked. In none of them does the protection Ofcom is relying on exist at all. The one channel where the danger was neutralised is the one channel where your warning was destroyed, and it was destroyed precisely because it named the danger accurately.

That is the shape of it. The blocking works where the criminal has already gone. The silence works where your mother still is.

And the guidance goes further than the statement let on, so let me put that on the table too. Buried among the validation steps, operators are asked to consider whether and how it may be possible to identify messages where an individual copies a scam URL or telephone number to send to a friend, to warn them about a scam. They are also invited to consider quarantining messages they cannot confidently classify either way, holding them back so somebody can look before anything is destroyed. That is a real thought, properly had, and I would rather credit it than pretend it is not there.

Now read the verbs. Providers must block, via automated means, without undue delay. Providers should consider whether and how it may be possible to spot a warning. One of those is a duty and the other is an invitation to have a think, and both are pointed at the very same message. The only other protection on offer is the one I mentioned a moment ago: take appropriate steps to ensure the end-user's number is not blocked. The number, not the message. Nobody, anywhere, is told to deliver the warning.

And that is the pattern, once you have seen it. What binds is the Notification at the back, and nothing else. Every acknowledgement that this might go wrong, every mitigation, every reassurance that somebody will be thinking carefully, lives in the reasoning or in the guidance, which is to say outside the only text a tribunal would be reading. The duty to block is in the rule. The care is in the commentary.

And two paragraphs before that, the same annex says something which cannot stand beside it. Blocking messages that contain scam URLs or telephone numbers, Ofcom says, does not engage Article 10 at all. Then, two paragraphs later, the warning message, which contains a scam telephone number, is blocked and does interfere with freedom of expression. Same annex, same measure, same morning. They cannot both be right, and the reason they collide is the drafting gap I have already described: because sub-paragraph (c) never asks about intent, the category it creates holds scams and warnings alike, while the rights analysis treats it as though it held only scams.

Whether your destroyed warning even counts as a False Positive is, at best, unclear. The defined term speaks of a message incorrectly identified and blocked on the basis the provider reasonably believed it was intended to scam the recipient, which is a belief sub-paragraph (c) neither requires nor forms. Annex 4 plainly assumes warnings are caught by the false positive machinery, and I hope it is right, because a great deal rests on it. But the definition does not say so, and the definition is what a compliance team will read.

So run the sequence, on either reading. Blocked automatically. Not notified, because that duty was lobbied away. No duty to deliver it once anyone works out what happened, and no duty even to keep it, since Ofcom confirms providers need not retain blocked messages at all. And a right to challenge which you will never exercise, because you do not know there is anything to challenge.

And note that all of this is the mandated floor working exactly as designed, with an accurate list and a correct match. Now consider the ceiling, which nobody regulates. Ofcom's own footnote records that operators already review messages against a broad set of scam indicators, including phrases such as “Hi Mum”, and observes, correctly, that such probabilistic methods are by their nature less precise and produce more false positives. Ofcom neither requires this nor forbids it. It is also, and I feel faintly ridiculous having to write this down, the most ordinary way in the English language to begin a message to your mother.

So there are two layers here, and they fail in opposite directions. The mandated one blocks you warning your mother about a scam, and does so correctly. The unmandated one blocks your child saying hello, and does so incorrectly. Neither of you is told about either.

If you think I am overreading the instrument, take it from its author. Ofcom's Article 8 assessment of these measures, the P2P measures, not the business ones, accepts that they may interfere with the right to privacy, because we expect mobile operators will need to use technology to review the content of private messages. The next paragraph lists the possible harms, and one of them, in Ofcom's own words, is unwarranted surveillance. Their phrase. Their document. Their rules.

And one more detail from the scope provisions, the one that moves this piece from commentary to confession. The content-blocking duty does not fall on “the MNOs”. GC C9.1 applies it to any communications provider that transfers or terminates P2P messages. That includes us. The company whose entire pitch, in this very blog, is that we look at the envelope and have never needed to steam open the correspondence, will from 18 January 2027 be required by law to open it. I am not describing something other people will do to you. I am describing something we will be conscripted to do to you, on pain of enforcement, and I would rather tell you that plainly now than have you discover it later and wonder why I did not.

What Ofcom removed, and who asked for it

If content inspection were the whole of it, I could almost live with it, because a careful operator can do careful things. What I cannot live with is what happened between the consultation and the statement, and who asked for it.

Ofcom consulted on two safeguards, and their reach was the reach of the blocking itself: both attached to automated blocking under GCs C9.3(b), C9.3(c), and C9.7, private and commercial alike. The first was a duty on providers to take steps to stop legitimate messages being caught in their own blocking tools. The second was a duty to tell senders when a message had been blocked. Both are gone.

On the first, the objectors are a roll-call: BT, Sky, Virgin Media O2, VodafoneThree, Mobile UK, and UKCTA. The arguments were that no failure to deliver legitimate messages had been demonstrated, that operators already have every commercial incentive to deliver, and that a duty to carry sitting alongside a duty to block would leave operators walking a tightrope with a penalty waiting on either side. BT went furthest, and said Ofcom was attempting to offload its own Human Rights Act duty onto private operators. Ofcom agreed. An up-front duty to get legitimate messages through became an after-the-fact duty to identify, monitor, and address erroneous blocking.

Orwell's real subject was never the surveillance. It was the language that makes surveillance sayable. He wrote that the great enemy of clear writing is insincerity, and that when there is a gap between what you are doing and what you are prepared to say you are doing, you reach instinctively for the longer word. So read the two formulations again. Ensure the transmission of legitimate messages: six words, every one of them concrete, and you know on reading it who owes what to whom. Identify, monitor, and address instances where messages are blocked in error: longer, softer, and nobody owes you anything. The first is a promise. The second is a process. The same people wrote both, about the same problem, within nine months.

That replacement is a real obligation and I will not pretend otherwise. But look at what it does not do. Where an operator discovers that it destroyed your lawful message in error, Ofcom does not expect it to then deliver the message. The stated reason is that doing so could cause confusion. So the remedy for having your correspondence wrongly destroyed is that the operator performs a root cause analysis and tries not to do it to somebody else. Restoration is not forbidden, to be fair: a provider may unblock where appropriate, Ofcom says, for example following a challenge under GC C9.17. Which is to say the route back for your wrongly destroyed message runs through the challenge you were never told you had grounds to raise. Failing that, you are invited to use some other means of communication.

There is a word for a message that is destroyed, whose contents are nowhere preserved, and which is not restored even once the destruction is admitted to have been a mistake. He gave us that one as well. The memory hole was never a device of malice. It was a device of tidiness.

On the second, the same names. BT, Sky, Virgin Media O2, and VodafoneThree all told Ofcom that notification would be disproportionate, because most blocked messages are scams anyway. I will give the tipping-off argument its due, because it is a real one, and because it is ours as much as theirs: tell a sender their message was blocked and you have handed the scrotes a Haynes manual on bypassing the block, complete with torque settings and an exploded diagram. It is precisely why we publish what we block without publishing how we decide. Had that been the whole of it, I would not be writing this section. But BT also costed it, and told Ofcom that a notification duty would add to its termination payments, and that other providers might drive up notification volumes to harvest the revenue. Note what it costed. Its estimate was framed for P2P messages alone. So the inter-operator payments argument that helped see off the safeguard was costed against private correspondence between individuals, and the safeguard died for both channels.

And then there is the evidence. An earlier draft of this said we were not shown it. That was wrong, and the truth is worse. Ofcom went back to providers in May and asked how often they block legitimate messages by mistake. The providers reported that they hardly ever do: somewhere between never and about once a month. On that basis, Ofcom decided a duty to tell you was not worth the candle.

Now read Ofcom's own footnote to that evidence. The figures are largely built out of complaints. No provider actually measures how often it wrongly blocks. And the rates may be under-reported, because users may not have known their message was blocked, or may not have bothered to complain.

Then read what Ofcom tells operators about hunting for false positives. They must not rely on complaints and challenges as their main method, because the number of challenges they receive may not reflect how much wrongful blocking is actually going on. They should expect to miss it on P2P in particular, for two reasons Ofcom sets out itself: end-users may not know a message was blocked, and they are in any event less likely than business senders to challenge it. Which is to say the regime knows its blind spot is deepest over private correspondence, and shallowest over the commercial traffic that has a contract and a service manager.

So Ofcom knows that complaints do not measure wrongful blocking. It says so, in terms, and writes a General Condition on the strength of it. It then uses complaint-derived data to conclude that wrongful blocking is too rare to be worth telling anyone about. The evidence that nobody complains has been used to remove the mechanism by which anyone would know to complain.

Doublethink was the term for holding two contradictory beliefs at once and accepting both of them. It was not offered as a figure of speech. It was offered as a technique. One paragraph knows that complaints do not measure wrongful blocking. Another counts the complaints and concludes that there is not much wrongful blocking. The two have never met. Both were published on the same morning, over the same name, in the same document.

So here is the finished article. Your lawful message may be inspected, it may be silently binned, nobody is obliged to tell you, and if the operator later works out that it should not have binned it, nobody is obliged to deliver it. The burden falls on you, the wrongly-blocked, to notice the silence, deduce that you have been blocked, and invoke your shiny new right to challenge a decision you were never told about. That is not a safeguard. That is Kafka with a message centre. We publish Call Quality Reports so that our customers can see what we are blocking for them. We do not publish how we decide, for the reason I gave earlier, and there is all the difference in the world between telling you a thing happened and handing over the workshop notes. Ofcom has arrived at the opposite instinct on both counts: keep the method to yourself, and do not mention that it happened either.

The cohort nobody asked about

Then there are the volume limits on pay-as-you-go SIMs, which sit in the P2P rules and bite on private messaging only. Here I must declare an interest in my own back catalogue. We told Ofcom, in writing, that we saw no issue with frustrating the bulk sending of P2P messages from PAYG SIMs, and that it was a sensible ex-ante measure at the point of entry rather than an ex-post criminal matter about the possession of equipment. I have not changed my mind. A bot firing thousands of texts an hour is not a person wishing their nan a happy birthday.

So this is not an objection to volume limits. It is an objection to a question Ofcom did not ask.

The rule bites on PAYG and on nobody else. Ofcom says so expressly: pay monthly users will not be constrained, because contracts, credit checks, and billing details make it harder for a criminal to acquire those SIMs in bulk. That is sound as far as it goes. But note why the two cohorts differ in the first place, on Ofcom's own account at the front of its statement: operators do not apply the same level of credit or identity checking to PAYG as they do to a contract. The line Ofcom has drawn is, substantially, a credit line.

Now turn to Annex 3, where Ofcom discharges its duty to have regard to the needs of, among others, persons on low incomes. Its conclusion is that it has not identified any adverse impacts on specific groups of persons likely to be affected in a different way to the general population.

I am afraid it has. A rule that applies to one tariff cohort and expressly not to the other affects that cohort in a different way to the general population. That is what the word only does. Whether the effect is material is a perfectly fair question, and the answer may well be hardly at all. But Ofcom did not ask it. It looked at a measure that bites on prepay and on nothing else, and recorded that it had found no differential impact on anybody.

It matters more than it looks, because Ofcom is not setting the limit. Each operator sets its own, on its own evidence, at whatever level it judges will disrupt scammers without stopping legitimate use. I have no quarrel with that in principle; operators know their own traffic, and a regulator picking a national number would be worse. But the consequence is that how many texts a prepay customer may send before the network stops them is now a commercial judgement, made by the operator, reviewed by nobody in particular, and applied to the one group of customers who did not, or could not, pass a credit check. That deserved a paragraph in the equality assessment. It got a line saying there was nothing to see.

And here is a question the statement never asks, which I will leave hanging because it deserves a proper answer rather than a paragraph. A great many pay-as-you-go propositions are sold on unlimited texts. That word is not Ofcom's to define: the advertising rules permit an unlimited claim only where the user suffers no additional charge and no suspension of service for exceeding a threshold, where any provider-imposed limitation is moderate, and where it is clearly explained in the marketing communication itself. Last year the ASA told EE that even a fair usage policy almost nobody ever hits is still a limitation, and still has to be spelled out. Ofcom has now required every operator to impose a hard cap on how many texts a prepay customer may send, and set it themselves. Advertising appears in this statement only as something fraudsters do; how these caps sit with what the operators' own marketing promises is nowhere considered. Somebody's marketing department is going to have an interesting fourth quarter.

The one definition they would not give

My favourite touch, and I say this as a connoisseur, is the treatment of RCS. Faced with the question of whether RCS falls under the Communications Act or the Online Safety Act, Ofcom has decided that operators are best placed to assess this in the first instance. A regulator that loves a definition almost as much as I do has, on the single question where a definition would actually help, declined to supply one and handed the parcel to the very people it regulates. Marvellous.

The shrug matters more than the joke, because that boundary is the boundary of everything in this statement. Number-based services, SMS and MMS, are regulated under the Communications Act, which is where all of this lives. Number-independent services, WhatsApp, Facebook Messenger, iMessage, are not, and Ofcom says so plainly: they use functionality that does not depend on telephone numbers, so they fall outside the Act. RCS sits on the fence. Which is precisely why nobody would define it.

The half they can reach

So hold that boundary in your head, and then read Ofcom's own account of how these scams actually work. A scammer makes first contact by SMS, and then, in Ofcom's words, may ask the victim to communicate with them using an online messaging app such as WhatsApp or Facebook Messenger. That is not my speculation about what criminals might do once the pipes are watched. It is the regulator's own description of the standard journey, and the second leg of it lies outside the scope of every rule that follows.

Now look at the number doing the heavy lifting at the front of the statement. Forty per cent of UK mobile users report having received at least one suspicious message in the past three months. It is an alarming figure and I do not dispute it. But read the footnote under it. Suspicious messages there means messages arriving in the phone's default messaging app, which is to say via SMS, RCS, and iMessage. iMessage is out of scope. The harm has been measured across a wider set of channels than the remedy can reach, and nobody closes the gap between the two.

And here is the thing I went looking for. Ofcom does think about displacement, once, and the once is instructive. Utility Warehouse warned that capping pay-as-you-go would simply push the scammers onto pay monthly SIMs. Ofcom's answer is genuinely good: it will not, because acquiring pay monthly SIMs at scale is hard. The contracts, the credit checks, the billing details. Displacement, in other words, is defeated by acquisition barriers, and by nothing else. Hold on to that, because it is the only displacement analysis in the document, and it cuts the other way the moment you step over the fence.

Because the industry asked the over-the-fence question too. VodafoneThree and Utility Warehouse told Ofcom, in terms, that increased regulation of A2P messaging risks displacing fraud to other platforms. The statement records the concern, turns to the question of costs, and never comes back to it. I have looked for the answer and I cannot find one. So the one analysis we do have says scammers move unless the next channel is hard to get into, and the next channel here is WhatsApp, whose acquisition barrier is an app store and thirty seconds. On Ofcom's own reasoning, we know exactly where the traffic goes. Nobody has asked what the apparatus is worth once it has gone there.

Consider who can move and who cannot. A criminal enterprise can shift from SMS to an encrypted app for nothing, over an afternoon, and it has every incentive to. We have watched scrotitude migrate from carrier to carrier for thirty years, and it remains remarkably light on its feet. The people who cannot move are the ones for whom SMS simply is the messaging service: no smartphone, no data allowance, no app, or no inclination. They are, and this is not a coincidence, the same cohort we met earlier, the prepay customers whose volume limits nobody thought to assess for differential impact. So the apparatus is built on the one channel the least equipped cannot leave, to catch people who can leave for free, and it will still be running long after they have gone.

Let me forestall the obvious rejoinder, because I can hear it coming. I am not asking Ofcom to extend any of this to WhatsApp, and I would fight it if it tried. My point is the reverse. When a remedy can only reach half the problem, and the half it reaches is the half where the intrusion is deepest and the escape is cheapest, that is the strongest argument yet that this balance was never Ofcom's to strike. A sectoral regulator can only act inside its own statute, so it acts where its statute reaches, whether or not that is where the harm will be tomorrow. Parliament can look at the whole landscape at once, weigh the intrusion against the displacement, and decide whether the trade is worth making at all. Which is exactly what we told Ofcom in January.

Surveillance, outsourced

And here is the part that should trouble you whatever you make of the rest. Strip away the packaging and this is state-sanctioned, private-sector surveillance of private correspondence, at national scale, and I can find no politer word for it than vile.

Consider what the state itself may not do. It cannot read your post, or listen to your calls, on a whim. When it wants the content of your communications it must go through the Investigatory Powers Act: a warrant, a threshold, a Secretary of State, independent oversight, and a judge. That architecture exists precisely because reading a citizen's correspondence is understood to be one of the gravest things a state can do to its people, so it is fenced about with safeguards.

This statement reaches the same intrusion and quietly steps around every one of those fences. It does not have the state read your messages. It conscripts your telephone company to do it, continuously, on everything, with no warrant, no suspicion, no oversight of the list your words are being checked against, and no judge within a mile of it. You get the intrusion of state interception, delivered with none of the discipline of state interception, and dressed up as consumer protection. Worse, the private conscript has every commercial incentive to over-block. The duty to carry your lawful message was struck out at the industry's request, what replaced it does not oblige anyone to deliver a message they have worked out they wrongly destroyed, and no one has to tell you that any of it happened. All of the snooping, none of the due process, and a Terms of Service where a warrant used to be.

I am not the only one uneasy about this, and I am nowhere near the shrillest. Amnesty International UK responded, and I should say plainly that they are more relaxed about the scanning than I am. They told Ofcom that mandatory scanning is rightly confined to a closed list, and that they did not find the proposals excessively problematic, in part because number-based messaging like SMS already carries low expectations of privacy, given the legacy constraints and the mandatory law-enforcement access built into these systems long ago. They are quite right that this is how it is. I would only say, as we said to Ofcom in January, that the length of time a thing has been done is not an argument that it ought to be. The envelope has been opened for thirty years. Thirty years of opening it has never once been a reason.

What Amnesty was worried about is the part I am worried about, and they got there before me. That the industry-standard filter already advertises AI and pattern analysis rather than the list Ofcom mandates. That the consultation nowhere discusses how any of this sits alongside the surveillance and intelligence powers we already have. That the new mandatory datasets could open fresh vectors for surveillance under bulk powers. And, in terms, that the infrastructure once built could be turned by the security services on URLs and numbers with nothing to do with scams, a point they thought worth making out loud given where this country currently sits on protest and dissent. United Nations experts got a mention. Their central recommendation was that Ofcom should not lean on generic data protection rules, and should define the purpose limits properly, because generic compliance with GDPR is not enough in 2026.

Ofcom's answer, in substance, is that it consulted the Information Commissioner and is satisfied the measures can be implemented in accordance with data protection law. Told that generic data protection would not hold the line, it confirmed that generic data protection was satisfied.

We should be very slow indeed to build this, because machinery outlives the intentions of the people who commission it. A tool built to catch a fake bank text is, mechanically, a tool that reads everyone's texts and drops the ones on a list. Change the list, and you change the target, and the second change is a great deal quieter than the first. We asked ourselves, in Are we evil?, whether we should wield rather less power than this. It is telling that Ofcom has mandated rather more, and asked itself rather less.

Made by no one you elected

Which brings me back to where I always seem to end up. None of this arrives as an Act, debated by people you can vote out. It arrives as guidance and General Conditions, drafted by an unelected regulator, which the industry will treat as law because the alternative is enforcement. I have written before of my fondness for the quaint American notion that lawmaking belongs to those closest to the People, and for the older instinct that it should be kept out of the hands of arbitrary decision-making by unelected nobles. You do not have to be a card-carrying libertarian to feel the hair on your neck rise when the power to inspect, and to silently suppress, private correspondence is created in this way, for the best of reasons, with the safeguards filed off somewhere between the consultation and the statement.

And I did not merely feel it, we filed it. Our response to this consultation, dated 28 January, told Ofcom that the balancing of over-blocking against fraud against invasion of privacy is a matter for an elected Parliament and not a sectoral regulator, and that the mere fact of today's industry practice proves neither that privacy rights have been upheld nor that what happens today is lawful. Ofcom's published answer to the first point runs to a single paragraph, and I will summarise it fairly: Ofcom has various duties relating to telephone numbers, including specific powers to make rules about mobile messaging, and it took them into account. That is a competent answer to the question are you allowed to. It is not an answer to the question should this be you. The second point, that industry practice is not proof of lawfulness, is recorded in the statement and answered nowhere, while the argument it was aimed at survives intact and is deployed more than once in support of the finished rules.

And look at who did the asking. Of the three mobile networks left in this country, Virgin Media O2 is owned outright by a Denver-run holding company incorporated in Bermuda and by Telefónica of Spain, behind which sit the Spanish state and Saudi Telecom. BT and Vodafone are British-incorporated, British-listed, and British-run, and their largest shareholders are an Indian conglomerate and, until last week, Abu Dhabi's state telecoms company. Sky, which is not a network at all but rides on Virgin Media O2, belongs to Comcast of Philadelphia. And VodafoneThree, our largest network, is forty-nine percent owned by CK Hutchison of Hong Kong until the sale to Vodafone completes later this year.

Hold that last one, because it is the most instructive thing I can offer you. When Li Ka-shing's conglomerate proposed to take a minority stake in a British mobile network, the machinery of the British state woke up. Two years of scrutiny. A review under the National Security and Investment Act. A Secretary of State. Binding mitigations, including a national security committee inside the merged company. Debates in the Commons. That is what it looks like when this country decides that something touches its interests: an Act, a Minister, and somebody you can hold to it.

Now count what it took to decide that those same networks may read the content of your correspondence and bin it without telling you. One consultation, one regulator, and one paragraph in reply when we asked whether it should be Parliament's call at all. We will spend two years deciding whether a Hong Kong billionaire may own half a network. We will spend an afternoon deciding what the network may read.

A floor is not a safe harbour

One more thing before I sum up, briefly, because it belongs in a different piece and I intend to write that piece. The record-keeping conditions require providers to keep false positive records for at least two years, challenge correspondence for at least one, and KYC and KYT material for at least three after the relationship ends. Note the words at least. Those are floors. I already suspect some will file them as ceilings, delete on schedule, and feel diligent about it.

Because here is what sits on the other side of the ledger. Under section 104 of the Act, the obligation to comply with a General Condition is a duty owed to every person who may be affected by a contravention, and a breach of that duty which causes someone loss is actionable by them. There are gates on it, and I will not pretend otherwise: Ofcom's consent is required, and a provider that took all reasonable steps and exercised all due diligence has a defence. But the ordinary limitation period for a claim of that kind is six years, and nothing puts an equivalent long-stop on Ofcom's own enforcement, which is administrative and not an action under the Limitation Act at all.

So line the numbers up. Two years of records. Six years of civil exposure. No outer limit on the regulator. And no requirement to retain the blocked message itself, which Ofcom confirms and justifies on data minimisation grounds. Add the missing notification, and the person who was wrongly blocked may not discover it for years, if ever, so their clock starts long after everyone's evidence has been lawfully shredded.

Which leaves the operator somewhere genuinely uncomfortable, and this is the part that ought to concentrate a few minds in compliance departments. You will be told what to keep and for how long. You will be told you need not keep the message. And you may then be asked, years later, to account for a decision you no longer hold the evidence to defend. Complying with the minimum is not a defence. It is simply a tidier way of having nothing to say for yourself. That deserves a piece of its own, and it will get one.

To be clear

Let me be unambiguous, because I fully expect to take fire from both directions for this, and I would rather choose the words that get misquoted. The scrotes will wave this blog about as cover for carrying on regardless, and the virtue-signalling luvvies who cheerlead every draconian intervention going will brand me an apologist for fraud. Both will quote me selectively, and neither will be right. Fraud is real, it does grievous harm, and stopping it is both the will of Parliament and a matter of basic decency. We do not need Ofcom to tell us to fight it; we jettison revenue every month doing exactly that, and we would happily do more if the rest of the industry would stop talking and start acting. My objection is not to the mission. It is to a design that deputises private companies, ours now among them, to read the content of lawful messages, block them in silence, with the duty to carry the legitimate ones traded away on request and nobody told when they are dropped, all of it authored by a body that no one elected.

Get those five things right and I will be first in the queue to help. Get them wrong, and this statement will be remembered less for the scams it stopped than for the precedent it set.

One last thing, and it is the tell. The rules come into force in two waves. The A2P rules, the ones about commercial messaging sent by businesses that can be identified, contracted with, and held to account, are given twelve months, and bite on 15 July 2027. The P2P rules, the ones that reach into private correspondence between individuals, are given six, and bite on 18 January 2027. Whatever the operational logic, the effect is that the more intrusive half arrives first and gets half the time to prepare. There is still time to do this properly.

Source: Ofcom, Statement: Combatting mobile messaging scams, 15 July 2026. All General Conditions cited in this piece are General Condition C9 as imposed by the Notification at Annex 1 to that statement, dated 15 July 2026, and not as the General Conditions read today.

There is an understandable desire to build.

Build the new voice capability. Build the messaging platform. Build the AI integration. Build the carrier connectivity. Build the APIs. Build the compliance layer.

After all, building creates ownership, control and differentiation.

But there is another side to the equation that isn't discussed nearly enough.

Every engineering sprint spent recreating infrastructure that already exists is a sprint not spent building the features your customers will actually pay for.

The Hidden Cost of "Build"

Building communications capabilities is rarely as simple as it first appears.

Beyond the initial development effort comes the ongoing reality of operating carrier infrastructure, maintaining resilience, managing fraud, handling compliance, supporting numbering, monitoring quality, integrating with multiple networks and continually investing as the market evolves.

None of these activities are what make a UCaaS business unique.

They are simply the foundations that enable it.

Yet they consume engineering resources, product investment and valuable management attention.

Perhaps the biggest cost, however, is one that rarely appears in a business case.

Time.

Every month spent building is another month before customers can buy.

Another month before revenue starts flowing.

Another month where competitors can launch first.

Speed is Becoming a Competitive Advantage

The communications market has changed dramatically.

Customers no longer wait years for innovation. They expect continuous delivery of new capabilities, whether that's AI voice, conversational intelligence, WhatsApp, compliance features, analytics or new routing options.

Being first - or simply being early - creates commercial momentum.

Being late often means competing on price.

The companies that consistently win are not necessarily those with the biggest engineering teams.

They are often the ones that recognise where they should innovate themselves, and where partnering allows them to move faster.

Build Where You Differentiate

Every technology company should invest in its intellectual property.

But the question every leadership team should ask is:

"Is this capability what our customers buy us for?"

Customers choose UCaaS providers because of the user experience, integrations, workflows, AI capabilities, customer support and overall value delivered.

They rarely choose a provider because it built its own carrier network, numbering platform or voice infrastructure from scratch.

Those capabilities matter enormously, but they are enablers rather than differentiators.

The greatest return on engineering investment often comes from focusing developers on customer-facing innovation rather than rebuilding core communications infrastructure.

Partnership Accelerates Innovation

The best partnerships are not about outsourcing innovation.

They're about accelerating it.

By leveraging proven communications infrastructure, providers can introduce new services in weeks instead of months, reduce technical risk and keep engineering teams focused on creating experiences that customers genuinely value.

Instead of asking, "How do we build this?"

The better question may be:

"How quickly can we bring this to market?"

In today's market, speed creates opportunity.

Opportunity creates revenue.

Revenue funds further innovation.

That cycle is difficult to achieve when engineering teams are tied up rebuilding capabilities that already exist.

The Commercial Impact

Choosing to partner doesn't just reduce technical complexity, it changes business outcomes.

It can help organisations:

• Launch new services faster.
• Generate revenue earlier.
• Reduce upfront engineering investment.
• Lower operational complexity.
• Respond more quickly to changing customer demands.
• Stay ahead of competitors entering the market with new capabilities.

Most importantly, it allows businesses to focus on the innovations that truly differentiate them.

Where Simwood Fits

At Simwood, we've spent decades building the communications infrastructure that powers voice.

Today, that foundation extends beyond traditional carrier services into programmable communications, WhatsApp messaging and voice, AI-ready voice, conversational intelligence, numbering, compliance and global connectivity.

Our role isn't to replace your platform.

It's to help you expand it.

By providing the underlying communications capabilities as a trusted partner, we enable UCaaS providers to bring new products to market faster while keeping their engineering teams focused on the innovations that create lasting competitive advantage.

Because in a market that moves as quickly as communications, success is rarely about who builds the most.

It's about who delivers value to customers first.

Start with why a marketing operation has to show you a number at all. It is not decoration, it is accountability. The rules make a marketer present a contactable line so that you, the person on the receiving end of a call, can work out who rang and ring them back. Being reachable is the price of being allowed to call strangers.

Now watch it unravel, quietly and entirely within the law. You ring the number back, and because you have had quite enough of these calls, you withhold your own number. You are perfectly entitled to; that privacy choice is protected, and not only by PECR but within the CLI rules themselves. The marketer's platform sees an anonymous inbound call and rejects it. Anonymous Call Reject is a legitimate feature, older than most of the people now leaning on it. And the presented number is still, in the technical sense, dialable. We would know, diallability is our day job, and a number sitting behind ACR can pass our dips when we present a CLI.

So each individual piece is lawful. The number is presented. The number is dialable. The caller may withhold. The recipient may screen. And yet the one outcome the presentation rule exists to deliver, that you can actually reach the people who rang you, has been quietly engineered away. Worse, it has been engineered away for exactly the people the rule is there to protect, because those most likely to call back with a withheld number are the ones complaining or opting out, and who would rather not hand their number to the very operation that just interrupted their dinner.

The gap is not technical, it is in the spirit

This is not a diallability problem, and we want to be careful about that, because the reflex is always to reach for a technical fix. There isn't one to reach for. The number works, technically. The letter of the rules is satisfied. What is defeated is their object, and that is a harder and more interesting problem than a malformed prefix. A party that is under a legal duty to be reachable is using a legitimate feature to be selectively unreachable, and it has chosen to be unreachable to precisely the people the duty was written for.

What we have done about it

We have put the question to Ofcom, plainly. Not as a formal complaint, because in law there is nothing obvious to complain about, but as a gap between letter and spirit that someone holding the pen should probably look at, whether that turns out to be a line in the CLI Guidance, a tweak to C6, or a quiet word with the ICO, who own the marketing end of this.

We would always rather surface these things and get them closed than leave them sitting there as an unadvertised technique for the scrotes who collect such techniques. Confidence in CLI is built one boring, unglamorous fix at a time. Consider this one more of them, and another action taken by a network that genuinely wants to do something positive for society about the subject matter.

Here's the headline: you shouldn't notice anything.

What's actually changing

Under the hood, this is one of the more significant changes we've made to the portal in years. Login moves from our own custom flow to an industry-standard OpenID Connect service running at auth.simwood.com, built on the same battle-tested open-source foundations trusted by banks, governments, and Fortune 500s alike.

When the switch happens, the login page will look a little different (same Simwood branding, new address), and that's the extent of it:

• Your email and password work exactly as before. No reset, no re-registration, no "welcome to the new system" email demanding action.
• Your two-factor authentication carries over. If you use an authenticator app today, the same app and the same codes keep working.
• Everything in the portal behaves as it did. Same features, same account, same permissions.

Credentials migrate with you, and your existing password is brought up to the new platform's standard the first time you use it. The best migrations are the ones you never notice, and we've engineered this one to be exactly that.

Why bother, then?

Because what you don't see matters, and because of what it unlocks.

The new flow is built on the OAuth 2.0 Authorization Code flow with PKCE - today's standard for browser-based login - with short-lived access tokens, refresh tokens in httpOnly cookies the browser's JavaScript can never read, and central session management so a revoked login is revoked everywhere, immediately. Your portal session now carries the same granular scopes as our API keys, so one consistent permission model governs every request that touches the platform, whether it came from a script or a person.

Managing your login remains self-service, now through a dedicated account console - change your password, manage two-factor authentication, and, new this time, review and revoke your active sessions, all without a support ticket.

But the bigger reason is where this takes us next.

What it unlocks

Our old login flow was ours alone, which meant every improvement to it was ours to build alone. Standing on an open standard changes the economics entirely. On the roadmap, in rough order:

• Passkeys. Passwordless login using the biometrics already on your device - Face ID, Touch ID, Windows Hello, or a hardware key. Phishing-resistant by design, and faster than typing a password ever was. This is the one we're most excited about, and the new platform supports it natively.
• Sign in with the identity you already have. Google, Microsoft, and GitLab to begin with - handy for teams who manage access centrally and would rather not maintain another password at all.
• Finer-grained roles for your team. Today it's owners and users; the same scope model that powers our API keys lets us offer more precise roles over time, so you can grant a colleague exactly the access they need and nothing more.

None of these were realistic on the old system. All of them are natural extensions of the new one.

What you need to do

Nothing. That's the point.

The switchover is imminent. When it lands, log in as normal; if you're curious, the only tell will be the address bar reading auth.simwood.com for a moment while you sign in. As ever, if anything doesn't behave as promised, our support team wants to hear about it - but we've tested this one to the point where we'd be surprised.

We said earlier in July that authentication was being done right. This is what that looks like when it reaches the portal: a foundation you can't see, carrying features you'll soon be very glad of. Watch this space!

Every day, tens of thousands of calls try to cross our network and don't make it. Not because of congestion, not because of a fault - because they were scams, sprays, and spoofs, and we stopped them. Over a million a month. Fifteen million in the last year, and growing.

We tightened the net hard through last summer, and at the peak we were rejecting nearly six in every hundred call attempts based on their identified signature. If you've heard us cite "around 5% of traffic", that's the era it comes from, and it was true. It is about half now owing to two factors.

Traffic across our network has two sources - our own customers where we see 100% of their attempts usually, and other networks where we see a proportion of their attempts broadly equivalent to our market share. In the worst cases, we’ll see both - traffic across multiple customer accounts and attempts coming in across multiple peers. We’re agnostic about origin, it all gets treated the same, but we can and do terminate accounts. Sometimes this is within days of passing KYC and having service established. Other times, it's long-standing customers who have regrettably been seduced by apparently easy money. We don't discriminate: bad is bad.

What we’ve seen is a substantial reduction in the proportion originating on-net (of the 100% we see) and a substantial increase in that which originates off net (of the market-share percentage we see). This is of course in part traffic from those accounts we've terminated which has been welcomed with open arms by others. But the vast majority is simply the ongoing inflation in this type of traffic. Over the past year, the share of hostile calls in the traffic our peers hand us has roughly doubled - across every peer.

Part of the driver for this is simply economics. Wholesale phone calls are so cheap and actually free for the originator unless they connect. So turning up the volume, harassing more end users remains a lucrative and viable business, even if only a tiny proportion of them ever engage positively.

We tried to encourage Ofcom to change these motivations in a recent consultation, sadly to no avail.

One network in particular who we have called out repeatedly for their pious virtue-signalling, and specifically in the context as the “Fox in the Hen House”, has KYC requirements as pitiful as their technical standards. By our measurements, they are ten times more likely to be the origin of a spam call than the cleanest of our peers - which, credit where due, is BT. We won’t allow our customers' end-users to be ripped off or harassed, even if they will. I presume this is lax KYC rather than wilful targeting of that market segment, but the result is no different for the poor person on the receiving end.

That is based on the route traffic takes but it is equally interesting if one looks at the Range Holders problem numbers are assigned to. There are some really bad ones but if we look at the top 10, and then consider which networks host these, let’s just say it looks like the route probability would suggest. The smallest of aforementioned hosting operators is clear number one, with 5.6x BT’s number of blocked calls. Market-share weight this and things get exponential. Simwood, despite hosting more ranges than the number one spot, and seeing 100% of the traffic by virtue of the sampling taking place on our network, doesn’t appear on that list at all. So this appears to be Range Holders with lax KYC, favouring hosts with lax KYC, who also have lax KYC over the traffic they pass. How many times can you say correlation isn’t causation before giving up?

I’d dearly love to publish these league tables, maybe as a real-time dashboard like we have internally. I think they’d be really insightful to policymakers and hopefully drive responsible CPs to make different choices. Unfortunately various rules in our industry introduce hurdles to that. Maybe Ofcom will s135 us for this data? The blurred images above are the best we can do for now.

The result of all this on our side is a dramatically cleaner network: the failed-call share has fallen, and the population of abusive numbers originating here at any moment has fallen by roughly two thirds.

Meanwhile, excluding the effect of customers terminated, our catch rate is rising. Same customers, sharper filter. That's the pair of numbers that matters: cleaner network, keener blade.

Despite us catching more bad stuff in a cleaner population, the really important thing for us is false positives. Anyone can block 1m calls and in fact we’ve already told Ofcom we could block 30m just by enforcing one of their long-standing rules. The trouble is, doing so unilaterally we’d be out of business because those blocks would result from decades of poor discipline by other operators, either not knowing or not caring about the existence of said rule.

We treat blocking a legitimate caller as a serious incident. The entire system is engineered backwards from that:

• No block is forever. Every block is time-limited and expires automatically. A number is re-judged on what it does next, not on what it did once. However, persistent offenders now escalate, i.e. the blocks get longer each time.
• Every block candidate gets a second opinion. An independent AI adjudicator now reviews the evidence behind every candidate - and it argues in both directions. It can overturn a block as readily as confirm one, and every verdict it gives is logged and scored against what actually happened next.
• Evidence protects the innocent. Numbers with genuinely healthy calling relationships are structurally protected - a borderline signal cannot block them. And where evidence is missing or stale, the benefit of the doubt always goes to the caller. Absence of proof is never treated as guilt.
• We audit our misses, not just our mistakes. We now randomly re-examine traffic we cleared, so we can measure false negatives as rigorously as false positives - and tune the balance on data rather than anecdote.

Everything above is measured against real outcomes, continuously. This month we validated a new early-warning technique against a full year of enforcement history - strictly past-predicting-future - and found it concentrates almost half of the next month's brand-new offenders into a third of a percent of the number space. That means checking bad numbers before they've hurt anyone, not after.

That is a difficult one because compliance won’t always allow us to act upon the profiling of a number based on which Range Holder on which network and which interconnect the calls come from, even though statistically that gives great signal. The danger comes where some innocent user has seen the light and ported out which fails our false positive rule.

We also had an independent machine-learned model audit our hand-built rules: it agreed with every one of them, which is either reassuring or suspicious, and we choose reassuring - it also found two new signals we're now evaluating.

None of it ships as blind automation. New signals face direct scrutiny first and blocking only with corroboration. The system is learning all the time, both from its own evolving baselines and the signal of proven hypotheses. There are now well over 40 proven factors go into any block/don’t block decision, which individually have high statistical probabilities before tying them together.

Lastly we have recently licensed TPS and CTPS data. Calling those numbers isn't signal on its own because we don’t know the intent of those calls, but there are some interesting patterns in there which will no doubt help over time. One of the aforementioned operators purports to offer TPS screening as a service, despite not being a licensee of the data. Curious in itself considering the other data points.

Nuisance calling is an ecosystem problem. Every network that tolerates it - through indifference, through fear of the support tickets that come with imperfect blocking, or because the margin on a spam machine is too nice - keeps the problem alive for everyone. Our experience says the fear is misplaced: block precisely, expire automatically, review everything, measure both error types, and bin abusers. The only question is whose network they land on next, and our stats already answer it.

We would be very interested to hear from other network operators who would be interested in a feed of what is blocked, especially what is blocked coming from their network.

Klarna is the poster-child for this. In early 2024 they announced, proudly, that their AI assistant was doing the work of 700 customer service agents. Fifteen months later the CEO was on record admitting that optimising for cost had produced lower quality, promising customers would always be able to reach a human, and hiring people again. But before anyone in telecoms enjoys that too much or takes any kind of affirmation from it: at least Klarna bothered to try. At least they moved, learned something expensive, and corrected.

By contrast, our industry cannot even be bothered to make the mistake. I've heard it said that "AI is for our customers to build". They just don't get it - and here's the uncomfortable bit - even if they did get it, they couldn't act on it, because acting on it requires infrastructure and operations somewhere near this millennium. You cannot point intelligence at a business run on spreadsheets, fax-era processes and a billing system nobody dares touch. Well you can, but it is a much bigger ask, and a bigger roll of the dice by those who have proven effort- and risk-aversion.

My own conclusions came from having no choice. My recent health and long-standing family situation mean I don't have the luxury other CEOs take for granted any more, especially in respect of time and geo-mobility. The only way for me to compete is to be massively more productive in the hours I do have, and I'd argue I am, despite one hand tied behind my back. Automation and recently AI amplification is how: the mornings my inbox used to eat now belong to the work only I can do. I realised amplification works because I had to operate this way, and that lived experience is the whole philosophy in miniature - don't replace the human, amplify them, make them superhuman. If it does that for someone running with a handicap, imagine what it does for a whole team at full strength. Everything we've built recently reflects this.

What's been interesting, having arrived there out of necessity, is looking up and realising I'm not alone. Jensen Huang has been telling audiences "you're not going to lose your job to an AI, but you're going to lose your job to someone who uses AI" - true, though I'd go further, and will below. Erik Brynjolfsson gave the phenomenon a name years ago: the "Turing Trap" - build machines to imitate humans and the best you can ever achieve is a cheaper human; build machines to augment humans and you create things that were impossible before. Klarna walked straight into the trap. Much of the queue behind them is still shuffling forward.

And then there's the opposite camp, which is louder. Dario Amodei - whose company builds the very models we use, so hardly a luddite - warned that AI could eliminate half of all entry-level white-collar jobs within five years. On the narrow point he's probably right: if AI can do the meaty-medium tasks you used to hire junior people for, you'll need fewer junior people. But the bloodbath framing misses what happens at the other end, which is where the real story is.

We've been here before, incidentally. In weaving, the power loom was going to decimate employment in the mill towns - places with no other industry - and people smashed machines over the fear of it. What actually happened is one of the most instructive statistics in economic history: over the 19th century, automation removed 98% of the labour needed to weave a yard of cloth. Now you could read that as it took 98% of jobs but in fact by 1902 a single weaver minding 18 power looms produced 50 times what their predecessor had a century earlier. Employment should have collapsed by any replacement logic. Instead, not only did a single weaver achieve 50x more, but the number of weavers quadrupled between 1830 and 1900, because cloth got so cheap that demand exploded. That is a 200x improvement in output with an expansion of employment.

Of note, the people who were ruined weren't weavers as a class - they were the handloom weavers who kept doing it the old way while the world industrialised around them. Read that again with today's headlines and particularly telecoms in mind. The job didn't go extinct - it grew exponentially - but the people and businesses that refused the technology did.

A senior manager used to leverage themselves through a team of ten humans, and spent most of their week diluted across managing them - the coordination, the checking, the chasing. Give that same manager ten AI agents instead and the dilution disappears. They're not managing anymore, they're amplified: the judgement that made them senior applied at ten times the surface area. I made exactly this point to Raj, our CRO, in our 1:1 last week. The conventional playbook says hire x more people to do back-office functions in support of account managers. The better answer is ten-plus agents doing the work agents can do, with the budget that would have gone on those hires spent instead on humans doing the things only humans can do - the relationships, the trust, the judgement. And here's the twist: as AI becomes ubiquitous, the human bits don't get less valuable, they get more valuable. Everyone will have the agents. Not everyone will have people freed up to be human. Replacement shrinks a business to save cost. Amplification multiplies what the same business can do, and redeploys the humans to where humans compound. These are not the same strategy, and they emphatically do not produce the same outcome.

This is running in both directions at Simwood - outwards in what we ship, and inwards in how we work.

Outwards, Conversation Intelligence is amplification made product. When a fraud signal fires mid-call and a whisper delivers guidance into the handler's ear, the AI hasn't taken the call off the human - it's made that human better at their job than they could ever be alone. The handler with an Operator watching their call is not a cheaper handler. They're a superhuman one.

Inwards is where it gets more interesting, because this is the part no customer will ever see. I wrote recently about kaizen that remembers - me and an agent doing a task together once, it documenting every decision as it's made, and it just happening from then on. These are the tasks where previous automation efforts couldn't quite reach. What started as email triage is now something closer to an operating system we're expanding across the business: standing rules, codified skills, memory that executes rather than a wiki that rots. I said to Charles only last week that there is little point newly humanising processes with internal portals and the like when we can liberate the human altogether to a level we couldn't imagine in our last round of automation - which itself led to the requirement for the button for the human to click. Our biggest wins are increasingly coming from the unglamorous internal plumbing - reconciliations, month-end, reporting, the thousand paper cuts of running a carrier - places nobody outside the business will ever see. Competitors won't see any of it, they'll just wonder, as they probably do now, how a company our size is this insanely productive, the same way they've spent a decade wondering how we run a network like ours with a team the size of ours.

But here's where it gets exponential, and where I think the extinction actually happens.

By my reckoning Simwood is 10 to 15 years ahead of our peers on infrastructure, and objectively 20 years ahead of those who prefer to invest in Ferraris to show (themselves) how successful they are. We've consistently been a generation or two ahead at every turn. Despite being significantly smaller than many of them, our margins are ahead of businesses 100 times our size because our operation is more efficient - our financial statements are public if you want the receipts. That lead was built the slow way, over decades, a few percent at a time. And now we're ahead on AI adoption too - the entire Conversation Intelligence platform was designed, documented, built and shipped by a small team amplified in exactly the way described above. We could not have built it at all, under any previous model, with the team size we have.

Think about two cars that accelerate at the same rate, where one simply starts sooner. The second car never catches up - the gap is permanent even with identical performance. The follower can spend a lot more on a faster car - I mean literally invest in the business not themselves - and might gain a few percent faster acceleration. They can spend telephone numbers buying our customers too but the common thread is spending a lot more, in the often vain hope of catching up. In the old paradigm that could work in theory, although I've yet to see it in practice in telecoms.

However, now amplify the first car's acceleration ten, a hundred, a thousand-fold, because that's what AI adoption does to a team that already knows how to move - and remember the compounding: every rule written down, every skill codified, makes the next amplification cheaper. By the time the second car pulls away from the line, the first isn't merely ahead - it's over the horizon. The word "race" doesn't even apply and no realistic amount of money makes catch-up feasible.

I've been generous here in assuming the laggards recognise the need to even leave the start line, which, given some of them still don't have a usable API in 2026, and survive servicing knuckle-draggers, is quite the assumption.

So yes, I think AI is an extinction-level event. But the thing going extinct isn't the human's job, it is the businesses that can't move. Those businesses are the ones that are already inefficient, already a decade behind, already hanging on by their fingernails - the ones who could just about survive against competitors marginally better than them, but cannot survive against competitors 10, 100 or 1,000 times more efficient. Remember what happened to cloth prices - the laggards simply could not compete. Huang had it nearly right: you won't lose your job to AI, and your business won't lose to AI either. It will lose to a business that uses AI. The asteroid isn't aimed at your staff. It's aimed at your slower competitors, or - if you wait, or if you think AI is something your customers should build - at you.

Which brings me to the part that really excites me. This revolution is one where size doesn't matter; Simwood is proof of that. What matters is agility and adoption, and every one of our customers has both available to them. Since we launched Conversation Intelligence I've watched new businesses being formed on top of it, and existing customers genuinely getting it - taking what we've given them and developing their own propositions at a pace that would have been impossible in conventional times. The best part: they're augmenting their own people with AI in order to build on the AI capabilities we've handed them. Amplification stacked on amplification. That's the exponent doing its work, and it's available to a two-person startup just as readily as to us.

I genuinely think we're only years away from a trillion-dollar company, run by a single person. The asteroid has already hit. The only question left is whether you made it outside the crater. Your move.

The point of writing about these, as I said at the time, is that they're the only way to show the work and investment behind an architecture that's designed to survive this stuff. I do so not to gloat (although some will disagree) but because it is a genuine point of differentiation and I live in no small hope that those who have other priorities for investment (Ferrari-cough, cuddly-dogs-cough) might be motivated to up their game. This industry improving benefits us all, not least end-users and our customers who cannot solely depend on us in an industry that is by its very nature interdependent.

I write now because you’ll see another entry on our status page for Monday (13 July 2026 if you’re reading this in the future) relating to our Slough Availability Zone (AZ). It might have cost some of you a portal login, an API call, or a chunk of an afternoon trying to update your locked balance; or you might not have noticed. It is more likely you did notice because this actually affected some services ancillary to our main services - actual call volumes were normal and not a single 999 call failed (we specifically alert on that, however caused). There’s learning here for us though, and everything I said above would be hypocrisy if we didn’t similarly share. I’d also sooner you heard the truth from source rather than a distortion from a Mustard Moron in some dark corner at the CCUK Christmas party. 

So… there are four factors at play here that set some context: 

• Firstly we’ve been refreshing hardware around the network. You won’t have noticed because that’s how we’re designed. The London AZ, the Manchester AZ, Newport which isn’t an AZ but regrettably still exists - all done. Slough, next on the list and thus still running old gen hardware and build. 
• Secondly, you’ll have seen us talk about new auth and you’ll have probably seen that relating to the API already in the portal and you may even be using it. The portal itself hasn’t been moved across yet - for you at least, we’re using it in staging. That means it is dependent on an API you’ve never heard of (v4) which should never have existed and was written way back in the day by a French man - our resident chaos monkey, a title he’ll still be proud of - because he was fed up of waiting on another former colleague to make the changes he needed to API v3 - the one you do know and love. It has sat as middleware for selected portal functions (like login) for way too long. v4 is completely replaced by the new API architecture, which I’ll call v5 for simplicity even though it introduces independently versioned services starting at v1. So v4 never existed and v1 comes after v3; with me so far? Good.
• Thirdly, we rely heavily on DNS for global service discoverability where local load-balancing or internal anycast can’t cut it. For that we use DNSMadeEasy and in particular their Constellix product which allows automatic failover of records and we’re hooked into its API for dynamic updates. They used to happen within the TTL (15 seconds) which was great. Constellix was bought by Digicert in 2022 and it's apparent their standards have deteriorated.
• Lastly, we recently parted ways with a long-serving and very capable engineer. That left gaps in ownership and institutional knowledge we hadn't fully backfilled - which matters below.

That's the context. I hasten to add not excuses, the ownership comes later!

So, at 14:27, an old host in our Slough AZ died. Not gracefully - disk I/O error, no IPMI, no way to even power-cycle it remotely. It was one of the older boxes on the estate, with less monitoring wired into it than anything we've bought in the last few years, and it had passed a health check a month earlier. It just went, the way hardware does, with no warning anyone could have acted on. 

But that is what we plan for and nobody outside of our DevOps team should have noticed. Other hosts have failed the same way more than once this year and it's been a non-event every time, because they're on current hardware with proper out-of-band management and deployed to our current standards. This one wasn't, and that's the actual story here.

We have hundreds of container images, deployed dozens of times in some cases, making for a large estate. Within AWS we use Kubernetes to orchestrate this, but in our three on-net UK AZs, they use Docker with our own network stack. This is something I’ve blogged and presented on many times in the past as, uniquely, a container is a first class citizen on the network, speaks BGP to its host, pushes its own firewall rules to the edge etc. etc. All good but a lot to orchestrate and therefore we have strict policies around deployment to ensure availability between AZs and across hosts within an AZ. Anycast makes light work of this for many things - just run them everywhere - other things such as our database of record Galera is a cluster with a node per AZ, ElasticSearch is sharded and distributes shards according to its own strict policy and so on. We also make enormous use of Redis - like 500,000 requests a second levels of use - around the network. Read nodes are anycasted so everything consumes it closest, often local, usually on the same box, for minimum latency. If you know Redis though you’ll know it has a single master under which everything else is a slave. To manage the master-candidates around the network we use Sentinel, which seamlessly promotes a new master and ensures everything uses it. Much code is hooked in to use Sentinel to benefit from this but certain code which can’t instead uses DNS which is updated automatically on a state change.

The box that died had all of the above on it, as well as loads of other services. They all, even Galera, did what they should and just got handled. Manchester and London AZs, as well as the many on AWS, and our Global Edge, all continued completely uninterrupted exactly as they should. That is worth celebrating I think because I don’t think any of our competitors would have gone without a major outage losing primary database nodes, let alone primary nodes across dozens of services. But this isn’t about them, and we hold ourselves to a higher standard.

What didn’t work was Redis. Sure, the slaves carried on working, as designed, which is why other sites didn’t skip a beat and why call volumes remained normal (voice runs on different hosts altogether - Voice Compute Nodes (VCNs) vs Compute Nodes (CNs) in our parlance), but nothing could write to the master because Sentinel hadn’t failed over. Also, a load of services which rely on Sentinel to discover the new master failed to connect because there simply wasn’t one - the old one was in Slough on a host which was now dead. It's fair to say all hell broke loose in Slough and a cascade of weirdness ensued.

Notably portal logins failed on Carrier Services because API v4 couldn’t connect to Redis. Portal logins failed on Hosted for similar but independent reasons. API endpoints like ‘calls in progress’ stopped working because call events weren’t being processed and customers relying on the balance-update endpoint were understandably concerned, since the API writes to Redis as well as Galera and couldn't. It didn’t matter though because millions of CDRs weren’t being billed because requisite services couldn’t reach Redis. Finally, we also lost a SIP proxy in Slough which was wrongly deployed on the Compute Node which had failed, but I’ll return to that.

On investigation we found out that Sentinel didn’t exist anymore. Rather than existing in every site per our spec, it only existed in Slough on the old host which had failed. Let's say that was an ownership problem in origin - Sentinel hadn't been deployed elsewhere as hosts had been upgraded, so Slough was the only node. I believe in decentralised command - or trusting people to do their job - especially where people are technically so capable, but the reality is you can’t delegate accountability and we did. We have to own that and make sure it can’t happen again.

In terms of mitigation, we didn’t just want to stand up a new Sentinel with unknown consequences for the now unmanaged cluster so we promoted a new master manually. That triggered a DNS update but the services which use DNS for discovery of the write node didn’t update. It turns out that despite a 15 second TTL, Constellix took over 30 minutes to push the change out. Digicert’s support team wasn't aware of the product last time we contacted them recently and we were in the middle of forcing changes in other ways when the change took. That left the other services which consumed Sentinel in order to discover the write node; Sentinel which wasn’t there anymore. They needed patching, testing and deploying one-by-one to resolve. That had to be done in priority order and meant some things, themselves 2 minute fixes, took longer to resolve than they otherwise would have done. 

Out of hours after the incident we redeployed Sentinel and, with appropriate escape routes in place, let it control the cluster. It did so with the poise and lack of drama we know and love it for, and which it would have done during the day had it been there.

That covers pretty much all the weirdness customers saw with two exceptions. 

The first was “calls in progress” and “locked balances”. The latter was a simple case of Redis writeability being restored and that was one of the earlier services to be fixed. However, customers polling the calls in progress endpoint and firing off updates to locked balances were seeing an out of date balance simply because calls in progress wasn’t updating - a low priority thing to address. It wasn't low priority to them as they believed they’d run out of credit any second or that their change hadn’t worked; even when writability was back and CDRs were catching up, they were updating their locked balance to an impossible figure by virtue of decrementing a historic figure.

The second was the outbound carrier proxy in Slough. The customer facing proxy was working as was the rest of the stack but on the way out of the network there is another edge proxy in every AZ. We knew this was down from our monitoring, and some customers in Community Slack even told us, but it was low priority as voice calls were working fine according to our own automated testing and volumes. In days gone by the very first thing we’d have done in an incident like this is modify DNS to fail traffic away from the affected AZ, regardless. On this occasion we didn’t and that was a mistake, even though it would have been far more latent than designed due to Constellix issues. When a new carrier proxy was deployed onto the VCNs, the correct home, Slough was back to 100% even with the other Redis based issues. I stand by our record since 2018 that voice continued working across the network as other sites were unaffected and even Slough telemetry was fine. However, we did have a couple of tickets from sensible customers who experienced odd issues and we owe it to them to work through those thoroughly and mitigate them in future if there is a way of doing so.

There are two books I love. The first, Black Box Thinking, contrasts airlines with healthcare in terms of how one learns from mistakes and the other covers them up. I’m determined we’re more like the airlines and continue to improve wherever we can, and like the airlines, share that knowledge. The other one is Extreme Ownership by Jocko Willink. Jocko recorded the intro for the SimCon just before the pandemic for those who were there. I hope this post demonstrates how we embrace his teachings. One of his expressions is “discipline is freedom” which I think really captures the true root cause here. Yes, it was a Redis failure resulting from a hardware failure, but that was designed out of being a problem 10+ years ago. The reality is that for all the designs, and playbooks and testing, we ultimately relied on someone to do their job. The fact he took shortcuts is our problem and we should have identified and remedied them before they had an opportunity to cause an issue. The spine running through all of that is a lack of discipline.

There are a few lessons and actions here which we’re applying or have already applied:

• Sentinel is everywhere, per the design
• Services which were patched to bypass Sentinel are being corrected and redeployed
• We need to look at DNS to find an alternative or at least mitigation for Constellix. We already use another dynamic DNS provider for our Kubernetes services.
• We need to investigate and address those presumably carrier proxy derived edge cases.
• We need to fail-over DNS away from affected sites in such an incident in future, as we used to, rather than being overconfident in the local redundancy in place.
• The staging portal will be rolled out to customers ASAP, enabling v4 API to be retired.
• The chaos monkey role is very helpful and we’ve missed the sharpness having one causes. The longer stuff works, the more scary it breaking becomes and the rustier you are at responding. We intend to program in regular datacentre visits (even if no work is planned) and part of their function will be to trigger failures, to test redundancy and keep everyone sharp. Impending legislation requires annual reboots anyway so this is a necessary direction of travel everyone will have to take.
• Containerisation, as I’ve opined many times before, ensures every version of every container is identical, which was a massive win for us a decade or more ago. We can’t have an instance like some of our peers where two magic boxes have different manual configurations. But, only policy directs the placement of those containers and requires them not to be changed without going through a change control and deployment process. It is very clear we need to use some of the amazing tools at our disposal now to enforce that policy. We will have a single pane of glass, separate to monitoring, which visually enforces our policy and would have told us that Sentinel wasn’t compliant with it in terms of running instances and their placement, with the bonus of verifying the signature of the code running to affirm it hasn’t been “hot fixed” since deployment. That wasn’t an issue here but could have been and can be easily mitigated at the same time. Exposing policy violations enables them to be addressed when it isn’t an emergency and necessary changes made to ensure they don’t happen again. As we say in Bitcoin: trust, but verify. 
• Slough upgrades are being prioritised to complete the rollout.

I hope that provides some assurance and explanation to all those who wondered what was going on. This isn’t an RFO as the O didn’t happen, but it was far closer to happening than we’ve been in a long long time and shouldn’t have been. We pride ourselves on our architecture and technical performance so flog ourselves more than anyone outside ever could. We appreciate you trusting in us to do so.

There’s a category of engineering problem that doesn’t show up in postmortems or sprint reviews: the slow accumulation of undocumented decisions. Nobody documents the decision in the moment because the context is obvious – everyone involved knows why. Some time later, that context is gone, and someone makes the same mistake again, or undoes something that was done deliberately, or spends days rediscovering reasoning that exists somewhere in a Slack thread from years ago.

I actively monitor our developer Slack channels. It’s not unusual to see someone “fixing” something that is apparently obviously wrong and very much was done that way for a reason – a reason that would have been right in front of them if it had been recorded anywhere. In our case, “some time later” can mean twenty years later. The decisions made in the early days of the platform are still embedded in the codebase, often with no trail left to explain why. This is a cost that compounds, quietly, for as long as the product lives.

Architecture Decision Records (ADRs) are the tool the Simwood engineering team now uses to stop that accumulation.

An ADR is a short structured document that records a decision: what was decided, what the alternatives were, what the reasoning was, and what the follow-on questions are. Written at the time the decision is made. Stored in the codebase alongside the code it relates to. Never deleted – only superseded, with a link to the successor.

This might sound like bureaucracy. It is not. A well-written ADR takes perhaps twenty minutes to produce. In return, it gives any future engineer the ability to understand why the codebase looks the way it does. The auth model resolves authentication at the edge for a specific reason – documented in an ADR. The portal login migration is being done the way it is for a specific reason – documented in an ADR. These decisions exist. Without ADRs, they exist only in memory. With ADRs, they’re searchable.

ADRs are internal. They contain implementation details, open questions, and reasoning that isn’t relevant to API consumers. They’re not published at docs.simwood.com; they live in the internal platform docs repository, alongside architecture briefs and service guides that are equally internal.

An MCP (Model Context Protocol) server makes this internal documentation queryable by the AI agents working on the Simwood codebase. When an AI is helping an engineer work on a service, it can consult the ADRs directly rather than working from first principles or from assumptions about what might have been intended. A recorded decision gets found rather than rediscovered, without trawling Slack history or asking whoever was there at the time.

This is a specific, practical consequence of documentation-first development. The investment in writing good ADRs pays off here in a concrete, immediate way: the AI can reason about decisions that have been recorded, and it can flag when it encounters something that appears inconsistent with a recorded decision. It’s also why Part 2 describes AI as integrated into the development process rather than just assistive – the documentation is the context that makes that integration work.

There’s an onboarding benefit too. When a new engineer joins and asks “why does the auth model work this way?” – the answer should not be “ask Charles.” The answer should be: “Read this ADR.” That’s it. Question answered, without involving anyone else’s time.

The discipline of recording decisions as they’re made is not natural. Most engineers find it easier to get on with building. What Charles and his team have demonstrated is that the upfront investment – writing the brief before the code, recording the decision before moving on – pays back quickly and compounds over time. The codebase is more navigable. The AI assistance is more accurate. New team members get productive faster. The institutional knowledge that would otherwise walk out the door when someone leaves is preserved in a form that stays.

The template for adding a new service – the checklist, the ADR format, the guide structure – also lives in the internal docs. Which means the process of adding a new service is itself documented, followable without asking anyone, and improvable over time.

This is the last post in the series. If you’ve read all twelve, you now understand something that I think matters: the platform isn’t just the Conversation Intelligence features, and the features aren’t just code. They’re the product of a process – documented before it was built, AI-integrated throughout, decisions recorded so they can be found – that we think is genuinely better than how most engineering is done. We’ll find out whether that’s right over the next decade.

For now: the platform is live, the docs are real, and the APIs work. If you’re building on it, we want to hear how it goes.

Previous: Part 11 – Documentation as a product

Back to Part 1 – series index

Most API documentation in telecoms is a reference dump. A list of endpoints. Parameters, types, response codes. If you’re lucky, an example. If you’re very lucky, an example that actually works.

This is not adequate. A reference is useful when you know what you’re looking for. It is nearly useless when you’re trying to understand how something works, why it works that way, or how to combine capabilities to achieve something real. Developers who hit a reference dump when trying to figure out a new platform spend the first hour reading the same three sentences over and over and then go to find someone to ask. That’s a failure of documentation design, not developer competence.

The restructured docs site at docs.simwood.com is built on a different principle: reference is for lookup, guides are for learning. They are different things and should be written, maintained, and presented as different things.

The structure separates the two cleanly.

Platform-level guides cover things true across all services: how authentication works, how the gateway model works, how versioning and deprecation work, what error conventions to expect. These don’t belong to any single service – they’re the foundation. You read them once, early.

Per-service structure gives each service its own section: a service overview (what it does, when to use it), narrative guides covering the core workflows and patterns, an API reference generated directly from the live OpenAPI spec, and code examples. The narrative guides are hand-authored; the reference is auto-generated. Both are updated when the service changes – the reference automatically, the guides by the team responsible for the service.

The principle that drives this split: if a piece of documentation is explaining why something works the way it does, it’s a guide. If it’s specifying a parameter name and its type, it’s reference. Mixing the two produces something that’s bad at both.

The interactive explorer is worth spending a moment on, because it changes how you work with documentation.

Every service in the docs portal is served via Scalar – a modern API reference UI with a live “try it out” capability. You enter your API key directly into the explorer, choose an endpoint, fill in the parameters, and send the request. The response comes back in the browser. You don’t need to open a terminal, construct a curl command, or paste values between windows. You can explore a new endpoint in thirty seconds.

This sounds like a quality-of-life detail. It isn’t. The gap between “I can read what this endpoint does” and “I have seen this endpoint work against my actual account” is enormous in terms of developer confidence. Reducing that gap to thirty seconds changes how quickly new developers get productive and how much time the support team spends answering questions the docs should have answered already.

Real keys, real requests, real responses, in the browser, without setup. That’s the bar.

The technical implementation reflects the independent service architecture described in Part 8. Each service exposes its own OpenAPI spec at /{service}/{version}/openapi.json. The spec is the authoritative contract for that service, owned by the team responsible for it, published automatically on merge. The documentation portal reads the live spec URL rather than a copy – which means the reference is always in sync with what’s actually deployed. The usual failure mode for API documentation – it describes a version of the API that no longer quite matches what’s running – is eliminated.

Adding a new service to the docs portal is a single entry in the service registry file. No restructuring required.

We’re not writing this post to claim the docs are perfect. We’ve historically been terrible at documentation and our customers have forgiven us more often than we deserved. What we’re committing to is the principle: documentation is a product. It gets investment, it gets maintained, it has ownership. The alternative – reference dumps six months out of date, no narrative guidance at all – isn’t where we’re going.

Developers talk about documentation. Not in formal surveys – in Slack, on community forums, in comments on posts like this one. “The docs are actually good” is a competitive differentiator in the developer tools market, and it’s one that takes sustained commitment rather than a single sprint. We’re sustaining it.

Previous: Part 10 – Deprecation as a feature

Next: Part 12 – Internal documentation that actually gets used

Back to series index