PromptFE doesn’t replace your AIOps platform - it makes it work

Consider the Fibre-to-the-home (FTTH) network operator. FTTH networks are full of data.

Every ONT reports:

• Latency

• Packet loss

• Signal levels

• Error counts

At scale, this becomes thousands of data points.

Every few minutes.

So the assumption is:

We must have full visibility.

But in practice, something is missing.

The Problem: AIOps Has Data, But Not Usable Input

Most AIOps strategies assume this:

Collect telemetry → feed it into a platform → get automation.

You already have:

• Telemetry pipelines

• Platforms like InfluxDB and Prometheus

• Dashboards and alerts

But still:

• Automation is unreliable

• Alerts lack context

• Teams fall back to manual triage

This is not a platform problem.

It’s an input problem.

Why ONT-Level Telemetry Isn’t Enough

Most FTTH telemetry lives at the edge.

Per ONT.
Per service.
Per customer.

That’s useful.

But AIOps doesn’t act on individual ONTs.

It needs to understand the network.

At:

• OLTs

• PON ports

• Uplink interfaces

And this is where things break down.

What AIOps Actually Needs

When an issue occurs, the real question is:

“Is this isolated—or systemic?”

To answer that, AIOps needs:

• Correlation across many ONTs

• Awareness of shared infrastructure

• Alignment with OLT-side telemetry

Without that, it sees noise.

The Missing Layer: Correlated Network Context

To make AIOps effective, you need to combine:

From the ONTs:

• Latency, loss, jitter

• Signal levels

• Events like dying gasp

From the OLT:

• PON port utilisation and errors

• Queueing and buffer behaviour

• Uplink congestion indicators

Individually, these signals are weak.

Together, they form a clear picture.

What AIOps Needs to See

Instead of fragmented inputs:

• ONT-123: Latency 25ms

• ONT-456: Latency 27ms

• ONT-789: Dying gasp

AIOps needs structured outputs:

OLT-7 / PON-3: Service State = Red
Context:
– Latency increase across 180 ONTs
– Rising utilisation on PON port
– Burst of dying gasp events
Likely Cause: Access segment instability or congestion

Now automation has something to act on.

• Clear state.

• Clear scope.

• Clear cause.

How PromptFE Makes This Possible

Prompt Feature Engineering provides this missing layer.

It allows subject matter experts to define:

• How ONTs map to PONs and OLTs

• How edge and network signals relate

• What combinations indicate real issues

Using a sandbox GUI, engineers can:

• Aggregate ONT behaviour by shared infrastructure

• Combine it with OLT telemetry

• Define scoring and correlation logic

No code.

Just domain expertise—captured once and applied at scale.

From Telemetry to Automation-Ready Data

PromptFE does not create more data.

It creates better inputs for AIOps.

Each output is a data product with:

• A clear state (Green / Amber / Red)

• Context (what is happening and why)

• Confidence (how strong the signal is)

• Provenance (how it was derived)

This removes ambiguity.

Which is what automation needs most.

Why This Changes AIOps Outcomes

Without this layer:

• AIOps sees fragmented signals

• Automation hesitates or misfires

• Teams step back in

With PromptFE:

• Signals are correlated

• Fault domains are explicit

• Automation becomes reliable

You are no longer asking AIOps to interpret telemetry.

You’re giving it decisions it can trust.

The Bottom Line

Most operators already have the tools.

They already have the data.

What they don’t have is:

data that AIOps can actually use

PromptFE doesn’t replace your AIOps platform.

It makes it work.