Cross-OEM Telemetry Normalization

Fanuc calls it F_LOAD. Siemens calls it servo_load. Haas calls it SPINDLE_LOAD. One field, three languages. The canonical vocabulary for machines is the missing layer between raw telemetry and trusted automation.

The problem: every OEM speaks a different dialect

There are dozens of ways to name the same physical quantity, and every controller vendor picked a different one. A spindle's rotational speed might arrive as Spindle_Speed, S1_actual, n_ist, or SPDL_RPM. Multiply that by hundreds of fields and sixteen manufacturers and you get the integration tax that has kept industrial software bespoke for thirty years. Every agent, dashboard, and automation has to re-learn the dialect of every machine it touches.

How FoundryNet solves it

FoundryNet's normalize API maps raw OEM headers to a canonical schema from a corpus of confirmed field mappings across 16 OEM families. Spindle_Speed → spindle_speed_rpm; servo_load_x → axes.x_load_pct; CoolantTemp → sensor_readings.coolant_temp. Critically, it knows when not to guess:

It abstains. Below a confidence floor, a field is returned as unknown rather than force-mapped — a junk or ambiguous field doesn't get a confident wrong answer.
It's machine-class aware. Deterministic guards stop cross-vertical leaks — a robot's joint temperature can't be mapped to a CNC coolant field or a vehicle engine temp.
It self-validates. A continuous red-team pass re-checks mappings with dimensional analysis (a kW can't become a kWh, a rad/s can't become an rpm) and demotes drift.

Foundation models can guess field mappings. They can't guarantee them. The difference matters the moment you attest to what a machine did — a confident wrong mapping becomes a signed wrong record.

Connect an agent in 60 seconds

FoundryNet Forge is a Model Context Protocol (MCP) server — 14 tools over SSE, bearer-key auth. Add it to any MCP client (Claude Desktop, Cursor, an agent framework):

claude mcp add --transport sse foundrynet \
  https://foundrynet-mcp-production.up.railway.app/mcp \
  --header "Authorization: Bearer fnet_YOUR_KEY"

Or as JSON config:

{
  "mcpServers": {
    "foundrynet": {
      "url": "https://foundrynet-mcp-production.up.railway.app/mcp",
      "headers": { "Authorization": "Bearer fnet_YOUR_KEY" }
    }
  }
}

One call: normalize(oem, data) returns canonical field names with per-field confidence and an honest coverage_pct that counts only real mappings, not forced ones.

Normalize a payload — 50 calls, no card Read the Agent Card Explore the ecosystem ↗

Why this is the foundation

Normalization is plumbing — but it's the plumbing everything else stands on. Attestation is only trustworthy if the field it signs means what it says. Industrial MCP only gives agents one surface because normalization makes the surface uniform. Get the vocabulary right and the rest of the stack becomes possible.

Frequently asked

What is cross-OEM telemetry normalization?

It is the translation of raw, vendor-specific machine field names (like F_LOAD, servo_load, SPINDLE_LOAD) into a single canonical vocabulary (like spindle_speed_rpm, axes.x_load_pct), so every agent and automation reads the same field names regardless of who built the machine.

How is this different from a foundation model guessing the mapping?

A foundation model can guess a mapping but can't guarantee it. FoundryNet abstains below a confidence floor instead of force-mapping, blocks cross-machine-class leaks with deterministic guards, and continuously red-teams mappings with dimensional analysis. That guarantee matters once you attest to what a machine did.

What does the API return?

normalize(oem, data) returns canonical field names with per-field confidence and an honest coverage percentage that counts only real mappings — junk or ambiguous fields are returned as unknown, not given a confident wrong answer.