Maintenance Log Acceptance: Preserve the Severity Mapping

Severity mapping in a maintenance-log export can change how a receiving team sorts and interprets events. A source level written as text and a normalized numerical level are related fields, not automatically identical representations. Before accepting a robot-service log conversion, a buyer should ask how their meaning is preserved. This article proposes that review and inspects no real incident, log pipeline, or failed component.

Ask what the source level actually represents

Start with the originating logging system and the record being exported. The supplier should explain which field contains the original severity wording and what that wording means in the source context. Familiar terms can appear in different systems without establishing a shared mapping.

The buyer also needs the purpose of the export. A receiving viewer may sort events, filter a display, or retain records for later examination. Those uses do not by themselves establish that a displayed level diagnoses the equipment. Keep the data-conversion task distinct from a maintenance conclusion. Ask who owns the mapping explanation and who can confirm the source convention when an unfamiliar level appears in a later export.

For the fictional handover, no source record is supplied. The checklist should leave the original wording and mapped result unresolved until actual material is available. Inserting a plausible warning line would make the report appear operational without providing evidence about the supplier’s conversion.

Keep original text and normalized number separate

The OpenTelemetry Logs Data Model describes SeverityText as the source’s original string representation and SeverityNumber as a normalized numerical value under the model. It explains that mappings from existing logging systems need to define how their levels correspond to the model’s ranges.

This gives the receiving team a concrete acceptance question: where is the conversion relationship documented? The supplier should not simply replace source text with a number and call the export equivalent. Retaining the source wording can help a reviewer understand what was converted and investigate an unexpected result.

The model also treats these fields as optional. A missing value should not be silently turned into a confidently assigned level merely to fill a column. Ask the author how absence and unspecified context are represented in the actual delivery, without inventing an observation to make the data look complete.

Read the export representation beside the conceptual model

The official OpenTelemetry log protocol definition includes distinct severity_number and severity_text fields and comments describing their roles. That confirms the distinction at the representation level, while the data model supplies the interpretation context.

Ask the supplier which representation the receiving application actually obtains. A field label in a spreadsheet may not tell the reviewer whether it preserves source text, normalized meaning, or a presentation label generated later. The handover should explain that boundary rather than require reverse inference from a dashboard.

This article does not decode a protocol message or assign a numerical level. Documentation of available fields is not proof that a real exporter populates them correctly. A later authorized check needs the actual source, mapping, exported record, and observed interpretation.

Require a reviewable account of conversion exceptions

A supplier should explain what happens when a source level is missing, unfamiliar, or outside the mapping the receiver expected. Keep those cases visible in the acceptance checklist. Quietly choosing a reassuring label would discard information needed to assess the conversion.

If a real export produces an unexpected order in the receiving viewer, record the actual fields and display context before assigning a cause. The difference may concern conversion, presentation, or another documented step. Do not label it a robot fault merely because the record belongs to a maintenance system.

Likewise, a severe log classification is not a complete assessment of operational risk or a root-cause diagnosis. Those conclusions require appropriate contextual evidence and responsible review. The current checklist concerns preservation of log meaning across a representation boundary.

Close the export task with its mapping intact

The proposed handover should identify the originating level, the normalized convention, the conversion relationship, and the actual receiving observation. An unexplained gap should remain an open item. That gives another reviewer a route back to the source rather than only a final display label.

When the mapping or source logging system changes, ask which earlier comparisons need renewed examination. Preserve the previous conversion record with the material it describes. An unchanged dashboard color should not imply that the underlying classification remained identical.

More examples appear in our maintenance records section and the reading directory. The two original diagrams include no real severity values, fault messages, event counts, root causes, or completed repairs.