Water SCADA narrative logs must be ingested by a NeMo-style pipeline that expects clean text records. Which format preparation is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Pipelines are picky eaters—they want UTF-8 lines, not mystery binary stew. Make the water SCADA narratives UTF-8 and newline-delimited before NeMo-style ingestion.
Full Explanation
Water SCADA narrative logs destined for a NeMo-style pipeline should be prepared as UTF-8 encoded, newline-delimited text records before ingestion. LLM data pipelines expect clean text encodings and record boundaries; UTF-8 plus newline-delimited lines (or JSONL) is the interoperable contract. Getting encoding and record format right prevents silent mojibake and parser failures on municipal operations logs. Keeping proprietary binary SCADA blobs and renaming the extension to .jsonl does not convert binary telemetry into text and will break readers that expect JSON lines. Saving logs as UTF-16 spreadsheets with merged cells and embedded charts introduces office-document complexity and an encoding that many NLP loaders mishandle relative to UTF-8 text. Storing each log line as a lossy JPEG screenshot of the operator console discards precise text and injects OCR burden and compression artifacts. Exam caveat: narrative text extraction from SCADA must still respect security zones—export only approved narrative fields, not control-plane binaries, into the LLM pipeline. Operational check: convert exports to UTF-8, verify file/chardet reports UTF-8, ensure one record per line, dry-run NeMo (or equivalent) ingestion on a sample day, and reject any path that only renames binary extensions.