PromptFE: MNOC and Prompt Feature Engineering

For the past year, most advice on improving Large Language Model (LLM) outcomes has focused on prompt engineering - refining wording, adding examples, and iterating on structure.

That works, to a point.

But when LLMs are applied to operational data - telemetry, logs, network tests, events - prompt wording is rarely the real problem.

The problem is the data.

The hidden failure mode of LLMs in operations

Operational systems generate enormous volumes of data:

• Metrics sampled at different rates

• Logs with inconsistent structure

• Telemetry with technology-specific semantics

• Events that are noisy, bursty, and ambiguous

When this raw data is placed directly into a prompt, the LLM is forced to:

• Infer scale and thresholds

• Guess what “good” or “bad” looks like

• Reconcile contradictory signals

• Reason over noise instead of signal

The result is brittle, non-repeatable answers - regardless of how well the prompt is written.

From prompt engineering to Prompt Feature Engineering

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

PromptFE shifts the focus from how we ask the question to what we present to the model.

Instead of feeding raw telemetry into an LLM, PromptFE emphasises:

• Normalised inputs

• Scored and ranked signals

• Technology-aware thresholds

• Explicit confidence and severity indicators

In other words: applying the same discipline used in feature engineering for machine learning to the inputs of an LLM.

Prompt wording still matters - but only after the data has been made intelligible.

MNOC: PromptFE for operational data

MNOC was built to solve a long-standing problem in service assurance:
how to turn diverse, noisy measurements into a shared, trustworthy view of system state.

That makes it a natural fit for PromptFE.

MNOC introduces a scoring layer between measurement and interpretation:

1. Measure
   Collect raw metrics, events, and test results from operational systems.

2. Score
   Convert those measurements into normalised, technology-aware scores
   (e.g. red / amber / green, low / medium / high, confidence-weighted values).

3. Present
   Expose the scored outputs as structured data suitable for:

   • LLM prompts

   • Agent tools

   • Automated decision systems

By the time an LLM sees the data, the hard work has already been done.

Why scoring matters

Scoring provides three things LLMs struggle to infer on their own:

1. Semantic stability

A “0.2” means nothing without context.
A “high risk with low confidence” is immediately interpretable.

2. Repeatability

The same inputs produce the same interpretation, regardless of phrasing.

3. Trust boundaries

Humans, automation, and AI agents can all reason over the same scored signals.

This is particularly important in regulated or safety-critical environments, where evidence and explainability matter more than creativity.

PromptFE enables agentic workflows

As teams move toward agentic AI, PromptFE becomes even more important.

Agents need:

• Stable inputs

• Clear thresholds for action

• Confidence measures

• Machine-readable structure

MNOC-scored data can be exposed as tools, shared between systems, or federated across organisations - enabling shared awareness without sharing raw data.

Prompt engineering isn’t going away — it’s moving up the stack

Prompt engineering still has value.

But its role changes.

Instead of compensating for messy data, prompts can focus on:

• Policy

• Decision logic

• Escalation rules

• Human-readable explanation

PromptFE - and tools like MNOC - handle the messy reality underneath.

Conclusion: better inputs, better outcomes

If LLMs are the reasoning layer, then Prompt Feature Engineering is the interface.

MNOC provides an open, opinionated implementation of PromptFE for operational data — grounded in decades of service assurance practice, not trial-and-error prompting.

Better prompts help.

Better features make a big difference.