Map langfuse.score.* span attributes to scores on the OTLP ingestion path

[GeorgGroenendaal]

Describe the feature or potential improvement

The OTLP ingestion endpoint (/api/public/otel) maps a fixed allowlist of span
attributes to the Langfuse data model — trace/observation identity
(langfuse.trace.*, langfuse.observation.*), IO, usage, and cost. There is no
mapping for scores: a span attribute such as langfuse.score.<name> rides
along as an unmapped attribute and never materializes as a score
(OtelIngestionProcessor has no score handling, and attributes.ts defines no
score attribute keys).

Today scores must be sent through the dedicated ingestion path (score-create
events on /api/public/ingestion), which the official SDKs use internally. That
is a problem for OTel-only pipelines that have no Langfuse SDK in process
(e.g. agents that export pure OpenTelemetry through a collector). To attach an
inline, code-computed score (a cheap reference-free evaluator running on span
close) we have to make a second, out-of-band HTTP call to the score API,
re-deriving the trace id / observation id from the OTel span context and
re-implementing auth — duplicating transport, batching, and retry logic that the
OTLP exporter already provides.

If Langfuse mapped langfuse.score.* span attributes to scores during OTLP
ingestion, an OTel-native producer could attach a score with a single
span.set_attribute(...) and let the existing exporter ship it — no SDK, no
second sink, no manual id derivation.

Proposed solution

On the OTLP ingestion path, recognize a langfuse.score.<name> attribute
namespace on any span and emit a score attached to the corresponding observation
(and its trace), mirroring how langfuse.observation.metadata.* is already
keyed by suffix.

• langfuse.score.<name> → the score value (number, or string for
  categorical).
• langfuse.score.<name>.data_type → optional NUMERIC | CATEGORICAL |
  BOOLEAN (inferred from the value type when omitted).
• langfuse.score.<name>.comment → optional free-text comment.
• langfuse.score.<name>.config_id → optional score config id.

The score's traceId / observationId are the span's own trace/span ids (the
same derivation OTLP ingestion already does for observations), so the score
lands on the exact span that carried the attributes. Multiple scores per span
are supported by using distinct <name> segments.

Example: how the field could look

Producer side (OpenTelemetry SDK, no Langfuse SDK):

span.set_attribute("langfuse.score.correctness", 0.92)
span.set_attribute("langfuse.score.correctness.data_type", "NUMERIC")
span.set_attribute("langfuse.score.correctness.comment", "3/3 expected titles present")

span.set_attribute("langfuse.score.tone", "professional")
span.set_attribute("langfuse.score.tone.data_type", "CATEGORICAL")

As it arrives in the OTLP payload (span attributes):

{
  "attributes": [
    { "key": "langfuse.score.correctness",            "value": { "doubleValue": 0.92 } },
    { "key": "langfuse.score.correctness.data_type",  "value": { "stringValue": "NUMERIC" } },
    { "key": "langfuse.score.correctness.comment",    "value": { "stringValue": "3/3 expected titles present" } },
    { "key": "langfuse.score.tone",                   "value": { "stringValue": "professional" } },
    { "key": "langfuse.score.tone.data_type",         "value": { "stringValue": "CATEGORICAL" } }
  ]
}

Resulting scores (equivalent to the dedicated score-create events):

[
  {
    "traceId": "<span trace id>",
    "observationId": "<span id>",
    "name": "correctness",
    "value": 0.92,
    "dataType": "NUMERIC",
    "comment": "3/3 expected titles present"
  },
  {
    "traceId": "<span trace id>",
    "observationId": "<span id>",
    "name": "tone",
    "value": "professional",
    "dataType": "CATEGORICAL"
  }
]

Happy to help with the implementation for this.

Additional information

No response

[CodeCLS]

Hi @GeorgGroenendaal, great Idea and great suggestion! The more people upvote this Idea, the more likely this is to be added to the Engineer's backlog.