@cosyte/astm 0.0.15 → 0.0.18

package/dist/index.d.ts

@@ -74,18 +74,237 @@ 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";
+    /**
+     * 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.
+     */
+    readonly ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD: "ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD";
     /** 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 +326,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 +393,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 +504,106 @@ 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_ALIGNMENT_TRUNCATED_FIELD` warning. Emitted when a competing escape
+ * alignment decided a **repeat** boundary and the escape character the reading taken resumes on
+ * heads no sequence of its own, so the field is read as more repeats than the competing alignment
+ * gives it. No field-indexed slot moves, and that is the difference from
+ * {@link alignmentShiftedFields}. Where the gained boundary is the **first** in the field it still
+ * reaches a modeled slot, because a field's modeled value and components are taken from its first
+ * repeat alone: everything past the boundary stays in `repeats` and leaves every modeled slot, so a
+ * result value truncates and a Universal Test ID or a patient name loses the components that sat
+ * after it. At a **later** boundary nothing modeled moves and this still fires, which is
+ * over-reporting relative to those slots and never under-reporting; see
+ * {@link WARNING_CODES.ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD}.
+ *
+ * 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 gained boundary, it does not repair it.
+ *
+ * @example
+ * ```ts
+ * import { alignmentTruncatedField } from "@cosyte/astm";
+ * alignmentTruncatedField({ recordIndex: 2, recordType: "R", fieldIndex: 4 });
+ * ```
+ */
+declare function alignmentTruncatedField(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 +649,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 +851,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 +892,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 +911,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
@@ -2116,10 +2533,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.
  */
 
 /**
@@ -2273,9 +2698,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.
@@ -2896,6 +3326,27 @@ 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}.
+ * @param onAlignmentTruncatedField - Called (with the 0-based field index) for that
+ *   same condition on the **repeat** split, where no field-indexed slot moves and the
+ *   field is instead read as more repeats than the competing alignment gives it.
+ *   Where that boundary is the **first** in the field the field's own modeled reading
+ *   stops at it, because a field is modeled out of its first repeat alone; at a later
+ *   one nothing modeled moves and this still fires. See {@link TruncatedFieldSink}.
+ *   The component split is wired to neither, deliberately.
  * @returns The record's fields.
  * @example
  * ```ts
@@ -2904,7 +3355,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, onAlignmentTruncatedField?: (fieldIndex: number) => void): AstmField[];
 /**
  * Tokenize an `H` (header) record into its fields.
  *
@@ -2929,6 +3380,20 @@ 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.
+ * @param onAlignmentTruncatedField - Called with the 0-based whole-record field index
+ *   for each contested **repeat** boundary in the data portion on that same tail
+ *   test. The declaration is opaque, so it never reports here either.
  * @returns The header's fields.
  * @example
  * ```ts
@@ -2938,7 +3403,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, onAlignmentTruncatedField?: (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
@@ -2990,7 +3455,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";
 };
 /**
@@ -3065,14 +3542,63 @@ 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 it deliberately stays silent on, and
+ * why that silence is not a claim that nothing was lost there.
+ *
+ * **The same question asked on the repeat separator has a different answer, so it
+ * has a code of its own.** A gained repeat boundary moves no field-indexed slot, and
+ * where it is the **first** boundary in the field it still reaches a modeled slot,
+ * because a field's modeled reading is taken from its first repeat alone: everything
+ * past that boundary leaves the record, so a result value truncates and a Universal
+ * Test ID or a patient name loses the components that sat after it. That is
+ * `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD`; see {@link TruncatedFieldSink}, including
+ * what it does at a later boundary, where it fires and no modeled slot moves. The
+ * **component** separator is a third question again and is deliberately not answered
+ * here, because there the components do not disappear, they shift.
  *
  * Re-escaping (the inverse, for spec-clean emit) lives in the serializer and is
  * deliberately not implemented here.
@@ -3092,6 +3618,195 @@ 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 repeat or
+ * component boundary does reach a modeled slot. The **repeat** half of that is
+ * reported by {@link TruncatedFieldSink}, on the same tail test and under its own
+ * code, because what it costs is a different thing. The **component** half is
+ * measured, reported by nothing, and open: not something either 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;
+/**
+ * A callback the split calls on **exactly the condition {@link ShiftedFieldsSink}
+ * reports**, wired instead to the split taken on the **repeat** separator. The two
+ * sinks test the same predicate, because the predicate is about the bytes and the
+ * split does not know which role it is being taken on; they are separate so the
+ * caller that does know can name what the gained boundary costs, which is not the
+ * same thing in the two roles. Do not "simplify" them into one: the codes would then
+ * have to make one claim covering both, and the claim is different.
+ *
+ * **What a gained repeat boundary costs, and it is not a shift.** No field-indexed
+ * slot moves: the units slot and the result-status slot are read out of the same
+ * field numbers under either alignment. What the report says is that **the field is
+ * read as more repeats than the competing alignment gives it**, and that 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:
+ *
+ * - **The gained boundary is the FIRST in the field, and then a modeled slot is
+ *   lost.** A field's modeled value and its components are taken from its **first
+ *   repeat alone**, so everything past the boundary is still on the wire, still in
+ *   `repeats`, and gone from every modeled slot. Under a set naming the repeat
+ *   separator `F`, the value `28.6&S&F&U/L` reads as the two repeats `28.6^` and
+ *   `&U/L`, and every value extractor answers `28.6^`, while the competing alignment
+ *   reads one repeat carrying all of it. The same boundary inside a Universal Test ID
+ *   field leaves the components of the first repeat only, so a UTID whose bytes carry
+ *   a test code can come back as a single component holding a decoded delimiter, with
+ *   the coding scheme and local code read from nothing at all. A patient name loses
+ *   its given and middle names the same way.
+ * - **The gained boundary is a LATER one, and then no modeled slot moves.** The first
+ *   repeat is identical under both alignments, so the value, the components and every
+ *   slot taken from them read the same either way; what differs is the repeat
+ *   structure after the first. **This still fires there, deliberately and measurably**
+ *   (`5.0F28.6&S&F&U/L` under that same set), because 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**, which is the direction this package errs in. 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 of guessed at.
+ *
+ * **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. What is new is that the gained boundary is reported by
+ * a code no profile may tolerate, where before it was covered only by tolerable ones.
+ *
+ * **The tail is weighed one construct deep, exactly as in {@link ShiftedFieldsSink},
+ * and for the same reason.** Where the escape character the reading taken resumes on
+ * heads a sequence this codec recognizes, the bytes prefer the reading taken and the
+ * two 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.
+ * Refusing that is the over-refusal that sank an earlier candidate criterion for this
+ * family. Where it heads a sequence whose body is *unrecognized*, the competing
+ * alignment would leave two escape characters bare, so the preference is stronger
+ * again. **The truncation in that second case is real and this stays silent about
+ * it**: a named residue, measured, not overlooked, and not closed by widening the
+ * test, because widening it would report a boundary the bytes prefer.
+ *
+ * @param segmentIndex - The 0-based index of the repeat being accumulated when the
+ *   gained boundary was taken, so `0` is the boundary that ends the first repeat and
+ *   is the one that reaches a modeled slot. It is **not** a field index: the caller
+ *   splitting one field into repeats already knows which field it is in, and reports
+ *   that.
+ */
+type TruncatedFieldSink = (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
@@ -3106,6 +3821,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
@@ -3114,7 +3831,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
@@ -3132,11 +3849,38 @@ 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.
+ * @param onTruncatedField - Called on that same condition, wired only by the split
+ *   taken on the repeat separator, where the cost is not a shift but a field read as
+ *   more repeats than the competing alignment gives it. Where that boundary is the
+ *   **first** in the field the field's modeled reading stops at it; at a later one
+ *   nothing modeled moves and this still fires. See {@link TruncatedFieldSink}.
  * @returns The raw segments, in order.
  * @example
  * ```ts
@@ -3146,7 +3890,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, onTruncatedField?: TruncatedFieldSink): string[];
 
 /**
  * Deep-freeze helper for the immutable ASTM model.
@@ -3479,9 +4223,81 @@ 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.
+ *
+ * **`ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` landed next, on the same contested
+ * position and the same tail test, and it reaches a modeled slot by the other
+ * route.** It reports a contested alignment deciding a **repeat** boundary. Nothing
+ * shifts: no field-indexed slot moves, which is exactly why the shift report could
+ * not cover it. What it reports is that the field is read as more repeats than the
+ * competing alignment gives it, and **where that gained boundary is the first one in
+ * the field** it reaches a modeled slot, because a field's modeled value and
+ * components are taken from its **first repeat alone**: everything past it stays in
+ * `repeats` and leaves every modeled slot, so a result value truncates and a
+ * Universal Test ID or a patient name comes back holding only the components that sat
+ * before it. Until it existed the warnings on those streams were
+ * `ASTM_NONSTANDARD_DELIMITERS` and `ASTM_UNPAIRED_ESCAPE_CHARACTER`, both on the list
+ * below, 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**, which is over-reporting relative to those slots and never
+ * under-reporting: measured, and stated on the code itself rather than left to be
+ * found. It is safety-critical by construction and must never be admitted.
+ * Re-reading the survivors against it moved no admission, and the reason is the one
+ * the entry above already turns on: each of them re-badges the code it names and no
+ * other, and what this condition now raises is a code no profile may name.
+ *
  * **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
@@ -3493,41 +4309,102 @@ 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
  *   makes this admissible is a property of the *parse*, not of the warning: reading
  *   the character as a literal is unconditional, and tolerating the code changes
- *   nothing about how the record splits. No reader sees it, on the same grounds as
- *   the entry above: the type letter is read before any decoding, the split reader
+ *   nothing about how the record splits. None of the three readers named at the top of
+ *   this file sees it: the type letter is read before any decoding, the split reader
  *   counts fields the escape-aware tokenizer has already finished dividing, and a
- *   decoded value is never cut back into records. Contrast the condition it
+ *   decoded value is never cut back into records. **Two later readers DO see it**, and
+ *   they are named below rather than left out of this bullet. Contrast the condition it
  *   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 that much still
+ *   holds: it asks whether the character two positions past a sequence *is* the escape
+ *   character, never whether that character heads a sequence of its own. 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.
+ *
+ *   **The two TAIL readers are a different matter, and "no reader sees it" is
+ *   therefore FALSE of this entry and must not be restored.** Both
+ *   `ASTM_RECORD_ALIGNMENT_SHIFTED_FIELDS` and
+ *   `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` fire on `!isEscapeSequenceAt(text, i + 4,
+ *   escape)`, which is exactly the question this code answers, asked about the
+ *   character just past a contested boundary. That is a reader of the reported
+ *   condition, so this entry survives on the same narrower claim the unknown-sequence
+ *   entry above already uses, not on nothing reading it: a profile re-badges the code
+ *   it names and no other, and what those two readers raise is not tolerable in any
+ *   case. If a future reader of this condition ever produces something a profile
+ *   **can** tolerate, this entry stops being admissible and comes off the list.
  * - `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
@@ -3539,8 +4416,12 @@ 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 field whose modeled reading stops at a boundary only one alignment has,
+ * 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
@@ -3571,6 +4452,29 @@ 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.
+ *
+ * `ASTM_RECORD_ALIGNMENT_TRUNCATED_FIELD` is not on this list and must not be added
+ * to it either. It reports the same contested alignment deciding a **repeat**
+ * boundary, where no slot changes hands and a modeled reading is cut off instead: the
+ * field is read out of its first repeat alone, so where that boundary is the first
+ * one a value truncates and a Universal Test ID's coding scheme and local code are
+ * read from bytes that are no longer in any modeled slot. Reporting a value that is
+ * not the whole of what the sender wrote fails the first half of the two-clause test
+ * outright.
+ *
  * @example
  * ```ts
  * import { TOLERABLE_CODES } from "@cosyte/astm";
@@ -3675,7 +4579,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
@@ -4912,4 +5819,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 TruncatedFieldSink, type UniversalTestId, type UniversalTestIdProvenance, type UnknownEscapeSink, type UnpairedEscapeSink, type UnsupportedRecord, VERSION, type VerbatimInput, WARNING_CODES, type WarningCode, alignmentShiftedFields, alignmentTruncatedField, 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 };