Data sovereignty
Alarms, telemetry, topology, incident history — all of it stays on your servers, in your country. The only thing that may cross the border, if you enable it, is an anonymous health heartbeat so we can honor the support SLA.
The self-hosted operations console
Your network will report 96 problems. This console names the one that matters.
MODERAN Console is the operations screen for Open RAN networks — installed inside your own infrastructure, watching every vendor's equipment at once, and turning alarm floods into one explained incident with a probable root cause. Every screenshot below is the real product, photographed during a live fault.
Self-hosted — runs in your network
Vendor-neutral — one screen for all suppliers
EN / FR — one click
Your data never leaves the country
The problem this buys out of
One dead unit, one hundred alarms
At 2:14 a.m. a single processing unit (a DU) stops responding at one of your sites. Every radio hanging off it loses its link and starts alarming. Every vendor's own tool shows its own slice, in its own format. Your NOC sees a wall of red and starts guessing. In Open RAN — where you deliberately mix vendors — nobody's tool sees the whole picture. That gap is what you are buying closed.
96
raw alarms produced by one DU failure — every downstream radio reporting separately
1
incident card shown to your NOC operator
95%
confidence on the probable root cause, computed from your network topology
3
plain-language reasons explaining why that element was blamed
These are not marketing numbers — they are the live values from the fault captured in the screenshots below: element du-1, incident fg_79083f45af6e2a91.
How it does that
Four steps between an alarm and an answer
The console is the visible tip of a pipeline that runs entirely on your servers:
Collect
Listen to every vendor
Adapters speak each supplier's management protocols (O1, gNMI) and pull alarms and telemetry from radios, DUs, CUs, RIC, transport and cloud nodes.
Normalize
One common language
Vendor-specific formats are translated into a single internal model, so a Nokia alarm and a Mavenir alarm become comparable events.
Correlate
Group by topology & time
Events that share a parent element and a time window are folded into one incident — the correlator knows your network map, so it knows the DU is the radios' parent.
Explain
Name the root cause
The most probable culprit is ranked, scored, and — critically — explained in words your operator can defend to a supplier on the phone.
SCREEN 1 / 5
Faults — where the shift starts and ends
This is the screen on the NOC wall. Not 96 rows. One card.
What you're seeing
One open incident: severity CRITICAL, domain RADIO, probable root cause du-1, 96 member alarms folded inside. The yellow bar is the correlator's confidence — 95%.
The line underneath is the part no competitor shows: the reasoning. "Ancestor of other affected elements · carries highest-severity alarm in group · multiple alarms on same element." Your operator knows why the system blamed du-1, not just that it did.
Why it matters
Mean-time-to-understand collapses from an hour of cross-referencing vendor tools to seconds. When the fault clears, the card clears. New alarms attach to the existing incident live — no refresh, no re-triage.
An explained root cause is also leverage in vendor disputes: "your DU took down twelve radios, here is the evidence chain" is a very different call than "something is wrong."
Who lives here: NOC operators on every shift. It is the default screen — most days, most people never need another one.
SCREEN 2 / 5
Incident detail — the evidence chain
Click the card and the incident opens into everything the correlator folded together.
What you're seeing
The header repeats the verdict — when the incident opened, when it last changed, why this root cause. Below it, every member alarm as a timestamped row: the CRITICAL DU_PROCESS_DEAD on du-1, and the chain of RU_LINK_DOWN majors it dragged down on ru-1a, ru-1b, ru-1c, second by second.
Why it matters
This is your audit and post-mortem record. Regulators, insurers, and vendor SLA claims all ask the same question — what happened, in what order? This table is the answer, retained with the incident.
Engineers use the timeline to confirm the failure direction: the DU died first, the radios followed. That ordering is exactly what's invisible when alarms live in four different vendor tools.
Who lives here: the engineer who picks up the incident, and — after the fact — whoever writes the outage report.
SCREEN 3 / 5
Topology — the map the correlator thinks with
Your whole multi-vendor estate as one parent/child tree — the same map the root-cause engine reasons over.
What you're seeing
Every element with its type, vendor, software version, and site: the RIC controller, cloud nodes, the CU, both DUs with their radios indented beneath them, and the transport ring with everything that depends on it. VendorA and VendorB sit in the same tree — that's the vendor-neutral promise made visible.
Why it matters
Indentation is causality: siblings sharing a parent get grouped under one fault when that parent fails. When an incident names du-1, this page shows you at a glance what else is at risk beneath it.
It's also the fastest inventory answer in the building: "which sites still run VendorA v5.2.1?" is a glance, not a spreadsheet exercise.
Who lives here: network planners, and any engineer verifying blast radius during an incident.
SCREEN 4 / 5
Runbooks — what to do at 3 a.m.
Every fault family ships with a step-by-step repair procedure, owned by a named team.
What you're seeing
The starter library: "DU down or unreachable" (isolate the fault to radio, cloud or transport before paging anyone), "RIC policy ingestion lag", "transport degraded" — each with numbered steps, tags, and an owning team.
Runbooks are plain versioned files. Your engineers add their own; the console picks them up on reload — no vendor ticket, no rebuild.
Why it matters
The transport runbook encodes the classic Open RAN trap in its opening line: transport faults masquerade as radio faults because symptoms surface on the DU first. The procedure proves where the fault belongs before your team escalates to the wrong supplier.
This is how senior engineers' knowledge stops living in their heads and starts living in the console — your night shift inherits your best people's judgment.
Who lives here: whoever is on call — and the ops leads who write the procedures.
SCREEN 5 / 5
Scenarios — the rehearsal room
A safe fault-injection panel: press a button, watch the whole pipeline respond.
What you're seeing
Four realistic failure patterns — a DU hard-down, a RIC policy queue stall, a lone radio temperature WARNING, a transport jitter storm. Inject drives the synthetic network to emit exactly that alarm pattern; the faults screen lights up seconds later.
Why it matters
Three jobs in one screen: acceptance — verify your installation end-to-end before trusting it with live traffic; training — new NOC hires triage realistic incidents with zero risk; demonstration — show your own leadership the alarm-flood-to-one-card story on demand.
Who lives here: your acceptance team during rollout, then trainers and demo-givers.
Et en français
The same console, one click away
Every screen ships in English and French — Incidents en cours, same data, same second. Built for teams that operate across Lagos, Accra, Dakar and Abidjan; Yoruba, Hausa and Wolof are on the roadmap.
What “self-hosted” buys you
It runs in your network. Full stop.
The console and its entire pipeline install into your own Kubernetes cluster (Helm charts, or fully GitOps via Argo CD). ARGILETTE never operates a copy of your network data.
Your identity system
Operators sign in with your own SSO (OpenID Connect — Keycloak, Azure AD, and similar). Roles separate viewers from operators from admins; every privileged action is written to a tamper-evident audit trail.
Alerts where your team lives
Incidents push to Slack, Webex, or PagerDuty with per-incident cooldowns, so the on-call phone buzzes once per problem — not 96 times.
Fits your existing observability
Ships with Grafana dashboards and Prometheus alert rules. If you already run a metrics stack, MODERAN joins it rather than replacing it.
If you are a bank, not a telco
You don't buy this console — you buy what sits beside it
Regulated enterprises (banks, insurers, hospitals, government) come into this platform through the Sovereign Edge-AI Appliance — an in-country machine that runs AI models on data that legally cannot leave the country.
What your team sees
A tenant view: your usage against your quota, your models, your inference calls — metered and invoiced per month. Provisioning and disabling of tenants is the operator's job, not yours.
The proof your regulator asks for
The appliance produces a signed sovereignty attestation — cryptographic evidence that no regulated data crossed the border. Not a policy PDF; a verifiable artifact.
Enforced in code, not in promises
The appliance software refuses to start if cross-border egress is switched on without a written override reason — and if overridden, it warns loudly in the logs on every startup. Quiet exceptions are impossible by construction.
Why the console still matters to you
The same operations discipline you just read about — correlated incidents, runbooks, audit trails — is what keeps the appliance's host infrastructure honest. You inherit the telco-grade operational floor.
Where the console sits in the platform
Four layers, one contract shape
The console and everything in this briefing is Layer 0 — included in the base platform fee, together with Layer 1. Layers 2 and 3 are expansion lines you switch on when ready.
| Layer | What it is | What your teams get | Commercial model |
|---|---|---|---|
| L0 Observability & fault correlation |
Everything in this briefing: the console, the correlation pipeline, runbooks, alerts, dashboards. | One screen for the whole multi-vendor network; incidents instead of alarm floods. | Included in base fee Flat annual platform fee — unlimited cells and regions in the contracted country. No per-cell metering. |
| L1 Interop assurance |
Conformance runs against specific vendor combinations, with approved baselines guarded against regressions. | Proof a vendor mix works before deployment; instant detection when a supplier's update breaks the mix. | Included in base fee |
| L2 Compute broker |
Sells your idle edge-compute capacity to paying tenants; pre-empts them the instant radio demand returns. Radio always wins. | A new revenue line from hardware you already paid for, with SLO-tracked safety. | $0 upfront — 15–25% revenue share on brokered compute. |
| L3 Sovereign edge-AI appliance |
In-country AI inference for regulated tenants, with per-tenant metering and signed sovereignty attestations. | AI revenue from banks, insurers, hospitals and government — data never leaves the country. | Per appliance one-time + per tenant per month. |
In the box
What arrives with the contract
- Helm charts + Argo CD manifests — installs into your Kubernetes, GitOps-ready
- Installation guide & reference architecture — sized for your footprint
- Runbook starter library — extend it with plain versioned files
- Grafana dashboards & Prometheus alert rules — day-one observability
- SLA template with S1/S2 response commitments
- Disaster-recovery plan and backup guidance
- Data-processing agreements drafted for NG, GH, SN, CI and ECOWAS frameworks
- SOC 2 control mapping + evidence-collection tooling
- Full OpenAPI specification — every screen's data is also an API your tools can call
- English & French throughout — console and documentation
Next step
See it live on your own screen
A 30-minute walkthrough: we inject the DU failure you saw above and you watch 96 alarms become one explained incident, in real time. Bring your NOC lead.
Write to sales@argilette.com or visit moderan.org