During onboarding, about 60 percent of the ICD files we encounter are Word documents saved as PDFs. Roughly 25 percent are Excel workbooks organized with one sheet per packet type. The other 15 percent include proprietary-tool HTML exports, FrameMaker PDFs using multi-column tables, and occasional LibreOffice Calc files with irregular row merges. Uniform XML or JSON ICDs exist, but remain uncommon among missions in development.
Automated ICD parsing must handle heterogeneous documents and produce structured schemas. It is not simply PDF-to-text conversion, because schema definitions differ between organizations and sometimes within one document.
What Parsing Means in Practice
Spacebackend converts each ICD into a structured schema containing, for every packet APID, fields with a name, bit offset, bit length, data type, unit, and value constraints. The code generator uses it to emit Python classes or C structs with accessors and validation logic.
Parsing has three stages. First, structure extraction identifies table boundaries, headers, and rows. Second, semantic interpretation maps headers to schema fields: "Length (bits)", "Bit Width", "Size [b]", and even an unlabeled column in position 3 may all denote length. Third, cross-reference resolution handles types or constraints defined elsewhere in the document or in a shared ICD.
Where Language Models Enter the Pipeline
We handle document structure extraction with layout-aware tools, not a language model. Models are unreliable when rebuilding tables from raw character streams. Instead, we extract tables programmatically and provide pre-structured input containing headers, rows, and in-cell formatting signals.
The language model performs semantic interpretation: it maps each row of a headed table to the target schema. Format variation matters here. "Octets" and "Bits" are not interchangeable unless the type is byte-aligned, so the model must use the description and data type columns to determine whether widths are bytes or bits.
We use two passes. Pass one creates a provisional schema from the table. Pass two checks consistency: do bit lengths equal the packet length in the header, do offsets overlap, and are there gaps? Any failure raises a review flag instead of being accepted silently.
Failure Modes Found During Development
The hardest failure to detect was inferred field width on sparse rows. If "Octets" is empty but "Description" contains text, a language model may guess the width from that text. "CRC-16 checksum" consistently yields 2 bytes, while "Spacecraft identifier" varies with training context. We therefore prohibit implicit width inference and require a numeric width or an explicit type reference. Without either, the field goes to manual review.
Another frequent failure involves endianness assumptions. CCSDS standard fields use big-endian byte order, while mission-specific data fields often use little-endian encoding, particularly in subsystems built around commercial processor boards. ICDs may omit this detail, causing a language model to choose big-endian by default. Our schema requires endianness and initializes it to "unknown", so a decision is required before code generation.
Unit extraction fails in a particular way. "Temperature in Kelvin", "Temperature [K]", and "TEMP (deg K)" mean the same thing, while "Temperature (raw ADC counts, 0.01 K/count)" adds a conversion factor. The model usually finds the unit but may drop that factor. We treat extraction as best-effort and retain the raw description beside the schema for verification before conversion code is generated.
Limits of LLM Parsing
ICD parsing faithfully represents the document, but cannot establish whether its content is correct. An ICD may list fields as 16 bits when flight hardware uses 12 bits, describe unexplained sequence counter behavior that differs from CCSDS, or give conflicting parameter ranges in overview and detailed tables. Parsing will not expose these defects. Integration testing will, so someone familiar with the flight hardware must review the schema before code generation.
We do not derive behavioral semantics from ICD prose either. Descriptions may state that a parameter value causes a mode transition or that one field is invalid unless another has a particular value. Such conditional rules are natural-language content, and extracting them reliably for generated validation code is outside our current scope. We preserve the text as structured comments, but engineers must implement the conditional logic.
The Practical Workflow
Onboarding usually begins with an ICD upload. Most documents are parsed in under a minute. The result is a schema review screen pairing every extracted field with its source row. Engineers confirm or correct each item. For a 40-APID ICD, someone familiar with the document typically needs about 90 minutes. That beats manual extraction, but review remains required.
Review exposes errors in the source ICD and resolves the ambiguous cases we flag. Once the schema is confirmed, code generation produces the target language output, including the source field name, confirmed schema values, and description as structured comments.
After an ICD update, we parse the new version and compare it with the confirmed schema. The diff identifies changed fields, so review covers only the delta. A mission making 3 development updates does not recheck 300 fields each time. It typically reviews 5 to 15 fields per revision.
Format Coverage and Gaps
Word (.docx), Excel (.xlsx), and PDF files are currently suitable for production use. We support multi-column FrameMaker PDFs, though weaker column detection produces more review flags. Proprietary HTML or XML exports need format-specific adapters, which we add during onboarding. Plain-text ICDs from older missions are unsupported because table extraction requires layout metadata or spreadsheet cell addresses.
The parser does not attempt graphical timing diagrams, state machine diagrams, or embedded flowcharts. They may contain interface details absent from tables. Extracting that content would require a separate approach, which we have not built. Teams relying on embedded graphics must manually convert those details into the schema.
