@cosyte/astm 0.0.14 → 0.0.17

package/dist/index.d.cts

@@ -74,18 +74,170 @@ declare const WARNING_CODES: {
      * boundaries, silently, and this can happen to one record inside a run of these warnings); and a
      * set differing in the repeat, component or escape role usually splits into fields normally,
      * where a mis-split component can cost a test identity while the value survives, and where an
-     * `&X&` sequence whose body is a delimiter is an opaque atom, so that delimiter does not split
+     * `&X&` sequence whose body is an unrecognized character that is itself a delimiter in force is an
+     * opaque atom, so that delimiter does not split
      * and every field after it shifts. The escape role's worst case has narrowed and not
      * disappeared: an escape character heading no sequence is now read as a literal and reported
      * under {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER} rather than merging the rest of the
-     * record, but a delimiter swallowed inside an `&X&` body is reported only by
-     * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, which is tolerable. Treat this code as a
+     * record, and a delimiter swallowed inside an `&X&` body now raises
+     * {@link WARNING_CODES.ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE} as well as the tolerable
+     * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, though it still splits the same way. The
+     * mirror of that case, where the leftmost alignment lets a delimiter split that a competing
+     * alignment would have held, gains a boundary rather than losing one, so the record splits into
+     * more fields than another reading gives and this code cannot see it either
+     * ({@link WARNING_CODES.ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT} reports that). Treat this code as a
      * report that one record definitely lost its fields, never as a sweep that would have fired if
      * any had.
      */
     readonly ASTM_RECORD_FIELDS_UNSEPARATED: "ASTM_RECORD_FIELDS_UNSEPARATED";
     /** The header declared delimiters other than the canonical `H|\^&`: tolerated, noted. */
     readonly ASTM_NONSTANDARD_DELIMITERS: "ASTM_NONSTANDARD_DELIMITERS";
+    /**
+     * A header declared **one character in two roles**, so the boundary between those two roles is
+     * not recoverable from the bytes. The declaration is still read and honored and no record is
+     * dropped: what is gone is a distinction the sender's own bytes no longer carry.
+     *
+     * The field separator is not part of this: a declaration naming it in another role is refused
+     * earlier (the `ASTM_RECORD_UNDECLARED_DELIMITERS` fatal on the first header,
+     * {@link WARNING_CODES.ASTM_RECORD_UNREADABLE_REDECLARATION} on a later one). What this code
+     * covers is the three unordered pairs among the rest: **repeat/component, repeat/escape,
+     * component/escape**.
+     *
+     * Measured on `H|^^&` (repeat and component both `^`): the field `A^B^C^D` reads back as four
+     * repeats of one component each, so `components` holds only `A` and a two-repeats-of-two-components
+     * reading cannot be recovered. Measured on `H|\&&` (component and escape both `&`): `A&B` splits
+     * into two components while `A&F&B` reads as the single component `A|B`, so the same character
+     * means two different things depending on what follows it.
+     *
+     * **It is not tolerable**, and the reason is the pair it travels with: such a set is always
+     * non-canonical, so before this code existed the only warning on the stream was
+     * {@link WARNING_CODES.ASTM_NONSTANDARD_DELIMITERS}, which a profile may tolerate. That made a
+     * structurally unreadable declaration indistinguishable, to a strict consumer, from an ordinary
+     * vendor set. Emit refuses the same sets outright (`ASTM_EMIT_INVALID_DELIMITERS`).
+     *
+     * One warning per header that **changes** the set in force into such a set, not one per colliding
+     * pair. A later header restating the colliding set already in force is a no-op and warns nothing,
+     * on the same rule as {@link WARNING_CODES.ASTM_NONSTANDARD_DELIMITERS}: the set it names was
+     * already reported when it came into force.
+     */
+    readonly ASTM_RECORD_DELIMITER_ROLE_COLLISION: "ASTM_RECORD_DELIMITER_ROLE_COLLISION";
+    /**
+     * An escape sequence whose body was **not** a recognized mnemonic held a character that is one of
+     * the three splitting delimiters in force, and the atom rule (an `&X&` triple is opaque) kept it
+     * out of the split, so a boundary the bytes carried never became one. The sequence is preserved
+     * verbatim in the value; nothing is dropped and nothing is re-split.
+     *
+     * Measured on the canonical set: `R|1|^^^687|28.6&|&U/L||||F` reads `value` = `28.6&|&U/L`, with
+     * **no units** and status `unspecified` rather than `final`.
+     *
+     * **This is the code that says a boundary was lost.** The same condition also raises
+     * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, which stays and stays tolerable: that code
+     * reports only that a body was not recognized, which is true of bodies that cost nothing. This one
+     * is the narrower, safety-critical half, and no profile may tolerate it.
+     *
+     * **What it does not do is repair anything.** The atom rule is unchanged (it is what keeps `&F&`
+     * one token under a set that names `F` as a delimiter), so the value is byte-identical to what it
+     * was before this code existed. It also cannot see the condition through a re-emit: emit rewrites
+     * the preserved sequence into recognized mnemonics, and the resulting stream says that value
+     * unambiguously, so a second-generation read is silent and correct about its own bytes. The place
+     * to catch this is the first read of the wire bytes, which is where it now refuses a strict parse.
+     */
+    readonly ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE: "ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE";
+    /**
+     * Escape sequences are matched greedily and leftmost, so the escape character that **closed** an
+     * unrecognized sequence could not also **open** the next one. Where it could have, and where the
+     * body it would have held is the delimiter that was split on, the same bytes carry two alignments
+     * that disagree by one boundary: under the reading taken that delimiter ends a field, repeat or
+     * component, and under the other it sits inside an opaque atom and ends nothing. The leftmost
+     * reading is kept, every byte is preserved, and nothing is re-split.
+     *
+     * **This is the mirror of {@link WARNING_CODES.ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE}, and
+     * the direction is the reason it needs its own code.** That one reports a boundary the reading
+     * **lost**; this one reports a boundary the reading may have **gained**, which is the more
+     * dangerous direction, because a gained boundary hands back a value the sender's bytes do not
+     * unambiguously carry. Measured on the canonical set: `R|1|^^^687|28.6&Z&|&U/L||||F` reads
+     * `value` = `28.6&Z&` and `units` = `&U/L` under the leftmost alignment, and reads as a single
+     * unsplit field carrying both under the other.
+     *
+     * **Two exclusions, both deliberate, and the first is wider than its own argument.** Where the
+     * earlier sequence's body is a **recognized** mnemonic nothing is reported, because the reading
+     * taken interprets a construct (`&F&` is the sender escaping a field separator, which is what the
+     * mechanism is for) while the competing alignment's body is a delimiter character it usually
+     * cannot interpret at all, so this codec's own vocabulary prefers the reading taken. That is not
+     * the same as the reading taken being conformant, and where the declared set names a mnemonic
+     * letter as a splitting delimiter both alignments interpret one construct and neither is
+     * preferred, yet this stays silent. Both residues are measured and recorded rather than closed by
+     * widening the test. And where the escape
+     * character after the delimiter does not itself close a sequence there is no competing alignment
+     * at all, so an ordinary escaped value followed by an ordinary boundary is silent.
+     *
+     * **It is a report, not a repair, and not a round-trip guard.** The reading is unchanged: picking
+     * the other alignment would be a different guess with no more evidence behind it. Emit then
+     * 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. The first read of the wire bytes is the only place the ambiguity exists to be caught.
+     */
+    readonly ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT: "ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT";
+    /**
+     * Two escape alignments of the same bytes disagreed about a **field** boundary, the reading taken
+     * kept it, and the escape character that reading resumes on **heads no sequence at all**, so the
+     * boundary was bought with a byte this reading cannot read while the competing alignment is
+     * exactly the reading that can. Every field after that point sits one place further right than the
+     * competing alignment puts it.
+     *
+     * **The shift is the harm, and on a result record it reaches the status slot.** Measured on the
+     * canonical set, `R|1|^^^687|28.6&F&|&U/L||||F` reads **9** fields under the reading taken and
+     * **8** under the competing one, so the sender's trailing `F` lands in field 9 (the result status)
+     * under the first and in no field at all under the second. The parse hands back units `&U/L` and a
+     * status of **`final`**, and both are consequences of the alignment rather than values the sender
+     * placed in those slots. A downstream system reading `final` would act on a result the bytes do
+     * not say was finalised. Before this code the only warning on that stream was the **tolerable**
+     * {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER}, so the widest gate-legal profile plus
+     * `{ strict: true }` accepted it.
+     *
+     * **It is a report, not a repair.** The split is unchanged, every decoded byte is identical, and
+     * the units and status read are the ones that were always read. Picking the other alignment would
+     * be a different guess with no more evidence behind it, and it would change values on a published
+     * package. What is new is that the shift is reported by a code no profile may tolerate.
+     *
+     * **It fires alongside {@link WARNING_CODES.ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT}, not instead
+     * of it, and neither test is a widening of the other.** That code asks whether this codec's
+     * vocabulary prefers the reading taken *at* the contested position, and is silent where the
+     * earlier body is a recognized mnemonic. This one asks what the reading taken makes of the bytes
+     * *after* the boundary, and does not consult the earlier body at all.
+     *
+     * **Two deliberate bounds, both stated rather than left to be found.**
+     * - **Only the field role, and that bound is a CHOICE rather than a consequence.** A gained repeat
+     *   or component boundary divides one field and reaches nothing outside it, so it moves no
+     *   **field-indexed** slot: the units and the status stay where they were. **It does not follow
+     *   that it moves no modeled slot at all, and writing that down would be false.** Components are
+     *   modeled *inside* a field: a Universal Test ID's four components are the LOINC-candidate slot,
+     *   the test name, the **coding scheme** and the **local code**, and a patient name's three are
+     *   last, first and middle. A gained component boundary shifts those, so a local code can be read
+     *   as a coding scheme and a given name as a middle name. Measured, and **where the earlier body is
+     *   a recognized mnemonic, reported by nothing** (only the tolerable
+     *   {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER} fires, so a gate-legal profile accepts it).
+     *   An **unrecognized** earlier body raises
+     *   {@link WARNING_CODES.ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT} there and is refused, which is the
+     *   same split this code's own exclusion takes. It is a separate, open condition rather than something this
+     *   code covers, because wiring this sink to another split is a different criterion needing its own
+     *   population measurement. The repeat role costs the **value**, which this code does not report
+     *   either.
+     * - **The tail is weighed one construct deep.** Where the escape character the reading taken
+     *   resumes on heads a sequence this codec *recognizes*, the reading taken interprets it and the
+     *   competing alignment would leave it bare, so the bytes prefer the reading taken: under a set
+     *   naming the field 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 reading taken still consumes it while the
+     *   competing alignment would leave **two** escape characters bare, so the preference is stronger
+     *   again, and this stays silent there even though the field shift 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.
+     */
+    readonly ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS: "ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS";
     /** An escape sequence body was not one of `&F&`/`&S&`/`&R&`/`&E&`: preserved verbatim. */
     readonly ASTM_UNKNOWN_ESCAPE_SEQUENCE: "ASTM_UNKNOWN_ESCAPE_SEQUENCE";
     /**
@@ -107,7 +259,8 @@ declare const WARNING_CODES: {
      * *different* escape character in the same record may still head a real three-character sequence,
      * and if that sequence's body happens to be a delimiter (`&|&` under the canonical set) the atom
      * rule means that delimiter does not split. That case is reported separately, under
-     * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, and it can still cost a field boundary.
+     * {@link WARNING_CODES.ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE}, and it still costs a field
+     * boundary.
      */
     readonly ASTM_UNPAIRED_ESCAPE_CHARACTER: "ASTM_UNPAIRED_ESCAPE_CHARACTER";
     /**
@@ -173,7 +326,8 @@ declare const WARNING_CODES: {
      */
     readonly ASTM_RECORD_DELIMITERS_REDECLARED: "ASTM_RECORD_DELIMITERS_REDECLARED";
     /**
-     * A later `H` (header) record could not declare a usable delimiter set: it was too short, or the
+     * A later `H` (header) record could not declare a usable delimiter set: it was not a header, it
+     * was too short, its delimiter definition held fewer than three characters, or the
      * field separator it named also appeared among the other three, leaving the four roles
      * indistinguishable. The delimiters **already in force are kept** and every record is still surfaced;
      * a set is never guessed and no record is dropped.
@@ -283,6 +437,80 @@ declare function fieldsUnseparated(position: AstmPosition): AstmRecordWarning;
  * ```
  */
 declare function nonStandardDelimiters(position: AstmPosition): AstmRecordWarning;
+/**
+ * Build an `ASTM_RECORD_DELIMITER_ROLE_COLLISION` warning. Emitted when a header
+ * declares one character in two of the repeat / component / escape roles. The
+ * declaration is honored and no record is dropped; the message names no character,
+ * because a delimiter is a byte off the wire.
+ *
+ * A profile may **not** tolerate this code: it reports a distinction the bytes no
+ * longer carry, and the only other warning such a set raises
+ * ({@link WARNING_CODES.ASTM_NONSTANDARD_DELIMITERS}) is tolerable.
+ *
+ * @example
+ * ```ts
+ * import { delimiterRoleCollision } from "@cosyte/astm";
+ * delimiterRoleCollision({ recordIndex: 0, recordType: "H" });
+ * ```
+ */
+declare function delimiterRoleCollision(position: AstmPosition): AstmRecordWarning;
+/**
+ * Build an `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` warning. Emitted when an
+ * unrecognized escape body is itself a splitting delimiter in force, so the atom
+ * rule kept it out of the split. The value is preserved verbatim and is identical
+ * with the warning and without it; what the warning reports is the boundary that
+ * did not happen.
+ *
+ * A profile may **not** tolerate this code. It fires alongside
+ * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, which remains tolerable and
+ * reports the strictly weaker fact that a body was not recognized.
+ *
+ * @example
+ * ```ts
+ * import { delimiterSwallowedByEscape } from "@cosyte/astm";
+ * delimiterSwallowedByEscape({ recordIndex: 4, recordType: "R", fieldIndex: 4 });
+ * ```
+ */
+declare function delimiterSwallowedByEscape(position: AstmPosition): AstmRecordWarning;
+/**
+ * Build an `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT` warning. Emitted when the escape
+ * character that closed an unrecognized escape sequence could instead have opened one
+ * holding the delimiter that was split on, so the bytes carry two alignments that
+ * disagree about that boundary. The leftmost alignment is kept and every byte is
+ * preserved; what the warning reports is that the boundary is a choice.
+ *
+ * A profile may **not** tolerate this code. It fires alongside
+ * {@link WARNING_CODES.ASTM_UNKNOWN_ESCAPE_SEQUENCE}, which remains tolerable and
+ * reports the strictly weaker fact that a body was not recognized.
+ *
+ * @example
+ * ```ts
+ * import { ambiguousEscapeAlignment } from "@cosyte/astm";
+ * ambiguousEscapeAlignment({ recordIndex: 4, recordType: "R", fieldIndex: 4 });
+ * ```
+ */
+declare function ambiguousEscapeAlignment(position: AstmPosition): AstmRecordWarning;
+/**
+ * Build an `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS` warning. Emitted when a competing escape
+ * alignment decided a **field** boundary and the escape character the reading taken resumes on
+ * heads no sequence of its own, so every field after that point sits one place further right than
+ * the competing alignment puts it. On a result record that reaches the units and the **result
+ * status**: a trailing status letter lands in field 9 under the reading taken and in no field at
+ * all under the competing one.
+ *
+ * A profile may **not** tolerate this code. It fires alongside
+ * {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER}, which remains tolerable and reports the
+ * strictly weaker fact that one escape character was read as a literal, and alongside
+ * {@link WARNING_CODES.ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT} where that also applies. The reading
+ * is unchanged: this reports the shift, it does not repair it.
+ *
+ * @example
+ * ```ts
+ * import { alignmentShiftedFields } from "@cosyte/astm";
+ * alignmentShiftedFields({ recordIndex: 2, recordType: "R", fieldIndex: 4 });
+ * ```
+ */
+declare function alignmentShiftedFields(position: AstmPosition): AstmRecordWarning;
 /**
  * Build an `ASTM_RECORD_DELIMITERS_REDECLARED` warning. Emitted when a later `H`
  * record declares a delimiter set different from the one in force; the new set is
@@ -328,8 +556,10 @@ declare function unknownEscapeSequence(position: AstmPosition): AstmRecordWarnin
  *
  * **It is a statement about that one character, not about the record.** A
  * different escape character in the same record may head a real three-character
- * sequence, and if that sequence's body is a delimiter, that delimiter does not
- * split. See {@link WARNING_CODES.ASTM_UNPAIRED_ESCAPE_CHARACTER}.
+ * sequence, and if that sequence's body is an unrecognized character that is itself a delimiter in
+ * force, that delimiter does not
+ * split, which is reported separately by
+ * {@link WARNING_CODES.ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE}.
  *
  * A profile **may** tolerate this code: the value it reports is byte-identical
  * with the warning and without it, because reading the character as a literal is
@@ -528,13 +758,39 @@ interface Delimiters {
  * ```
  */
 declare const CANONICAL_DELIMITERS: Delimiters;
+/**
+ * Why a header record could not declare a usable delimiter set. Four distinct
+ * conditions, kept distinct because a consumer is told which one it was and two of
+ * them describe records that are **not** short.
+ *
+ * - `not-a-header`: the record does not begin with an `H` type letter.
+ * - `record-too-short`: fewer than five characters, so `H` plus a field separator
+ *   plus a three-character definition cannot fit.
+ * - `definition-truncated`: the delimiter-definition field runs to the next field
+ *   separator (or to the end of the record) and holds fewer than three characters.
+ *   **This is the one a full-length header reaches**, and it is what a declaration
+ *   naming its own field separator among the other three produces, because that
+ *   separator ends the definition where it appears.
+ * - `field-separator-reused`: the field separator is also the repeat, component or
+ *   escape character.
+ */
+type DelimiterDeclarationFault = "not-a-header" | "record-too-short" | "definition-truncated" | "field-separator-reused";
+/** The result of reading delimiters from a header record: either resolved or a named failure. */
+type DelimiterReadResult = {
+    readonly ok: true;
+    readonly delimiters: Delimiters;
+} | {
+    readonly ok: false;
+    readonly fault: DelimiterDeclarationFault;
+};
 /**
  * Read the four delimiters from a header record's raw text (a single `H`
  * record, its terminator already stripped).
  *
- * Returns `undefined` when the record cannot declare all four delimiters: it is
- * shorter than `H` + a field separator + a 3-char delimiter definition, or the
- * field separator it names also appears among the other three.
+ * Returns `undefined` when the record cannot declare all four delimiters. The four
+ * ways that happens are named by {@link readDelimiterDeclaration}, which is this
+ * function with the reason kept; use it wherever the reason is shown to a consumer,
+ * because "too short" is false of some of them.
  *
  * What the caller does with that depends on **which** header it is. On the first
  * header it is the `ASTM_RECORD_UNDECLARED_DELIMITERS` fatal, because there is no
@@ -543,6 +799,12 @@ declare const CANONICAL_DELIMITERS: Delimiters;
  * and an `ASTM_RECORD_UNREADABLE_REDECLARATION` warning is raised instead; a set is
  * never guessed and no record is dropped.
  *
+ * **A set two of whose other three roles share a character is resolved, not
+ * refused**, because the stream is still readable and refusing it would drop
+ * records the sender did send. What it costs is the boundary between those two
+ * roles, which the bytes no longer carry: see {@link hasCollidingRoles}, which
+ * the parse path calls to report it (`ASTM_RECORD_DELIMITER_ROLE_COLLISION`).
+ *
  * This function does not throw: delimiter resolution and the escalation decision are
  * kept separate so the reader stays pure and testable.
  *
@@ -556,6 +818,68 @@ declare const CANONICAL_DELIMITERS: Delimiters;
  * ```
  */
 declare function readDelimiters(headerRecord: string): Delimiters | undefined;
+/**
+ * The same read as {@link readDelimiters}, keeping **why** it failed.
+ *
+ * The reason is not cosmetic. A caller that reports every failure as "too short"
+ * says something false about `H||^&`, a full-length header whose definition field is
+ * empty because its own field separator ends it, and a consumer reading that
+ * diagnostic looks for the wrong thing. The two conditions are separate rules that
+ * happen to coincide today (see the fault list on
+ * {@link DelimiterDeclarationFault}), so they are named separately.
+ *
+ * **`field-separator-reused` is unreachable through this function today, and the
+ * check stays.** A field separator occurring in the definition positions sits at
+ * index 2, 3 or 4, so it ends the definition where it appears and the definition is
+ * under three characters: `definition-truncated` answers first, every time. The
+ * outcome is right either way (such a declaration does not resolve at all). The
+ * check is the statement of an invariant the length rule currently enforces on its
+ * behalf, and the two are not the same rule: a change to how the definition field is
+ * bounded would separate them again. Deleting it would leave the invariant
+ * unstated and the change silent.
+ *
+ * @param headerRecord - The raw `H` record text (no trailing CR/LF).
+ * @returns The resolved delimiters, or the named reason they could not be read.
+ * @example
+ * ```ts
+ * import { readDelimiterDeclaration } from "@cosyte/astm";
+ * readDelimiterDeclaration("H|\\^&").ok; // true
+ * readDelimiterDeclaration("H||^&"); // { ok: false, fault: "definition-truncated" }
+ * ```
+ */
+declare function readDelimiterDeclaration(headerRecord: string): DelimiterReadResult;
+/**
+ * Whether a resolved set names one character in two roles, so the boundary
+ * between those two roles cannot be recovered from the bytes.
+ *
+ * {@link readDelimiters} already refuses a declaration whose **field** separator
+ * is one of the other three (it returns `undefined`, which is the
+ * `ASTM_RECORD_UNDECLARED_DELIMITERS` fatal on the first header and the
+ * `ASTM_RECORD_UNREADABLE_REDECLARATION` warning on a later one), so what is left
+ * to test here is the three unordered pairs among the remaining roles:
+ * **repeat/component, repeat/escape, and component/escape**. Three pairs, named
+ * rather than counted, because the count is only meaningful with the list.
+ *
+ * Such a declaration is read and honored (nothing is guessed, no record is
+ * dropped) and the loss it causes is real and was previously silent. Measured on
+ * the canonical-looking `H|^^&`, where the repeat and component roles are both
+ * `^`: the field `A^B^C^D` reads back as **four repeats of one component each**,
+ * so a two-repeats-of-two-components reading is unrecoverable and `components`
+ * holds only `A`. On `H|\&&`, where the component and escape roles are both `&`,
+ * the same character splits (`A&B` reads as two components) or opens an atom
+ * (`A&F&B` reads as the single component `A|B`) depending only on what follows
+ * it. Emit refuses such a set outright (`ASTM_EMIT_INVALID_DELIMITERS`).
+ *
+ * @param d - A resolved delimiter set.
+ * @returns `true` iff two of the repeat / component / escape roles share a character.
+ * @example
+ * ```ts
+ * import { hasCollidingRoles, readDelimiters } from "@cosyte/astm";
+ * hasCollidingRoles(readDelimiters("H|\\^&")!); // false
+ * hasCollidingRoles(readDelimiters("H|^^&")!); // true (repeat === component)
+ * ```
+ */
+declare function hasCollidingRoles(d: Delimiters): boolean;
 /**
  * Whether a resolved delimiter set differs from the canonical `H|\^&`. A `true`
  * result is a tolerated vendor quirk, surfaced as a value-free warning so a
@@ -2042,7 +2366,10 @@ declare function attachComments(records: readonly AstmRecord[], warnings: AstmRe
  * set (a non-canonical source is normalized to `H|\^&` by default). Normalizing sets the
  * four delimiter **roles**; it does not delete a declaration's surplus characters, so a
  * canonically-declared header that arrived carrying surplus keeps it on the default path
- * too.
+ * too, **except where that surplus could not be read back as surplus, when all of it is
+ * dropped** (see `declarationResidual` below). Emit re-encodes what it read, so bytes
+ * can differ without anything being lost: `O&BRIEN` in a canonical stream goes out as
+ * `O&E&BRIEN`.
  *
  * **One delimiter set for the whole stream.** Every record (including `H`, `M` and `S`)
  * is emitted against the delimiters being emitted with, and the header declares that same
@@ -2063,7 +2390,11 @@ declare function attachComments(records: readonly AstmRecord[], warnings: AstmRe
  * `H|\^&#` rather than losing the `#`. That holds on the **default** canonical path as
  * well as when a set is passed explicitly: the surplus of a canonically-declared header
  * survives normalization, because normalization is about the four roles and the surplus
- * has none.
+ * has none. It stops holding where the surplus itself could not be read back, and then
+ * **the whole surplus is dropped, not the offending character alone**, on the default
+ * path as much as any other: `declarationResidual` states which surpluses those are and
+ * why an all-or-nothing drop is the only one of the available answers that invents
+ * nothing.
  *
  * **Never break framing.** A component leaf that contains a record terminator
  * (`CR`/`LF`) cannot be escaped by the ASTM escape codec (only the four declared
@@ -2084,10 +2415,15 @@ declare function attachComments(records: readonly AstmRecord[], warnings: AstmRe
  * output, which is why they are refused at this one.
  *
  * **One position is not a modeled value and does not keep the byte:** the surplus
- * of a header's delimiter declaration, where any control character is dropped
+ * of a header's delimiter declaration, where a control character is dropped
  * silently (see `declarationResidual` below, where that disposition is argued and
  * where it long predates the frame-layer refusal). So "the record layer carries
  * these bytes" is a statement about values, not about every byte of every line.
+ * Measured, one character at a time in the surplus of an otherwise spec-clean
+ * `H|\^&` header: **31 of the 33 C0/`DEL` characters reach that rule and are
+ * dropped**, with `warnings: []` and no error. The two that do not are `CR` and
+ * `LF`, which never reach it at all, because they end the record while it is being
+ * read and so are never part of any surplus the model carries.
  *
  * **Check the delimiter set before writing.** Three conditions are required for the
  * emitted bytes to read back as the records that produced them (each separator exactly
@@ -2104,10 +2440,18 @@ declare function attachComments(records: readonly AstmRecord[], warnings: AstmRe
  *
  * **What is still not guaranteed.** Together the two checks guarantee that every
  * record re-reads as its own *type*. They do not guarantee that every *field* of it
- * lands where it did: an escape sequence whose body is itself a delimiter is read as
+ * lands where it did: an escape sequence whose body is an unrecognized character that is itself a
+ * delimiter in force is read as
  * one opaque atom, so that delimiter never becomes a boundary and the fields after it
- * shift. That is reported on the parse side (`ASTM_UNKNOWN_ESCAPE_SEQUENCE`) and is
- * not what these refusals cover.
+ * shift. That is reported on the parse side, by `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`
+ * (which no profile may tolerate) alongside the tolerable `ASTM_UNKNOWN_ESCAPE_SEQUENCE`, and is
+ * not what these refusals cover. Nor is the mirror of it: sequences are matched leftmost, so one
+ * can end where another could have begun and the delimiter between them splits where the competing
+ * alignment would have held it, reported by `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`. **Neither
+ * report survives this serializer**, by construction rather than by oversight: it rewrites the
+ * preserved characters into recognized mnemonics, so the emitted stream carries the reading that
+ * was taken with nothing ambiguous left in it, and a second-generation parse is silent and correct
+ * about its own bytes. Catch both on the first read of the wire bytes.
  */
 
 /**
@@ -2166,10 +2510,12 @@ declare class AstmSerializeError extends Error {
 type AstmSerializeErrorCode = "ASTM_EMIT_UNENCODABLE_VALUE" | "ASTM_EMIT_INVALID_DELIMITERS" | "ASTM_EMIT_TYPE_LETTER_COLLISION";
 /**
  * Escape-encode one component leaf for spec-clean emit: the inverse of
- * `decodeEscapes`. The **escape character itself is encoded first** (`&` → `&E&`)
- * so a later delimiter substitution can never double-encode the `&` it just
- * introduced; then the field / component / repeat delimiters map to their
- * mnemonics.
+ * `decodeEscapes`. Each character is read **once**, in one left-to-right pass, and
+ * written either as itself or as a whole `escape` + mnemonic + `escape` triple
+ * (`&` → `&E&`, the field / component / repeat delimiters → `&F&` / `&S&` / `&R&`).
+ * Nothing this encoder writes is examined again, which is what makes it the exact
+ * inverse of the decoder: the decoder reads the same output one token at a time,
+ * so every triple it meets is a triple this encoder wrote.
  *
  * A `CR`/`LF` in the leaf has no escape mnemonic and would break framing, so it
  * is rejected with an {@link AstmSerializeError} rather than emitted raw, as is a
@@ -2199,7 +2545,11 @@ declare function encodeComponent(leaf: string, d: Delimiters, recordIndex?: numb
  * The header (`H`) is special-cased: its delimiter-definition field is emitted as
  * the **literal** declaration of `d`, never escaped, escaping it would corrupt the
  * very declaration a reader depends on, followed by any characters the modeled
- * declaration carried beyond the three a reader takes its roles from. Manufacturer
+ * declaration carried beyond the three a reader takes its roles from. Those surplus
+ * characters are kept unless the surplus could not be read back as surplus, when
+ * **all** of it is dropped: that covers a surplus carrying the field delimiter or
+ * any control character, and it is silent, because emit has no warning channel.
+ * Manufacturer
  * (`M`) and scientific (`S`) records are reproduced **byte-identically** from their
  * preserved `rawLine` when they are already in `d`, and re-encoded from their fields
  * when they are not, so their fields never collapse into one on the next read.
@@ -2234,7 +2584,11 @@ declare function serializeAstmRecord(record: AstmRecord, d?: Delimiters): string
  * re-parsing it recovers every field. Passing `d` explicitly emits against that set
  * instead, and the header declares it. Normalization replaces the four delimiter
  * **roles**; a header declaration carrying characters beyond the three that hold a
- * role keeps them, on this path as on any other, rather than being truncated.
+ * role keeps them, on this path as on any other, rather than being truncated. The
+ * exception is a surplus that could not be read back as one, carrying the field
+ * delimiter or any control character: there the **whole** surplus is dropped, on
+ * every path including the default one, and silently, because emit returns a bare
+ * string with no channel to say so.
  *
  * **`d` is checked before anything is written.** Each of the four separators must be
  * exactly one character, none may be a record terminator, and no two may share a
@@ -2251,9 +2605,14 @@ declare function serializeAstmRecord(record: AstmRecord, d?: Delimiters): string
  * therefore checked to start with the letter the record models, and one that does
  * not is `ASTM_EMIT_TYPE_LETTER_COLLISION` rather than a stream that reads back as
  * different records. What neither check promises is that every *field* lands where
- * it did: an escape sequence whose body is a delimiter is an opaque atom, so that
+ * it did: an escape sequence whose body is an unrecognized character that is itself a delimiter in
+ * force is an opaque atom, so that
  * delimiter never becomes a boundary, and the parse side reports that
- * (`ASTM_UNKNOWN_ESCAPE_SEQUENCE`) rather than emit refusing it.
+ * (`ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`, plus the tolerable
+ * `ASTM_UNKNOWN_ESCAPE_SEQUENCE`) rather than emit refusing it. The mirror case, where a sequence
+ * ends where another could have begun so a delimiter splits that the competing alignment would
+ * have held, is reported the same way (`ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`). Emitting
+ * normalizes both away rather than preserving them, so neither reaches a second generation.
  *
  * @param input - A parsed {@link AstmMessage} or a list of {@link AstmRecord}s.
  * @param d - The delimiters to emit against; defaults to the canonical `H|\^&` set.
@@ -2874,6 +3233,20 @@ declare function classifyMessage(records: readonly AstmRecord[]): AstmMessageCla
  *   unrecognized escape sequence encountered, so the caller can warn.
  * @param onUnpairedEscape - Called (with the 0-based field index) for each escape
  *   character that heads no escape sequence and was therefore read as a literal.
+ * @param onSwallowedDelimiter - Called (with the 0-based field index) for each
+ *   unrecognized escape sequence whose body is a splitting delimiter in force, so
+ *   that delimiter never became a boundary.
+ * @param onAmbiguousAlignment - Called (with the 0-based field index) for each
+ *   unrecognized escape sequence whose closing escape character could instead have
+ *   opened one holding the delimiter that split, so the boundary is one of two
+ *   readings the bytes carry.
+ * @param onAlignmentShiftedFields - Called (with the 0-based field index) for each
+ *   contested **field** boundary the reading took while resuming on an escape
+ *   character that heads no sequence, so every later field is one place further
+ *   right than the competing alignment puts it. Wired only to the field split: a
+ *   repeat or component boundary divides one field and so moves no field-indexed
+ *   slot. That is a choice and not a consequence, because components are modeled
+ *   inside a field; see {@link ShiftedFieldsSink}.
  * @returns The record's fields.
  * @example
  * ```ts
@@ -2882,7 +3255,7 @@ declare function classifyMessage(records: readonly AstmRecord[]): AstmMessageCla
  * fields[3].components[0]; // "28.6"
  * ```
  */
-declare function tokenizeRecord(record: string, d: Delimiters, onUnknownEscape?: (fieldIndex: number) => void, onUnpairedEscape?: (fieldIndex: number) => void): AstmField[];
+declare function tokenizeRecord(record: string, d: Delimiters, onUnknownEscape?: (fieldIndex: number) => void, onUnpairedEscape?: (fieldIndex: number) => void, onSwallowedDelimiter?: (fieldIndex: number) => void, onAmbiguousAlignment?: (fieldIndex: number) => void, onAlignmentShiftedFields?: (fieldIndex: number) => void): AstmField[];
 /**
  * Tokenize an `H` (header) record into its fields.
  *
@@ -2907,6 +3280,17 @@ declare function tokenizeRecord(record: string, d: Delimiters, onUnknownEscape?:
  * @param onUnpairedEscape - Called with the 0-based whole-record field index for
  *   each unpaired escape character in the data portion. The declaration itself is
  *   opaque, so the escape character it names never reports here.
+ * @param onSwallowedDelimiter - Called with the 0-based whole-record field index
+ *   for each unrecognized escape sequence in the data portion whose body is a
+ *   splitting delimiter in force. The declaration is opaque, so the delimiters it
+ *   names literally never report here.
+ * @param onAmbiguousAlignment - Called with the 0-based whole-record field index for
+ *   each competing escape alignment in the data portion. The declaration is opaque,
+ *   so the characters it names literally never report here either.
+ * @param onAlignmentShiftedFields - Called with the 0-based whole-record field index
+ *   for each contested field boundary in the data portion whose reading resumes on
+ *   an escape character heading no sequence. The declaration is opaque, so it never
+ *   reports here either.
  * @returns The header's fields.
  * @example
  * ```ts
@@ -2916,7 +3300,7 @@ declare function tokenizeRecord(record: string, d: Delimiters, onUnknownEscape?:
  * fields[4].raw; // "sender"
  * ```
  */
-declare function tokenizeHeader(record: string, d: Delimiters, onUnknownEscape?: (fieldIndex: number) => void, onUnpairedEscape?: (fieldIndex: number) => void): AstmField[];
+declare function tokenizeHeader(record: string, d: Delimiters, onUnknownEscape?: (fieldIndex: number) => void, onUnpairedEscape?: (fieldIndex: number) => void, onSwallowedDelimiter?: (fieldIndex: number) => void, onAmbiguousAlignment?: (fieldIndex: number) => void, onAlignmentShiftedFields?: (fieldIndex: number) => void): AstmField[];
 /**
  * The primary scalar of a field: its first repeat's first component, decoded.
  * Returns `undefined` for a truly empty field so callers can distinguish
@@ -2968,7 +3352,19 @@ declare const FATAL_CODES: {
     readonly EMPTY_INPUT: "EMPTY_INPUT";
     /** The first record is not an `H` (header) record: an ASTM message must lead with `H`. */
     readonly ASTM_RECORD_NO_HEADER: "ASTM_RECORD_NO_HEADER";
-    /** The `H` record is too short to declare the four delimiters (field/repeat/component/escape). */
+    /**
+     * The first `H` record could not declare all four delimiters (field/repeat/component/escape).
+     * One code, four reasons, and the message says which: the record is not a header, it is shorter
+     * than a header plus a three-character definition, its definition field holds fewer than three
+     * characters before the next field separator, or its field separator is also one of the other
+     * three. Only the second of those is "too short", so read the message rather than assuming it.
+     *
+     * **Two of the four cannot be reached on this fatal, and are not dead code.** A first record that
+     * is not an `H` raises `ASTM_RECORD_NO_HEADER` before the declaration is ever read, and a field
+     * separator reused among the other three ends the delimiter definition where it appears, so the
+     * truncation reason answers first. The reader names all four because it is also called directly
+     * and on later headers, where the same conditions are a warning rather than this fatal.
+     */
     readonly ASTM_RECORD_UNDECLARED_DELIMITERS: "ASTM_RECORD_UNDECLARED_DELIMITERS";
 };
 /**
@@ -3043,14 +3439,53 @@ declare class AstmParseError extends Error {
  * next escape character with no bound, which meant a single unescaped `&` in a
  * value merged every field after it into that value, in silence.
  *
- * **The atom rule is unchanged and still costs a boundary in one case.** A triple
- * is opaque by design, so where its body is itself a delimiter (`&|&` under the
- * canonical set) that delimiter does not split. That is deliberate: it is what
- * keeps `&F&` one token under a declared set that names `F` as a delimiter. Where
- * the body is not a recognized mnemonic the parse layer reports it as
- * `ASTM_UNKNOWN_ESCAPE_SEQUENCE`, so it is never silent, but that code is
- * tolerable and a field boundary has still gone. Do not "fix" that by narrowing
- * the atom: the narrowing would break the guarantee the atom exists for.
+ * **The atom rule is unchanged and still costs a boundary in one case, which now
+ * has a report of its own.** A triple is opaque by design, so where its body is
+ * itself a delimiter (`&|&` under the canonical set) that delimiter does not
+ * split. That is deliberate: it is what keeps `&F&` one token under a declared
+ * set that names `F` as a delimiter. Where the body is not a recognized mnemonic
+ * the parse layer reports it as `ASTM_UNKNOWN_ESCAPE_SEQUENCE`, and where that
+ * unrecognized body is *also* one of the three splitting roles in force it
+ * reports `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` **as well**, which is the
+ * code that says a boundary went missing rather than merely that a body was not
+ * recognized. Do not "fix" this by narrowing the atom: the narrowing would break
+ * the guarantee the atom exists for. The split is unchanged; what changed is that
+ * the loss is now reported by a code no profile may tolerate.
+ *
+ * **The match is greedy and leftmost, and that costs a boundary in the opposite
+ * direction, which also has a report of its own.** Triples are taken left to
+ * right, so the escape character that *closes* one triple cannot also *open* the
+ * next. Where it could have (the character after a triple is a splitting
+ * delimiter and the one after that is the escape character), the bytes carry two
+ * alignments that disagree about that delimiter: under the reading taken it ends
+ * a field, repeat or component, and under the other it sits inside an opaque
+ * atom and ends nothing. Where the earlier triple's body was **not** a
+ * recognized mnemonic, the reading taken rests on a triple this codec cannot
+ * interpret at all, so nothing in its own vocabulary prefers that reading to the
+ * competing one, and the parse layer reports
+ * `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`. The split is unchanged
+ * here too: the leftmost reading is kept, and what is new is that a boundary
+ * which may not be the sender's is no longer reported only by codes a profile
+ * may tolerate. Where that earlier body **was** a recognized mnemonic nothing is
+ * reported, and the reason is narrower than it looks, so read
+ * {@link AmbiguousAlignmentSink} before widening it.
+ *
+ * **A second question is asked at the same position, and it is a different one,
+ * which is why it is a second code and not a widening of the first.** That report
+ * asks whether this codec's vocabulary prefers the reading taken *at* the contested
+ * position. It says nothing about what the reading taken makes of the bytes *after*
+ * the boundary, and that is where the two alignments really diverge: they resume
+ * one character apart, so they disagree about the whole tail. Where the escape
+ * character the reading taken resumes on heads no sequence at all, the boundary was
+ * bought with a byte this reading cannot read, while the competing alignment is
+ * precisely the reading that can. On the **field** separator that gained boundary
+ * shifts every later field one place, so a result record's units and **result
+ * status** are read out of slots the competing alignment does not put them in, and
+ * a status of `final` can be a consequence of the alignment rather than something
+ * the sender wrote there. That is `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`; see
+ * {@link ShiftedFieldsSink}, including the tail and the two other delimiter roles it
+ * deliberately stays silent on, and why neither silence is a claim that nothing was
+ * lost there.
  *
  * Re-escaping (the inverse, for spec-clean emit) lives in the serializer and is
  * deliberately not implemented here.
@@ -3070,6 +3505,130 @@ type UnknownEscapeSink = () => void;
  * `ASTM_UNPAIRED_ESCAPE_CHARACTER` warning. Optional so the codec can be used purely.
  */
 type UnpairedEscapeSink = () => void;
+/**
+ * A callback the codec calls when an **unrecognized** escape body is itself one of
+ * the three splitting delimiters in force (field, repeat, component), so the atom
+ * rule kept that character out of the split and a boundary the sender's bytes
+ * carried never became one. The value is preserved verbatim either way; the
+ * callback lets the parser surface a value-free
+ * `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` warning. Optional so the codec can
+ * be used purely.
+ *
+ * The **escape** character is deliberately not in that test: it is not a splitting
+ * role, so `&&&` under the canonical set loses no boundary. A body that is a
+ * *recognized* mnemonic is not in it either, whatever character it is: `&F&` under
+ * a set naming `F` as the repeat delimiter is the escaped field delimiter the
+ * sender wrote, and reading it as a swallowed repeat boundary would report the
+ * escape mechanism working as a defect.
+ */
+type SwallowedDelimiterSink = () => void;
+/**
+ * A callback the split calls when the escape character that **closed** an
+ * unrecognized escape sequence could instead have **opened** one whose body is the
+ * delimiter being split on, so the two alignments of the same bytes disagree about
+ * whether that delimiter ends a field, repeat or component. The leftmost reading is
+ * kept and nothing is re-split; the callback lets the parser surface a value-free
+ * `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT` warning. Optional so the split can be
+ * used purely.
+ *
+ * Two exclusions, both deliberate. The first is what keeps this off conformant
+ * streams, and it is **wider than the case it is justified on**, so the residue is
+ * named here rather than left to be found:
+ *
+ * - **The earlier sequence's body must not be a recognized mnemonic.** The test is
+ *   which alignment this codec's own vocabulary supports, not which one is tidier.
+ *   Where the earlier body is unrecognized the reading taken rests on a triple the
+ *   codec cannot interpret, while the competitor's body is the delimiter character,
+ *   which it usually cannot interpret either: nothing prefers one, and that is what
+ *   this reports. Where the earlier body is a recognized mnemonic the reading taken
+ *   interprets a construct (`&F&` is the sender escaping a field separator, which is
+ *   what the mechanism is for) and the competitor **usually** interprets none, so the
+ *   vocabulary usually prefers one, and reporting it would report the escape
+ *   mechanism working. Usually, not always: see the second residue below.
+ *   **What that argument does not cover, measured.** It does not follow that the
+ *   reading taken is *conformant*: under `28.6&F&|&U/L` it is `&F&`, a real
+ *   separator, and then a bare escape character, which this package reports as a
+ *   deviation of its own. And where the declared set names a mnemonic letter as a
+ *   splitting delimiter, both alignments interpret exactly one construct and
+ *   neither is preferred, yet the exclusion still silences it. Both residues are
+ *   recorded with their measurements rather than closed by widening this test: the
+ *   criterion that would cover them is a different one (counting what each
+ *   alignment interprets), and swapping criteria moves which streams a published
+ *   package refuses.
+ * - **The following character must be the delimiter this split is taken on.** The
+ *   split runs once per role, so a character that is a delimiter in a *later* role
+ *   is reported by that role's pass, on the segment it survives into, and never
+ *   twice. A delimiter with no escape character two positions past it is excluded by
+ *   the rule that defines the condition rather than by a judgement: the sequence the
+ *   competing alignment would need never closes, so there is no competitor.
+ *
+ * @param segmentIndex - The 0-based index of the segment being accumulated when the
+ *   ambiguity was seen, so a caller splitting a record into fields can report which
+ *   field it sat in. A caller splitting one field into repeats or components
+ *   already knows the field index and ignores this.
+ */
+type AmbiguousAlignmentSink = (segmentIndex: number) => void;
+/**
+ * A callback the split calls when a competing escape alignment decided a boundary
+ * **and the reading taken cannot read the byte immediately past it**: the escape
+ * character the leftmost reading resumes on heads no escape sequence at all, so it
+ * is kept as a bare literal (reported separately as
+ * `ASTM_UNPAIRED_ESCAPE_CHARACTER`), while the competing alignment is exactly the
+ * reading that gives that character a job, as the close of its own triple.
+ *
+ * Wired **only to the split taken on the field separator**, because that is the
+ * whole of its claim: a gained *field* boundary shifts every later field one place,
+ * so a record's modeled slots after it are decided by the alignment rather than by
+ * the sender's own positions. On a result record that is the units slot and the
+ * **result status** slot: the sender's trailing letter lands in field 9 under the
+ * reading taken and in no field at all under the competing one, so a status of
+ * `final` can be a consequence of the alignment rather than something the sender
+ * put there. A gained *repeat* or *component* boundary divides one field and
+ * reaches nothing outside it, so it moves no **field-indexed** slot and is
+ * deliberately outside this. **That bound is a choice, not a consequence, and the
+ * difference matters**: components are modeled *inside* a field (a Universal Test
+ * ID's coding scheme and local code, a patient name's parts), so a gained component
+ * boundary does move a modeled slot. That is measured, unreported by anything, and
+ * open, not something this sink covers. The callback lets the parser surface a
+ * value-free `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS` warning. Optional so the split
+ * can be used purely.
+ *
+ * **It is a report, not a repair.** The split is unchanged, every decoded byte is
+ * identical, and the status read is the status that was always read. What is new is
+ * that the shift is reported by a code no profile may tolerate, where before it was
+ * covered only by tolerable ones.
+ *
+ * **This is independent of {@link AmbiguousAlignmentSink}, and fires alongside it
+ * rather than instead of it.** That one asks whether the codec's vocabulary prefers
+ * the reading taken *at* the contested position and is silent where the earlier
+ * body is a recognized mnemonic; this one asks what the reading taken makes of the
+ * bytes *after* the boundary and does not consult the earlier body at all. The two
+ * questions are different, so neither test is widened to answer the other.
+ *
+ * **The tail is weighed one construct deep, and that bound is stated rather than
+ * left to be found.** Two tails are excluded, with the same reason: the bytes past
+ * the boundary prefer the reading taken.
+ *
+ * - **The escape character heads a sequence this codec recognizes.** Then the
+ *   reading taken interprets it and leaves nothing bare, while the competing
+ *   alignment would leave it bare. Under a set naming the field separator `F`,
+ *   `28.6&F&F&F&U/L` is the sender escaping that separator, writing it, and
+ *   escaping it again: entirely well formed, and refusing it is the over-refusal
+ *   that sank the preceding candidate criterion for this family.
+ * - **The escape character heads a sequence whose body this codec does not
+ *   recognize.** Then the reading taken still consumes it as a sequence and carries
+ *   one unreadable body, while the competing alignment would leave *two* escape
+ *   characters bare. The preference is stronger there, not weaker.
+ *
+ * What that bound leaves open is the second of those tails, where the field shift
+ * is real and this stays silent. It is measured and named rather than closed by
+ * widening the test, because widening it would report a boundary the bytes prefer.
+ *
+ * @param segmentIndex - The 0-based index of the field being accumulated when the
+ *   shifting boundary was taken. Every field after it is one place further right
+ *   than the competing alignment puts it.
+ */
+type ShiftedFieldsSink = (segmentIndex: number) => void;
 /**
  * Decode the four recognized ASTM escape mnemonics in a single already-split
  * leaf (a component string), substituting the *active* delimiters read from the
@@ -3084,6 +3643,8 @@ type UnpairedEscapeSink = () => void;
  * @param d - The delimiters resolved from the header.
  * @param onUnknown - Called once per unrecognized escape body encountered.
  * @param onUnpaired - Called once per escape character that heads no sequence.
+ * @param onSwallowedDelimiter - Called once per unrecognized escape body that is
+ *   itself a splitting delimiter in force, so that delimiter never split.
  * @returns The decoded string.
  * @example
  * ```ts
@@ -3092,7 +3653,7 @@ type UnpairedEscapeSink = () => void;
  * decodeEscapes("O&Brien", CANONICAL_DELIMITERS); // "O&Brien" (literal, reported)
  * ```
  */
-declare function decodeEscapes(leaf: string, d: Delimiters, onUnknown?: UnknownEscapeSink, onUnpaired?: UnpairedEscapeSink): string;
+declare function decodeEscapes(leaf: string, d: Delimiters, onUnknown?: UnknownEscapeSink, onUnpaired?: UnpairedEscapeSink, onSwallowedDelimiter?: SwallowedDelimiterSink): string;
 /**
  * Split `text` on `delimiter`, treating an escape sequence (escape, one body
  * character, escape) as an opaque atom so a delimiter that appears *inside* an
@@ -3110,11 +3671,33 @@ declare function decodeEscapes(leaf: string, d: Delimiters, onUnknown?: UnknownE
  * closes is what used to merge the whole remainder of a record into one field.
  * Decoding the resulting leaf is what reports it, so this function stays a pure
  * split. Note the two rules together: a delimiter after such a character does
- * split, and a delimiter sitting inside a real three-character atom does not.
+ * split, and a delimiter sitting inside a real three-character atom does not. The
+ * second of those is reported, from the decode step rather than from here,
+ * whenever the atom's body was not a recognized mnemonic.
+ *
+ * **Atoms are matched greedily, leftmost first, and where that choice decides a
+ * boundary it is reported from here.** The escape character closing one triple
+ * cannot also open the next, so `28.6&Z&|&U/L` is read as the atom `&Z&`, then a
+ * field separator that splits, and not as `&Z`, then the atom `&|&` whose field
+ * separator would not have split. Both alignments are in the bytes and they
+ * disagree by one boundary. The reading is **not** changed (that would only pick
+ * the other alignment, with no more evidence for it); it is reported through
+ * `onAmbiguousAlignment`, and only where the earlier body was unrecognized, since
+ * a recognized mnemonic is a construct this codec can interpret and the
+ * competitor's body usually is not. That exclusion is wider than that argument:
+ * see {@link AmbiguousAlignmentSink}.
  *
  * @param text - The field or repeat string to split.
  * @param delimiter - The delimiter to split on.
  * @param escape - The active escape character.
+ * @param onAmbiguousAlignment - Called once per unrecognized escape sequence whose
+ *   closing escape character could instead have opened a sequence holding this
+ *   delimiter, so the boundary taken here is not the only reading of the bytes.
+ * @param onShiftedFields - Called once per contested boundary where the escape
+ *   character this reading resumes on heads no sequence of its own, so the boundary
+ *   was bought with a byte the reading cannot read. Wired only by the split taken on
+ *   the field separator: see {@link ShiftedFieldsSink} for why, and for the tail it
+ *   deliberately does not report.
  * @returns The raw segments, in order.
  * @example
  * ```ts
@@ -3124,7 +3707,7 @@ declare function decodeEscapes(leaf: string, d: Delimiters, onUnknown?: UnknownE
  * splitEscapeAware("O&Brien^John", "^", "&"); // ["O&Brien", "John"]  (unpaired: literal)
  * ```
  */
-declare function splitEscapeAware(text: string, delimiter: string, escape: string): string[];
+declare function splitEscapeAware(text: string, delimiter: string, escape: string, onAmbiguousAlignment?: AmbiguousAlignmentSink, onShiftedFields?: ShiftedFieldsSink): string[];
 
 /**
  * Deep-freeze helper for the immutable ASTM model.
@@ -3457,9 +4040,60 @@ declare function resolveProfileTransport(profile: AstmProfile | undefined): Astm
  * field separator was absent outright, so it is a reader of record structure that
  * cannot be relied on as a sweep.
  *
+ * **A fourth and a fifth reader of record structure landed together, and the
+ * allow-list was re-derived against them.** `ASTM_RECORD_DELIMITER_ROLE_COLLISION`
+ * reports a header declaring one character in two of the repeat / component /
+ * escape roles, so the boundary between those two roles is not in the bytes;
+ * `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` reports an unrecognized escape body
+ * that is itself a splitting delimiter, so the atom rule kept it out of the split.
+ * Both are safety-critical by construction, because that side is computed rather
+ * than listed. What they required was re-reading the survivors below against them,
+ * and two of the four needed their arguments rewritten rather than merely
+ * re-checked: each was, on its own, the *only* warning a stream exhibiting one of
+ * these conditions raised. That is the state this file exists to prevent, and it is
+ * why the remedy in both cases was a **second, narrower, non-tolerable code**
+ * rather than striking the tolerable one off. Striking it off would have changed
+ * behavior for every profile naming it while still leaving the two conditions
+ * reported by codes that also fire on cases costing nothing.
+ *
+ * **A sixth reader landed with `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT`, and it is
+ * the mirror of the fifth.** That code reports that the escape character closing an
+ * unrecognized sequence could instead have opened one holding the delimiter that
+ * split, so the bytes carry two alignments disagreeing by one boundary and the
+ * leftmost was taken. It is safety-critical by construction, and the direction is
+ * why it could not be left to the codes below: the fifth reports a boundary the
+ * reading **lost**, this one a boundary the reading may have **gained**, and a
+ * gained boundary hands back a value the sender's bytes do not unambiguously carry.
+ * Both of the codes that condition previously raised are on the list below, so a
+ * profile naming them left `{ strict: true }` accepting it. Re-reading the survivors
+ * against it changed no admission and rewrote no argument: none of the four is a
+ * statement about where a boundary was taken, and the new code is not tolerable, so
+ * the same "a profile re-badges the code it names and no other" reason already
+ * written under the two escape entries covers it.
+ *
+ * **A further reader landed with `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS`, and it is
+ * the first one that reaches a MODELED SLOT rather than a boundary.** It reports
+ * that a contested alignment decided a **field** boundary while the reading taken
+ * resumes on an escape character heading no sequence, so every later field sits one
+ * place further right than the competing alignment puts it. On a result record that
+ * moves the units and the **result status**: the sender's trailing letter is read out
+ * of field 9 under the reading taken and out of no field at all under the other, so a
+ * status of `final` can be a consequence of the alignment rather than something the
+ * sender wrote there. Until it existed the only warning on that stream was the
+ * **tolerable** `ASTM_UNPAIRED_ESCAPE_CHARACTER`, so the widest gate-legal profile
+ * plus `{ strict: true }` accepted a fabricated `final` on a lab result. It is
+ * safety-critical by construction and must never be admitted. Re-reading the
+ * survivors against it moved no admission, and the reason is worth stating because it
+ * is not last time's: `ASTM_UNPAIRED_ESCAPE_CHARACTER` stays on the list because it
+ * remains true and benign of every case that costs nothing (a bare escape character
+ * in a value alters no boundary at all), and the case where it accompanies a shifted
+ * field is now reported by a code no profile may re-badge.
+ *
  * **So the ones that remain are recorded with the reading each one survives**, not
- * merely with the value it preserves. Each was re-derived against both readers of
- * record structure above, plus the single-message / single-patient guards:
+ * merely with the value it preserves. Each was re-derived against **every** reader of
+ * record structure named above (this sentence deliberately names no count: it has
+ * been corrected upward at every slice that landed one), plus the single-message /
+ * single-patient guards:
  *
  * - `ASTM_NONSTANDARD_DELIMITERS`: the header's own declared delimiters are read
  *   and honored either way, and this notes only that they differ from the canonical
@@ -3471,29 +4105,70 @@ declare function resolveProfileTransport(profile: AstmProfile | undefined): Astm
  *   force. A stream may be wholly non-canonical and split perfectly, and a wholly
  *   canonical stream can still carry a record that does not split, so tolerating the
  *   first can never quiet the second.
+ *
+ *   **Its admission was resting on a set of declarations it does not distinguish,
+ *   and no longer is.** A declaration naming one character in two roles is
+ *   necessarily non-canonical, so this code fired on it, and until
+ *   `ASTM_RECORD_DELIMITER_ROLE_COLLISION` existed it was the *only* warning such a
+ *   stream raised: tolerating "the declared set is unusual" therefore quieted
+ *   "the declared set cannot express the boundary it was read with". That second
+ *   condition now has its own code, which is not tolerable, so what is left here is
+ *   the honest statement it always meant to be: the set differs from the canonical
+ *   one and was honored. The reason tolerating this one cannot quiet that one is the
+ *   profile mechanism and nothing subtler: a profile re-badges the code it names and
+ *   no other. It is **not** that the two conditions are independent. They are not:
+ *   every colliding set is non-canonical, which is exactly why this bullet needed
+ *   rewriting.
  * - `ASTM_UNKNOWN_ESCAPE_SEQUENCE`: an unrecognized escape body is **preserved
  *   byte-for-byte** in the decoded value (the escape codec does not guess at one),
- *   so the value is identical with or without the profile. No reader sees it
- *   either: a decoded field value is never cut back into records, the type
- *   letter is read before decoding, and the split reader counts fields, which the
- *   escape-aware tokenizer has already finished dividing before any body is decoded.
- *
- *   **This entry is on the list and is recorded as questionable, deliberately.**
- *   The argument above is about the *decoded value*, and it holds. What it does not
- *   cover is that the escape-aware split itself treats an `&X&` triple as opaque, so
- *   where `X` is a delimiter that delimiter never became a boundary: the split the
- *   argument says has "already finished dividing" divided one time too few, and this
- *   code is the only report of it. Measured on the canonical set:
+ *   so the value is identical with or without the profile. A decoded field value is
+ *   never cut back into records, the type letter is read before decoding, and the
+ *   split reader counts fields the escape-aware tokenizer has already finished
+ *   dividing, so none of those three sees it.
+ *
+ *   **Part 2 acquired a reader here, and it is named rather than left to be found.**
+ *   `isSplittingDelimiter` in `../common/escapes.ts` runs **only** on the
+ *   unrecognized-body condition this code reports, and decides out of it whether to
+ *   raise `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE`. That is a reader of the
+ *   reported condition, which is exactly what part 2 asks about, so this entry no
+ *   longer survives on "nothing reads it". It survives on a narrower and checkable
+ *   claim: a profile tolerating a code re-badges **that code and no other**, so
+ *   tolerating this one cannot quiet what the reader raises, and what it raises is
+ *   not tolerable in any case. If a future reader of this same condition ever
+ *   produces something a profile **can** tolerate, this entry stops being admissible
+ *   and comes off the list.
+ *
+ *   **A second reader of the same condition landed, and it is named here for the
+ *   same reason.** The mnemonic test in `../common/escapes.ts` is now asked twice:
+ *   once by the decoder, to decide whether a body is recognized, and once by the
+ *   escape-aware split, which raises `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT` only
+ *   where an **unrecognized** body sits in a sequence a competing alignment would
+ *   have aligned differently. That is the condition this code reports, read a second
+ *   time, and this entry survives it on the same narrower claim: what that reader
+ *   raises is a different code, which a profile cannot name and cannot tolerate.
+ *
+ *   **This entry used to be recorded as questionable, and what made it questionable
+ *   is now a separate code that is not on this list.** The argument above is about
+ *   the *decoded value*, and it holds. What it did not cover is that the
+ *   escape-aware split itself treats an `&X&` triple as opaque, so where `X` is a
+ *   delimiter that delimiter never became a boundary: the split the argument says
+ *   has "already finished dividing" divided one time too few, and this code was the
+ *   only report of it. Measured on the canonical set:
  *   `R|1|^^^687|28.6&|&U/L||||F` yields a value of `28.6&|&U/L`, no units, and status
- *   `unspecified` rather than `final`, with this as the sole warning, so a profile
- *   tolerating it (the shipped `referenceCorpus` does) lets `{ strict: true }` accept
- *   it. That fails part 1 of the two-clause test on the reading, not on the value.
- *   It is **left on the list on purpose**: removing it would change behavior for
- *   every profile naming it, and what should report a swallowed boundary instead, and
- *   at what severity, is a question this file cannot settle on its own. Do not read
- *   this bullet as an endorsement; read it as the open question it is, and do not
- *   close it by narrowing the atom, which is what keeps `&F&` one token under a
- *   delimiter set that names `F` as a delimiter.
+ *   `unspecified` rather than `final`, and this was the sole warning, so a profile
+ *   tolerating it (the shipped `referenceCorpus` does) let `{ strict: true }` accept
+ *   it. That failed part 1 of the two-clause test on the reading, not on the value.
+ *   `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` now fires **alongside** this code on
+ *   exactly that subset and is safety-critical, so the lost boundary is reported by
+ *   something no profile may tolerate and that same stream is refused under
+ *   `{ strict: true }`. This code was **not** removed, for two reasons: removing it
+ *   changes behavior for every profile naming it, and it remains true and benign of
+ *   every unrecognized body that is not a delimiter in force, where the sequence is
+ *   preserved byte-for-byte and no boundary is lost. What is scoped away here is a
+ *   claim, not a guard. Do not close the underlying condition by narrowing the atom,
+ *   which is what keeps `&F&` one token under a delimiter set that names `F` as a
+ *   delimiter, and do not read the new code as a repair: the value is byte-identical
+ *   to what it was, and only the reporting changed.
  * - `ASTM_UNPAIRED_ESCAPE_CHARACTER`: an escape character heading no escape
  *   sequence, read as the **literal character it is** and kept byte-for-byte in the
  *   decoded value, so the value is identical with or without the profile. Note what
@@ -3506,6 +4181,14 @@ declare function resolveProfileTransport(profile: AstmProfile | undefined): Astm
  *   replaced, which **would** have failed part 1: reading the same character as an
  *   unterminated sequence merged every field after it into one, and a code reporting
  *   that would have been a report of lost values.
+ *
+ *   **The alignment reader is not a reader of this condition, and the distinction is
+ *   worth stating rather than leaving to be checked.** It asks whether the character
+ *   two positions past a sequence *is* the escape character, never whether that
+ *   character heads a sequence of its own, which is the question this code answers.
+ *   The two are independent in both directions, measured: `28.6&Z&|&U/L` raises this
+ *   code and the alignment code together, and `28.6&Z&|&U&L` raises the alignment
+ *   code with no unpaired character anywhere in it.
  * - `ASTM_RECORD_UNINTERPRETED_QUERY_STATUS`: a request-information status carried
  *   verbatim as a leaf field on a `Q` record; the code set is paywalled and is not
  *   interpreted, profile or not. Classification reads whether a `Q` record is
@@ -3517,8 +4200,11 @@ declare function resolveProfileTransport(profile: AstmProfile | undefined): Astm
  * undefined abnormal flag or result status, an unparseable reference range, absent
  * units, a mis-attached comment, a partial timestamp, a query-vs-result ambiguity,
  * an unrecognized record type, a record the delimiters in force could not split, a
- * bad frame checksum / sequence gap / unterminated / oversize frame, an ambiguous
- * transport, an unexpected protocol event, or a rejected frame: is forbidden.
+ * declaration naming one character in two roles, a delimiter an unrecognized escape
+ * sequence kept out of the split, a boundary a competing escape alignment disagrees
+ * about, a bad frame checksum / sequence gap / unterminated
+ * / oversize frame, an ambiguous transport, an unexpected protocol event, or a
+ * rejected frame: is forbidden.
  *
  * **What this file cannot do for you.** Part 2 is a review obligation, not a
  * mechanical one. There is no honest automatic check for "nothing load-bearing
@@ -3549,6 +4235,20 @@ declare function resolveProfileTransport(profile: AstmProfile | undefined): Astm
  * reports a record the delimiters in force could not split, so every modeled field
  * of that record is missing: it fails the first half of the test outright.
  *
+ * `ASTM_RECORD_DELIMITER_ROLE_COLLISION`,
+ * `ASTM_RECORD_DELIMITER_SWALLOWED_BY_ESCAPE` and
+ * `ASTM_RECORD_AMBIGUOUS_ESCAPE_ALIGNMENT` are not on this list and must not be
+ * added to it. Each reports a boundary the reading cannot defend from the bytes (the
+ * first two a boundary that is not in the reading, the third one that may not be in
+ * the bytes), and each exists precisely because the only warnings its condition
+ * previously raised were among the four below.
+ *
+ * `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS` is not on this list and must not be added
+ * to it either, and it is the strongest case of the four: it reports not merely a
+ * boundary but a modeled slot changing hands, up to and including a result status
+ * reading `final` that the competing alignment of the same bytes puts in no field at
+ * all.
+ *
  * @example
  * ```ts
  * import { TOLERABLE_CODES } from "@cosyte/astm";
@@ -3653,7 +4353,10 @@ declare const defaultProfile: AstmProfile;
  * only re-badges the *warning*: no value, flag, status, or identifier is altered
  * or dropped. And by the safety gate in `defineAstmProfile`, it **cannot** tolerate
  * a result value / flag / status / range / units, a patient or comment context, a
- * message-kind ambiguity, an unrecognized record type, or any frame / LTP integrity
+ * message-kind ambiguity, an unrecognized record type, a declaration naming one
+ * character in two delimiter roles, a delimiter an unrecognized
+ * escape sequence kept out of the split, a field boundary a competing escape
+ * alignment disagrees about, or any frame / LTP integrity
  * warning: those always surface, profile or not. The unrecognized-record-type case
  * matters because message grouping reads a record's type letter, so a letter the
  * reader does not recognize may be a header, and a header read as something else
@@ -4890,4 +5593,4 @@ declare class AstmFrameStrictError extends Error {
  */
 declare const VERSION: string;
 
-export { ALL_ASTM_WARNING_CODES, AMBIGUOUS_CODES, ACK as ASTM_ACK, ENQ as ASTM_ENQ, EOT as ASTM_EOT, NAK as ASTM_NAK, type AbnormalFlag, type AbnormalFlagCode, type AbnormalFlagMeaning, type AmbiguousCode, type AnyAstmWarningCode, AstmAmbiguousStreamError, type AstmDate, type AstmDatePrecision, type AstmField, type AstmFrame, AstmFrameEncodeError, type AstmFrameEncodeErrorCode, type AstmFramePosition, AstmFrameStrictError, type AstmFrameWarning, type AstmFraming, type AstmLivdWarning, type AstmLtpWarning, type AstmMessage, type AstmMessageClassification, type AstmMessageKind, AstmParseError, type AstmParseOptions, type AstmPosition, type AstmProfile, AstmProfileDefinitionError, type AstmProfileProvenance, type AstmQuirkMatch, type AstmQuirkTolerance, type AstmRecord, type AstmRecordInput, type AstmRecordWarning, AstmSerializeError, type AstmSerializeErrorCode, type AstmStreamMessage, AstmStrictError, CANONICAL_DELIMITERS, type CommentInput, type CommentRecord, type ComposeFramesOptions, type DecodeAstmFramesResult, type DefineAstmProfileOptions, type Delimiters, type DetectFramingOptions, type DetectFramingResult, FATAL_CODES, FRAME_WARNING_CODES, type FatalCode, type FrameChecksum, type FrameOptions, type FrameTerminator, type FrameWarningCode, type FramedAstmResult, type HeaderInput, type HeaderRecord, LIVD_WARNING_CODES, LTP_WARNING_CODES, type LivdAnnotation, type LivdCatalog, type LivdEntry, type LivdLookup, type LivdMapping, type LivdResult, type LivdWarningCode, type LtpAction, type LtpEvent, type LtpPhase, type LtpState, type LtpTransition, type LtpWarningCode, type ManufacturerRecord, type MessageInput, type OrderInput, type OrderRecord, type PatientInput, type PatientName, type PatientNameInput, type PatientRecord, type QueryInput, type QueryRecord, type ReferenceRange, type ReferenceRangeKind, type ResultInput, type ResultRecord, type ResultStatus, type ResultStatusCode, type ResultStatusMeaning, SAFETY_CRITICAL_CODES, type ScientificRecord, TOLERABLE_CODES, type TerminatorRecord, type UniversalTestId, type UniversalTestIdProvenance, type UnknownEscapeSink, type UnpairedEscapeSink, type UnsupportedRecord, VERSION, type VerbatimInput, WARNING_CODES, type WarningCode, ambiguousMessageKind, ambiguousValueSplit, applyAstmProfile, applyAstmProfileToWarnings, applyLivd, astmDateToLocalISO, astmProfiles, attachComments, buildAstmMessage, classifyMessage, comments, commentsFor, composeAstmFrames, computeChecksum, decodeAstmFrames, decodeEscapes, deepFreeze, defineAstmProfile, defineLivdCatalog, delimitersRedeclared, detectFraming, encodeComponent, fieldScalar, fieldsUnseparated, frameBadChecksum, frameOversize, frameSequenceGap, frameUnterminated, getAstmProfile, getDefaultAstmProfile, interpretAbnormalFlag, interpretResultStatus, isNonStandard, isSafetyCriticalCode, listAstmProfiles, livdAmbiguousMapping, livdUnmappedCode, lookupLivdForRecord, ltpAmbiguousTransport, ltpFrameRejected, ltpInitialState, ltpReduce, ltpUnexpectedEvent, messages, nonStandardDelimiters, orders, orphanComment, parseAstmDate, parseAstmRecords, parseChecksumHex, parseFramedAstm, parseReferenceRange, partialTimestamp, patient, primaryCode, profileQuirkApplied, query, readDelimiters, recognizeUniversalTestId, resolveProfileTransport, results, serializeAstmRecord, serializeAstmRecords, serializeField, serializeFramedAstm, setDefaultAstmProfile, splitEscapeAware, toChecksumHex, tokenizeHeader, tokenizeRecord, undefinedAbnormalFlag, undefinedResultStatus, uninterpretedQueryStatus, unitsAbsent, unknownEscapeSequence, unknownRecordType, unpairedEscapeCharacter, unparseableReferenceRange, unreadableRedeclaration };
+export { ALL_ASTM_WARNING_CODES, AMBIGUOUS_CODES, ACK as ASTM_ACK, ENQ as ASTM_ENQ, EOT as ASTM_EOT, NAK as ASTM_NAK, type AbnormalFlag, type AbnormalFlagCode, type AbnormalFlagMeaning, type AmbiguousAlignmentSink, type AmbiguousCode, type AnyAstmWarningCode, AstmAmbiguousStreamError, type AstmDate, type AstmDatePrecision, type AstmField, type AstmFrame, AstmFrameEncodeError, type AstmFrameEncodeErrorCode, type AstmFramePosition, AstmFrameStrictError, type AstmFrameWarning, type AstmFraming, type AstmLivdWarning, type AstmLtpWarning, type AstmMessage, type AstmMessageClassification, type AstmMessageKind, AstmParseError, type AstmParseOptions, type AstmPosition, type AstmProfile, AstmProfileDefinitionError, type AstmProfileProvenance, type AstmQuirkMatch, type AstmQuirkTolerance, type AstmRecord, type AstmRecordInput, type AstmRecordWarning, AstmSerializeError, type AstmSerializeErrorCode, type AstmStreamMessage, AstmStrictError, CANONICAL_DELIMITERS, type CommentInput, type CommentRecord, type ComposeFramesOptions, type DecodeAstmFramesResult, type DefineAstmProfileOptions, type DelimiterDeclarationFault, type DelimiterReadResult, type Delimiters, type DetectFramingOptions, type DetectFramingResult, FATAL_CODES, FRAME_WARNING_CODES, type FatalCode, type FrameChecksum, type FrameOptions, type FrameTerminator, type FrameWarningCode, type FramedAstmResult, type HeaderInput, type HeaderRecord, LIVD_WARNING_CODES, LTP_WARNING_CODES, type LivdAnnotation, type LivdCatalog, type LivdEntry, type LivdLookup, type LivdMapping, type LivdResult, type LivdWarningCode, type LtpAction, type LtpEvent, type LtpPhase, type LtpState, type LtpTransition, type LtpWarningCode, type ManufacturerRecord, type MessageInput, type OrderInput, type OrderRecord, type PatientInput, type PatientName, type PatientNameInput, type PatientRecord, type QueryInput, type QueryRecord, type ReferenceRange, type ReferenceRangeKind, type ResultInput, type ResultRecord, type ResultStatus, type ResultStatusCode, type ResultStatusMeaning, SAFETY_CRITICAL_CODES, type ScientificRecord, type ShiftedFieldsSink, type SwallowedDelimiterSink, TOLERABLE_CODES, type TerminatorRecord, type UniversalTestId, type UniversalTestIdProvenance, type UnknownEscapeSink, type UnpairedEscapeSink, type UnsupportedRecord, VERSION, type VerbatimInput, WARNING_CODES, type WarningCode, alignmentShiftedFields, ambiguousEscapeAlignment, ambiguousMessageKind, ambiguousValueSplit, applyAstmProfile, applyAstmProfileToWarnings, applyLivd, astmDateToLocalISO, astmProfiles, attachComments, buildAstmMessage, classifyMessage, comments, commentsFor, composeAstmFrames, computeChecksum, decodeAstmFrames, decodeEscapes, deepFreeze, defineAstmProfile, defineLivdCatalog, delimiterRoleCollision, delimiterSwallowedByEscape, delimitersRedeclared, detectFraming, encodeComponent, fieldScalar, fieldsUnseparated, frameBadChecksum, frameOversize, frameSequenceGap, frameUnterminated, getAstmProfile, getDefaultAstmProfile, hasCollidingRoles, interpretAbnormalFlag, interpretResultStatus, isNonStandard, isSafetyCriticalCode, listAstmProfiles, livdAmbiguousMapping, livdUnmappedCode, lookupLivdForRecord, ltpAmbiguousTransport, ltpFrameRejected, ltpInitialState, ltpReduce, ltpUnexpectedEvent, messages, nonStandardDelimiters, orders, orphanComment, parseAstmDate, parseAstmRecords, parseChecksumHex, parseFramedAstm, parseReferenceRange, partialTimestamp, patient, primaryCode, profileQuirkApplied, query, readDelimiterDeclaration, readDelimiters, recognizeUniversalTestId, resolveProfileTransport, results, serializeAstmRecord, serializeAstmRecords, serializeField, serializeFramedAstm, setDefaultAstmProfile, splitEscapeAware, toChecksumHex, tokenizeHeader, tokenizeRecord, undefinedAbnormalFlag, undefinedResultStatus, uninterpretedQueryStatus, unitsAbsent, unknownEscapeSequence, unknownRecordType, unpairedEscapeCharacter, unparseableReferenceRange, unreadableRedeclaration };