Evidence
Case studies, deployment patterns and operating proof
Five kinds of evidence, kept apart on purpose: operating proof Interkey measures on its own facility, deployment patterns that describe how a product runs in the field, reference architectures, evaluation guides, and engagement summaries published with a counterparty’s agreement.
How to read this page
Five kinds of evidence, and why they are not mixed
A buyer asking “has this been done before” is asking five different questions, and a page that answers them with one blurred story is not evidence. Operating proof is what Interkey measures on something it runs itself. A deployment pattern describes how a product is put into service, independent of any one organisation. A reference architecture is a design that can be checked. An evaluation guide is the checklist a buyer uses on any supplier, Interkey included. An engagement summary names a sector, a problem, the work and the result, and it is published only with the counterparty’s agreement.
Deployment patterns
How each product goes into service
A pattern describes the work as it runs: what the product needs from the site, what it connects to, what a pilot has to prove and what operating it involves. Each is written to be checked against your own environment before anyone talks about a programme.
SquintPRO on the CCTV a site already owns
Which PPE classes are detectable, camera placement, false-positive budgets and what an alert triggers.
Pilot patternA safety pilot that proves something
Success criteria, measurement honesty and the privacy handling a pilot has to settle before it starts.
Deployment patternIntelligent DPI inside an operator network
Where traffic classification sits, what it integrates with, and the proof of concept on the operator’s own traffic.
Deployment patternOTP and transactional messaging with Digital Connect
Channels, sender registration, integration over REST and SMPP, and the first-party platform figures with their scope.
Deployment patternLive replication between systems that do not match
Where iblync sits between source and target, rate control, queueing when a target is down, and cutover.
Migration patternA database migration run like production depends on it
Assessment, dual-run, cutover and the workloads that should stay put.
Operating proof
The Riyadh facility, measured by Interkey
Company operating figures for Interkey Semiconductor’s network-equipment facility in Riyadh. They describe the operation as it runs, not any one customer’s programme, and they distinguish delivered output from annual production capacity. The capability itself is on the manufacturing page; the company is on the Interkey Semiconductor page.
| What is measured | Figure | What it is |
|---|---|---|
| Facility | Riyadh, Saudi Arabia | Network-equipment manufacturing and assembly, run by an Interkey-owned company |
| First production run | 2025 | The first run on Interkey’s own timeline; the year is what the source gives |
| Devices delivered | More than 100,000 | Completed output that has left the facility |
| Annual production capacity | Up to 1.5 million devices | A ceiling across the current product families, not a count of what was produced |
| Product families | 5G CPE, mesh routers, 5G MiFi, ONT | The four families assembled today |
| Production lines | Four | As stated by the current source |
| Localisation stage | SKD assembly | The stage running today, under an OEM contract model open to vendors |
| Operational monitoring | AI-enabled | Visibility across the stages of work; a description of how the process is managed |
| Local content | Saudi Made positioning; mandatory local-content list inclusion stated in Interkey’s official publication | A programme’s own local-content position is assessed under the buyer’s rules |
Reference architectures
Designs that can be checked
Each of these is drawn, not described: the components, where data lands, and what the control points are. They are the designs Interkey implements, and they are written so an architect can disagree with them precisely.
The observability residency split
An in-Kingdom control point between your systems and a SaaS platform, with the audit trail it produces.
Reference architectureKubernetes monitoring, designed to be audited
Install paths, the security review, air-gapped registries and the cardinality budget.
Reference architectureAPI gateway shapes: self-managed, hybrid, on-cluster
Which deployment shape residency and the existing cluster allow, and what a production gateway has to show.
Planning guideIntegrating with Saudi digital platforms
Sandbox to production, authentication, logging, retries and auditability for documented government interfaces.
Engagement summaries
References are given in a conversation
An engagement summary names a sector, a problem, the work Interkey did and the result, and it is published here only when the counterparty has agreed to it. For everything else, ask for references in the first conversation: they are given with the other party’s consent, matched to your programme, which a web page cannot do. The operating proof above and the patterns beside it are what Interkey can show without asking anyone’s permission.
Evaluation guides
The checklists to use on any supplier
Written to be used on Interkey as much as on anyone else, and explicit about the cases where the answer is not this.
How to evaluate a Saudi network equipment manufacturer
Localisation stages, test coverage, design ownership and the twelve questions for an RFP.
Evaluation guideEvaluating an observability platform for Saudi Arabia
The four questions that narrow the options before any product name appears.
ComparisonDatadog alternatives: when to switch, and when not to
Written by a Datadog implementation team, which is why the honest half is worth reading.
Buyer guideChoosing between IT companies in Riyadh
Ten criteria, what to ask under each, and where Interkey fits using supported facts only.
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Why deployment patterns rather than customer stories?
A pattern describes the work as it actually runs, independent of who bought it, so it can be checked against your own environment. A customer story is only evidence with the customer’s agreement, and those are given as references in a conversation rather than published in general.
Are the manufacturing figures a customer result?
No. They are Interkey’s operating figures for its own Riyadh facility: delivered output and annual capacity are company measurements, and neither is a claim about any one customer’s programme.
What is a reference architecture, as opposed to a deployment pattern?
A reference architecture is a drawn design: components, where data lands and where the control points are, written so an architect can disagree with it precisely. A deployment pattern is the operating description around a product: what it needs from the site, what it connects to and what running it involves. Most programmes use one of each.
Can we get a reference for a specific product?
Ask in the first conversation, naming the product and the sector. References are arranged with the counterparty’s consent and matched to the programme you are planning.
Next
Continue exploring
Next step
Ask for the reference that matches your programme
Name the product, the sector and what the reference has to show, and the team arranges it with the counterparty’s agreement.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia