Telemetry Everywhere, Truth Nowhere: The FTTH Operations Gap

The Illusion of Visibility

FTTH networks are among the most instrumented environments in telecom.

Operators collect:

• Y.1731 measurements across thousands (or millions) of ONTs

• OLT counters and alarms

• Optical telemetry from the access layer

• Streaming data into platforms like InfluxDB and Prometheus

On paper, this should mean complete visibility.

But ask any operations team a simple question:

“What is the state of this service right now?”

And the answer is rarely immediate — or consistent.

Data Is Not Truth

Y.1731, ONT telemetry, and OLT stats are measurement systems.

They describe:

• latency

• loss

• continuity

• signal levels

But they don’t tell you what those measurements mean.

A spike in latency might be:

• a transient artefact

• a congestion signal

• a developing fault

• or completely irrelevant

The data doesn’t decide.

The engineer does.

The Hidden Layer: Interpretation

Every operational decision depends on an invisible step:

interpretation

Engineers continuously translate raw telemetry into judgement:

• “this looks normal”

• “this is degrading”

• “this needs escalation”

That translation is:

• undocumented

• inconsistent

• dependent on experience

And critically:

it does not exist in the data itself.

Fragmented Reality

The problem compounds because the data is spread across systems:

• Y.1731 tools show path performance

• OLT systems show port and PON state

• NMS platforms show alarms

• Customer systems show symptoms

Each system provides a partial truth.

None provide the full picture.

So operators are forced to:

• pivot between tools

• mentally correlate signals

• build a narrative in real time

This is not observability.

It’s reconstruction.

Why Dashboards Don’t Solve It

Modern dashboards look impressive.

They provide:

• real-time graphs

• historical trends

• alert overlays

But they still leave a critical gap:

They show what happened, not what it means.

A graph might clearly show degradation.
But it doesn’t answer:

• Is this actionable?

• Who owns the problem?

• What happens next?

So the operator is still required to interpret.

The Threshold Trap

To reduce ambiguity, operators introduce thresholds:

• latency > X → alert

• loss > Y → alarm

But FTTH networks don’t behave uniformly.

• Different services have different tolerances

• Different PONs behave differently

• Time-of-day effects distort baselines

So thresholds either:

• fire too often (noise), or

• miss real issues (blind spots)

This leads to the worst of both worlds:

• alert fatigue

• lack of trust

The Scaling Problem

As networks grow, telemetry scales.

But interpretation doesn’t.

This creates a structural bottleneck:

• Tier 1 teams escalate too much

• Tier 2/3 teams become overloaded

• automation initiatives stall

• mean time to resolution remains high

In effect:

the network scales, but operational truth does not.

Why This Matters Now

The industry is pushing toward:

• AIOps

• closed-loop automation

• AI-assisted operations

But these systems depend on one thing:

reliable, decision-ready inputs

Raw telemetry doesn’t meet that requirement.

Without a layer that converts data into meaning:

• AI produces noise

• automation becomes risky

• trust breaks down

The Real Gap

FTTH doesn’t have a telemetry problem.

It has a truth gap.

Between:

• what the network reports

• and what the operator understands

There is a missing layer:

• where data becomes meaning

• where signals become decisions

• where ambiguity is removed

Today, that layer is human.

And that doesn’t scale.

Engineering Truth into Telemetry

The gap between telemetry and truth isn’t a tooling problem.

It’s a translation problem.

Until now, that translation has lived in the heads of experienced engineers — applied manually, inconsistently, and at a scale that doesn’t match modern FTTH networks.

What’s needed is a way to make that judgement:

• explicit

• repeatable

• and usable by machines

This is where Prompt Feature Engineering (PromptFE) comes in.

PromptFE allows engineering teams to:

• encode their operational judgement directly into telemetry

• transform raw measurements into structured, decision-ready signals

• attach context and explanation to every outcome

So instead of asking:

• “What does this data mean?”

Your systems already know.

And your automation can act with confidence.