@cosyte/astm 0.0.17 → 0.0.18

package/CHANGELOG.md

@@ -173,7 +173,7 @@ this file is maintained by hand (Changesets handles the version bump and publish
   profile, and both are **`PRE-EXISTING`** (byte-identical on the base of this slice), so they are
   disclosed here as a separate open condition rather than covered: wiring this sink to another
   delimiter role is a different criterion and wants its own population measurement. On the repeat role
-  what is lost is the value, also not reported here. And the tail is weighed **one construct deep**: where
+  what is lost is the value, not reported by this code and now reported by its own, below. And the tail is weighed **one construct deep**: where
   the escape character past the boundary heads a **recognized** sequence, the alignment taken
   interprets it while the competing one would leave it bare, so the bytes prefer the alignment taken
   (under a set naming the field separator `F`, `28.6&F&F&F&U/L` is that separator escaped, written and
@@ -204,6 +204,78 @@ this file is maintained by hand (Changesets handles the version bump and publish
   `ShiftedFieldsSink` type, and a trailing optional sink parameter on `splitEscapeAware`,
   `tokenizeRecord` and `tokenizeHeader`.
 
+- **A parse-path warning code for a field a competing escape alignment read short**
+  (`ASTM-FRAME-RESIDUALS`, defect 17b). `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` fires where two
+  escape alignments of the same bytes disagree about a **repeat** boundary, the reading taken keeps
+  it, and the escape character that reading resumes on heads **no sequence at all**. It lands on the
+  profile safety gate, so `{ strict: true }` refuses a stream carrying it whatever profile is in
+  force.
+
+  **Nothing shifts, and that is not the same as nothing being lost, which is the correction this
+  entry carries.** No field-indexed slot moves: the units slot and the result-status slot are read
+  out of the same field numbers under either alignment, which is exactly why the shift report above
+  cannot see this. What it reports is that **the field is read as more repeats than the competing
+  alignment gives it**, which is true wherever it fires. **Where that gained boundary is the FIRST
+  one in the field it reaches a modeled slot**, because a field's modeled value and its components
+  are taken from its first repeat alone: everything past the boundary stays on the wire, stays in
+  `repeats`, and leaves every modeled slot. Both costs are reachable on the **canonical** set, so no
+  unusual declaration is needed for either:
+  - **A value truncates.** `R|1|^^^687|28.6&S&\&U/L|U/L||||F` reads a value of `28.6^`, and `&U/L`
+    leaves the result entirely; the competing alignment reads one repeat carrying all of it.
+  - **A modeled identity empties, which is the half the shift report could not reach.**
+    `R|1|&F&\&687|28.6|U/L||||F` reads a Universal Test ID of one component holding a decoded
+    field separator, so the local code `687` is in no modeled slot at all and the identity comes back
+    as a LOINC candidate nobody wrote. `DOE&S&\&JANE^A` reads a last name and **no given or middle
+    name**. Before this code the only warnings on those streams were tolerable ones, so the widest
+    gate-legal profile plus `{ strict: true }` accepted a truncated value and an emptied test
+    identity.
+
+  **At a LATER boundary it fires and no modeled slot moves**, because the first repeat is then
+  identical under both readings, and what differs is the repeat structure after it. That is
+  **over-reporting relative to the modeled slots and never under-reporting**, it is measured on its
+  own sweep beside the main corpus rather than assumed, and it is stated on the code itself.
+  Narrowing the sink to the first boundary would change which streams a published package refuses
+  and wants its own measurement, so the bound is written down instead.
+
+  **Additive, and the split is unchanged.** Every decoded byte is identical, `repeats` still carries
+  every one of them, and the value read is the value that was always read: this reports the gained
+  boundary, it does not repair it. Picking the other alignment was rejected for the same reason as
+  before, on a published package.
+
+  **Two further bounds, both deliberate.** It is wired to the **repeat** separator only: a gained
+  **component** boundary reaches a modeled slot too, and differently, moving it one slot along rather
+  than dropping it, and that stays the separate open condition disclosed above. And the tail is
+  weighed **one construct deep**, on the same test the shift report uses: where the escape character
+  past the boundary heads a **recognized** sequence the bytes prefer the reading taken and the two
+  repeats are the ones the sender wrote (`28.6&R&\&R&U/L` is the canonical repeat separator
+  escaped, written and escaped again, and refusing it is the over-refusal that sank a criterion
+  measured for this same family), and where it heads an **unrecognized** one the competing alignment
+  would leave two escape characters bare, so the preference is stronger again. That second case still
+  truncates and is silent here: recorded as a residue, measured, not overlooked.
+
+  **Measured against the corpus constants committed with the test**, on the same
+  strict-accepted-under-a-gate-legal-profile tier and the same **864 tuples** as the two measurements
+  before it, in `test/records/alignment-truncated-field.test.ts`: the code fires on **96**, moves
+  **32** from accepted to refused under a profile built from the whole tolerable allow-list, moves
+  **0** back, and fires on **none** of the 96 escape-clean tuples. The pair-count criterion measured
+  and rejected on this same corpus would have refused 48 of them, which is why the tail is what gets
+  weighed. **Unlike that rejected criterion's population, this one is not confined to a set naming a
+  mnemonic letter as a delimiter**: the canonical repeat separator reaches it, on 12 of the 108
+  canonical tuples swept. A second sweep beside it moves the contested boundary off the front of the
+  field and measures the same column: **96 fire, 32 move, 0 back, 0 escape-clean**, and on every one
+  of the 96 the first repeat is identical under both alignments, which is the bound on the claim
+  stated as a measurement rather than as prose.
+
+  **It does not survive a re-emit**, the same residue its siblings disclosed: the serializer rewrites
+  the preserved characters into recognized mnemonics, so a second-generation read is silent and is
+  correct about its own bytes. Catch it on the first read of the wire bytes.
+
+  This is a **narrowing on a published package**, on the strict path only: a lenient parse of the
+  same stream returns the same records, with the same values, and one more warning on them. New
+  public surface: `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`, the `alignmentTruncatedField` warning
+  factory, the `TruncatedFieldSink` type, and a further trailing optional sink parameter on
+  `splitEscapeAware`, `tokenizeRecord` and `tokenizeHeader`.
+
 ### Fixed
 
 - **A header that is not short no longer reports that it is too short** (`ASTM-FRAME-RESIDUALS`,

package/README.md

@@ -235,12 +235,30 @@ tolerate**; before it existed the only warning on that stream was the tolerable
 unchanged: it reports the shift rather than repairing it. It is wired to the **field** separator
 only, because a gained repeat or component boundary divides one field and so moves no field-indexed
 slot. **That bound is a choice, not a consequence**: components are modeled inside a field, so a
-gained **component** boundary does move a modeled slot, and `R|1|&F&^&GLU^L^687|28.6|U/L||||F` reads
-`687` as a local code under one alignment and as the coding scheme under the other, with only a
-tolerable code raised. That is a separate open condition, not something this code covers. It is also
-silent where the trailing escape character heads a sequence of its own, recognized or not; that case
-still shifts the fields and is the recorded residue. It does not survive a re-emit either: catch it
-on the first read.
+gained repeat or component boundary does reach a modeled slot. It is also silent where the trailing
+escape character heads a sequence of its own, recognized or not; that case still shifts the fields
+and is the recorded residue. It does not survive a re-emit either: catch it on the first read.
+
+**And where that gained boundary is a REPEAT boundary, nothing shifts and the field can still be
+read short.** What the report says is that the field is read as more repeats than the competing
+alignment gives it. A field's modeled value and components are taken from its **first repeat
+alone**, so where the gained boundary is the **first** one everything past it stays on the wire,
+stays in `repeats`, and leaves every modeled slot. On the canonical set, `R|1|^^^687|28.6&S&\&U/L|U/L||||F` reads a value of `28.6^`
+and drops `&U/L`, and `R|1|&F&\&687|28.6|U/L||||F` reads a Universal Test ID of one component
+holding a decoded field separator, so the local code `687` is in no modeled slot and the identity
+comes back as a LOINC candidate nobody wrote. A patient name loses its given and middle names the
+same way. That raises `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`, which **no profile may tolerate**;
+before it existed the only warnings on those streams were tolerable ones, so a strict parse under a
+legal profile accepted a truncated value and an emptied test identity. The reading is unchanged: it
+reports the gained boundary rather than repairing it. **At a LATER boundary it fires and no modeled
+slot moves**, because the first repeat is then the same under both readings; that is over-reporting
+relative to the modeled slots and never under-reporting, and it is measured rather than assumed. Its
+tail bound is the shift report's, for the same reason: `28.6&R&\&R&U/L` is the repeat separator
+escaped, written, and escaped again, and refusing it would refuse a well-formed stream. It is wired to the **repeat** separator only; a gained
+**component** boundary reaches a modeled slot differently, moving it one slot along rather than
+dropping it (`R|1|&F&^&GLU^L^687|28.6|U/L||||F` reads `687` as a local code under one alignment and
+as the coding scheme under the other, with only a tolerable code raised), and that is a separate
+open condition. It does not survive a re-emit either: catch it on the first read.
 
 ### A header that names one character in two delimiter roles
 
@@ -339,7 +357,10 @@ outside it:
   not tolerable. Where that gained boundary is a **field** boundary and the reading taken resumes on
   an escape character heading no sequence, every later field shifts one place and a result's units
   and status are read out of slots the other alignment does not put them in: that raises
-  `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, not tolerable either.
+  `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, not tolerable either. Where it is a **repeat** boundary
+  nothing shifts, but the field is read out of its first repeat alone, so a gained first boundary
+  truncates a value and costs a test identity or a patient name the components that sat after it:
+  that raises `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`, not tolerable either.
 
 All are accepted limits, for two different reasons: widening the field-separator check would mean
 deciding which set a record ought to have had, which is the same guess the parser declines to make

package/dist/index.cjs

@@ -329,6 +329,73 @@ var WARNING_CODES = {
    * silent and is correct about its own bytes. A clean re-read is not evidence.
    */
   ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS: "ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS",
+  /**
+   * Two escape alignments of the same bytes disagreed about a **repeat** boundary, the reading
+   * taken kept it, and the escape character that reading resumes on **heads no sequence at all**.
+   * Same contested position and same tail test as
+   * {@link WARNING_CODES.ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS}, on a different delimiter role, and
+   * what it costs is a different thing, which is why it is a different code.
+   *
+   * **Nothing shifts, and that is not the same as nothing being lost.** No field-indexed slot
+   * moves: the units and the result status are read out of the same field numbers under either
+   * alignment. What this reports is that **the field is read as more repeats than the competing
+   * alignment gives it**, which is true wherever it fires. What that costs depends on **which**
+   * boundary was gained, and the two cases are stated separately rather than folded into one claim.
+   *
+   * **Where it is the FIRST boundary in the field, a modeled slot is lost**, because a field's
+   * modeled value and components are taken from its **first repeat alone**. Everything past the
+   * boundary stays on the wire and stays in `repeats`, and leaves every modeled slot:
+   *
+   * - **A value truncates.** Under `H|F^&`, `R|1|^^^687|28.6&S&F&U/L||||F` reads the value field as
+   *   the two repeats `28.6^` and `&U/L`, so a consumer reads `28.6^` and the rest of the value is
+   *   gone. The competing alignment reads one repeat carrying all of it.
+   * - **A modeled component list is deleted rather than shifted.** The same boundary inside a
+   *   Universal Test ID leaves the components of the first repeat only: under `H|F^&`,
+   *   `R|1|&F&F&687|28.6|U/L||||F` reads a UTID of one component holding a decoded field separator,
+   *   with no coding scheme and no local code, where the bytes carry `687`. A patient name loses
+   *   its given and middle names the same way. That is the half of this condition the shift report
+   *   could not cover, because components are modeled **inside** a field.
+   *
+   * Before this code the only warnings on those streams were **tolerable** ones
+   * ({@link WARNING_CODES.ASTM_NONSTANDARD_DELIMITERS} and, where the tail applies,
+   * {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER}), so the widest gate-legal profile plus
+   * `{ strict: true }` accepted a truncated value and an emptied Universal Test ID.
+   *
+   * **Where it is a LATER boundary, no modeled slot moves and this still fires.** The first repeat
+   * is identical under both alignments, so the value, the components and every slot taken from them
+   * read the same either way (`R|1|^^^687|5.0F28.6&S&F&U/L||||F` under `H|F^&` reads a value of
+   * `5.0` under both), and what differs is the repeat structure after the first. It fires there
+   * deliberately: the boundary is still one the bytes do not force and a consumer reading `repeats`
+   * is still reading an alignment guess. Relative to the modeled slots that is **over-reporting,
+   * never under-reporting**. Narrowing it to the first boundary would change which streams a
+   * published package refuses and wants its own measurement, so the bound is written down instead.
+   *
+   * **It is a report, not a repair.** The split is unchanged, every decoded byte is identical,
+   * `repeats` still carries every one of them, and the value read is the value that was always
+   * read. Picking the other alignment would be a different guess with no more evidence behind it,
+   * on a published package.
+   *
+   * **Two further deliberate bounds, both stated rather than left to be found.**
+   * - **Only the repeat role.** The **component** role reaches a modeled slot too, and differently:
+   *   there the components stay in the record and move one slot along, so a local code reads as a
+   *   coding scheme and a given name as a middle name. That is measured, reported by nothing where
+   *   the earlier body is a recognized mnemonic, and open. It is not covered here, because wiring a
+   *   sink to another split is another criterion wanting its own population measurement.
+   * - **The tail is weighed one construct deep**, exactly as for the shift report. Where the escape
+   *   character the reading resumes on heads a sequence this codec *recognizes*, the bytes prefer
+   *   the reading taken and the repeats are the ones the sender wrote: under a set naming the
+   *   repeat separator `F`, `28.6&F&F&F&U/L` is that separator escaped, written, and escaped again,
+   *   and refusing it would be an over-refusal of a well-formed stream. Where it heads a sequence
+   *   whose body is *unrecognized*, the competing alignment would leave **two** escape characters
+   *   bare, so the preference is stronger again, and this stays silent there even though the gained
+   *   boundary is real. That last case is the named residue: measured, not overlooked.
+   *
+   * **Catch it on the first read.** Emit rewrites the preserved sequences into recognized
+   * mnemonics, and those bytes carry the reading that was taken unambiguously, so a
+   * second-generation read is silent and is correct about its own bytes. A clean re-read is not
+   * evidence.
+   */
+  ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD: "ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD",
   /** An escape sequence body was not one of `&F&`/`&S&`/`&R&`/`&E&`: preserved verbatim. */
   ASTM_UNKNOWN_ESCAPE_SEQUENCE: "ASTM_UNKNOWN_ESCAPE_SEQUENCE",
   /**
@@ -488,6 +555,13 @@ function alignmentShiftedFields(position) {
     position
   };
 }
+function alignmentTruncatedField(position) {
+  return {
+    code: WARNING_CODES.ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD,
+    message: "A repeat boundary here is one of two escape alignments the bytes carry, and the reading that took it resumes on an escape character heading no sequence, which the other alignment uses to close one. This field is read as more repeats than the other reading gives it, and its modeled value and components are taken from the first repeat alone, so where that boundary is the first one the rest of the field leaves every modeled slot. The reading was kept and every byte is preserved.",
+    position
+  };
+}
 function delimitersRedeclared(position) {
   return {
     code: WARNING_CODES.ASTM_RECORD_DELIMITERS_REDECLARED,
@@ -1113,7 +1187,7 @@ var referenceCorpus = defineAstmProfile({
   tolerate: [
     {
       code: "ASTM_UNKNOWN_ESCAPE_SEQUENCE",
-      rationale: "The OSS reference stack (python-astm codec.py, firsthand-verified) treats '&' as literal data and never decodes escape sequences, so streams from that ecosystem carry non-standard '&\u2026&' bodies our escape-aware tokenizer flags. The body is preserved byte-for-byte in the value. NOT always non-clinical, and this is measured rather than assumed: where the body is a delimiter, that delimiter never became a field boundary, so `28.6&|&U/L` reads as one value with no units and no final status. That subset now also raises ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE, which this profile cannot tolerate, so tolerating this code no longer hides it. The same holds for the mirror case, where a sequence ends where another could have begun and a delimiter splits that the other alignment would have held: that raises ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT, which this profile cannot tolerate either. Where that gained boundary is a field boundary and the reading taken resumes on an escape character heading no sequence, every later field shifts and a result's units and status move with it, which raises ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS, untolerable here as well."
+      rationale: "The OSS reference stack (python-astm codec.py, firsthand-verified) treats '&' as literal data and never decodes escape sequences, so streams from that ecosystem carry non-standard '&\u2026&' bodies our escape-aware tokenizer flags. The body is preserved byte-for-byte in the value. NOT always non-clinical, and this is measured rather than assumed: where the body is a delimiter, that delimiter never became a field boundary, so `28.6&|&U/L` reads as one value with no units and no final status. That subset now also raises ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE, which this profile cannot tolerate, so tolerating this code no longer hides it. The same holds for the mirror case, where a sequence ends where another could have begun and a delimiter splits that the other alignment would have held: that raises ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT, which this profile cannot tolerate either. Where that gained boundary is a field boundary and the reading taken resumes on an escape character heading no sequence, every later field shifts and a result's units and status move with it, which raises ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS, untolerable here as well. Where that same gained boundary is a repeat boundary, nothing shifts but the field is read out of its first repeat alone, so a value truncates and a test identity empties, which raises ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD, untolerable here too. Both of those carry the same tail bound and stay silent where the escape character past the boundary heads a sequence of its own, recognized or not, which is much of this corpus: tolerating this code does not quiet them, but their absence is not a statement that nothing was lost."
     }
   ]
 });
@@ -1187,7 +1261,7 @@ function isMnemonicBody(body) {
 function escapeBody(body, d) {
   return isMnemonicBody(body) ? d[MNEMONIC_ROLES[body]] : void 0;
 }
-function splitEscapeAware(text, delimiter, escape, onAmbiguousAlignment, onShiftedFields) {
+function splitEscapeAware(text, delimiter, escape, onAmbiguousAlignment, onShiftedFields, onTruncatedField) {
   if (text.length === 0) return [""];
   const out = [];
   let current = "";
@@ -1201,6 +1275,7 @@ function splitEscapeAware(text, delimiter, escape, onAmbiguousAlignment, onShift
       }
       if (contested && !isEscapeSequenceAt(text, i + 4, escape)) {
         onShiftedFields?.(out.length);
+        onTruncatedField?.(out.length);
       }
       current += text.slice(i, i + 3);
       i += 3;
@@ -1220,7 +1295,7 @@ function splitEscapeAware(text, delimiter, escape, onAmbiguousAlignment, onShift
 }
 
 // src/records/tokenize.ts
-function tokenizeRecord(record, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment, onAlignmentShiftedFields) {
+function tokenizeRecord(record, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment, onAlignmentShiftedFields, onAlignmentTruncatedField) {
   const rawFields = splitEscapeAware(
     record,
     d.field,
@@ -1235,11 +1310,15 @@ function tokenizeRecord(record, d, onUnknownEscape, onUnpairedEscape, onSwallowe
       () => onUnknownEscape?.(fieldIndex),
       () => onUnpairedEscape?.(fieldIndex),
       () => onSwallowedDelimiter?.(fieldIndex),
-      () => onAmbiguousAlignment?.(fieldIndex)
+      () => onAmbiguousAlignment?.(fieldIndex),
+      // The repeat split runs INSIDE one field, so the index it hands back is a repeat index and is
+      // discarded: what a caller needs is which field carries the contested boundary, and that is
+      // the index this map is already iterating.
+      () => onAlignmentTruncatedField?.(fieldIndex)
     )
   );
 }
-function tokenizeHeader(record, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment, onAlignmentShiftedFields) {
+function tokenizeHeader(record, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment, onAlignmentShiftedFields, onAlignmentTruncatedField) {
   const defEnd = record.indexOf(d.field, 2);
   const definition = defEnd === -1 ? record.slice(2) : record.slice(2, defEnd);
   const head = [opaqueField(record.slice(0, Math.min(1, record.length))), opaqueField(definition)];
@@ -1251,17 +1330,27 @@ function tokenizeHeader(record, d, onUnknownEscape, onUnpairedEscape, onSwallowe
     (i) => onUnpairedEscape?.(i + 2),
     (i) => onSwallowedDelimiter?.(i + 2),
     (i) => onAmbiguousAlignment?.(i + 2),
-    (i) => onAlignmentShiftedFields?.(i + 2)
+    (i) => onAlignmentShiftedFields?.(i + 2),
+    (i) => onAlignmentTruncatedField?.(i + 2)
   );
   return [...head, ...data];
 }
 function opaqueField(raw) {
   return { raw, components: [raw], repeats: [[raw]] };
 }
-function toField(raw, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment) {
-  const rawRepeats = splitEscapeAware(raw, d.repeat, d.escape, () => {
-    onAmbiguousAlignment();
-  });
+function toField(raw, d, onUnknownEscape, onUnpairedEscape, onSwallowedDelimiter, onAmbiguousAlignment, onAlignmentTruncatedField) {
+  const rawRepeats = splitEscapeAware(
+    raw,
+    d.repeat,
+    d.escape,
+    () => {
+      onAmbiguousAlignment();
+    },
+    void 0,
+    () => {
+      onAlignmentTruncatedField();
+    }
+  );
   const repeats = rawRepeats.map(
     (rep) => splitEscapeAware(rep, d.component, d.escape, () => {
       onAmbiguousAlignment();
@@ -1412,6 +1501,11 @@ function buildRecord(line2, recordIndex, d, warnings) {
       alignmentShiftedFields({ recordIndex, recordType: rawType, fieldIndex: fieldIndex + 1 })
     );
   };
+  const onAlignmentTruncatedField = (fieldIndex) => {
+    warnings.push(
+      alignmentTruncatedField({ recordIndex, recordType: rawType, fieldIndex: fieldIndex + 1 })
+    );
+  };
   const fields = rawType === "H" ? tokenizeHeader(
     line2,
     d,
@@ -1419,7 +1513,8 @@ function buildRecord(line2, recordIndex, d, warnings) {
     onUnpairedEscape,
     onSwallowedDelimiter,
     onAmbiguousAlignment,
-    onAlignmentShiftedFields
+    onAlignmentShiftedFields,
+    onAlignmentTruncatedField
   ) : tokenizeRecord(
     line2,
     d,
@@ -1427,7 +1522,8 @@ function buildRecord(line2, recordIndex, d, warnings) {
     onUnpairedEscape,
     onSwallowedDelimiter,
     onAmbiguousAlignment,
-    onAlignmentShiftedFields
+    onAlignmentShiftedFields,
+    onAlignmentTruncatedField
   );
   if (fields.length === 1 && line2.slice(1).trim().length > 0) {
     warnings.push(fieldsUnseparated({ recordIndex, recordType: rawType }));
@@ -2640,7 +2736,7 @@ function concatBytes3(chunks) {
 }
 
 // src/index.ts
-var VERSION = "0.0.17";
+var VERSION = "0.0.18";
 
 exports.ALL_ASTM_WARNING_CODES = ALL_ASTM_WARNING_CODES;
 exports.AMBIGUOUS_CODES = AMBIGUOUS_CODES;
@@ -2665,6 +2761,7 @@ exports.TOLERABLE_CODES = TOLERABLE_CODES;
 exports.VERSION = VERSION;
 exports.WARNING_CODES = WARNING_CODES;
 exports.alignmentShiftedFields = alignmentShiftedFields;
+exports.alignmentTruncatedField = alignmentTruncatedField;
 exports.ambiguousEscapeAlignment = ambiguousEscapeAlignment;
 exports.ambiguousMessageKind = ambiguousMessageKind;
 exports.ambiguousValueSplit = ambiguousValueSplit;