Checking Subject and Event Alignment in Model Inputs

Why Subject and Event Alignment Matters

A model input can contain the expected number of rows and still be wrong. An observation may have been assigned to another subject during a join, a subject identifier may have been converted to a different representation, or records may have been placed in an order that changes how the software interprets events. Such errors can be hard to see in a diagnostic summary: they concern which subject a record belongs to and where that record sits in the subject's event history.

This review is about record identity and sequence, not about deciding whether the model equations are correct. The essential question is whether each model-input record corresponds to the intended subject and event, and whether its position is consistent with the documented event rules. Counts and ordering checks provide evidence, but they do not replace understanding what each event means.

No single event key is correct for every dataset. Two observations can legitimately share a subject and time, and a dose and an observation can occur at the same recorded time. If the chosen key omits a field needed to distinguish those records, it can label distinct events as duplicates. Conversely, a key that includes a field altered during processing may fail to match the same event across two files. The key therefore needs to follow the data's documented meaning.

Set the Review Rules Before Checking the Rows

Start with an authoritative subject mapping and a clear account of the event fields. Earlier review of analysis population and exclusion counts establishes which subjects and records are in scope; this check asks whether the in-scope records remain correctly identified and aligned. For each input and any comparison source, establish:

• Which field or fields identify a subject, and whether IDs are character labels or numeric values.
• Which fields describe event time, event type, and any within-time sequence.
• Which combinations of fields should be unique, and which repeated combinations may be valid.
• Which ordering rules apply, including how tied times should be handled.
• Which source fields or stable record identifiers can be used to match records between files.

These are review assumptions, not automatic properties of the data. In particular, chronological ordering generally means that times do not decrease within a subject, but the required ordering among records tied at the same time depends on the event definitions and input conventions. A reviewer should not invent a tie-breaking rule from the observed row order.

Check Subject Identifiers and Record Counts

First compare the subject identifiers in the model input with the expected subject set for that input. Report identifiers that are missing, unexpected, or repeated in contexts where a single subject-level record is expected. Then compare record counts by subject and, where useful, by event type. These summaries can reveal an entire subject's records being dropped or an unexpected cluster of records assigned to one subject.

Preserve identifiers in their intended representation. For example, the labels "014" and "14" are different character identifiers unless the data specification explicitly says otherwise. Converting IDs to numbers can erase leading zeros; trimming spaces or changing case can also collapse two distinct labels. Normalization is appropriate only when the mapping rules say those differences are formatting artifacts, and the reviewer should check whether normalization creates collisions.

Check Event Order Without Mislabeling Ties

For each subject, inspect event times in the order presented to the model and test whether they follow the stated ordering rule. If chronological nondecrease is required, a simple adjacent-row condition is \(t_{i+1} \geq t_i\) within a subject. A violation identifies a local decrease; it does not by itself prove the data are wrong, because time resets, separate records, or other conventions may be allowed. Resolve each flag against the documented input rules.

Repeated times require particular care. A dose and an observation at the same time may both be valid, while their ordering can matter to the intended event interpretation. If a tie rule exists, check it using the event type and any sequence field. If none is specified, report the tie for clarification rather than asserting that one row order is correct.

Match Records Across Sources, Not Just Marginal Totals

When a model input is compared with a source or intermediate dataset, use a key that identifies the same event on both sides. A candidate composite key might be subject ID, time, event type, and analyte; a stable source-record ID may provide a stronger match if it is preserved. Compare the expected and observed record sets by key, then inspect values such as time, event type, dose amount, or observation value. Do not assume that equal numbers of records by subject prove the records are the same.

A useful justification is to compare records at the level where misalignment can occur. Let \(K\) be the chosen event key. For each key \(k\), let \(c_S(k)\) be its count in the comparison source and \(c_M(k)\) its count in the model input. If records are expected to transfer one-for-one, alignment requires \(c_S(k)=c_M(k)\) for every \(k\), as well as agreement on the checked fields. Equal overall totals only imply \(\sum_k c_S(k)=\sum_k c_M(k)\); they do not imply equality for each key. For example, one record can be lost at one key and an unrelated record duplicated at another while the totals remain equal.

Diagnostics, Alternatives, and Limits

A reproducible review can generate subject-level record counts, sorted event listings, duplicate-key reports, and source-to-input comparison tables. These automated checks are useful for broad coverage, especially when a dataset has many subjects. A targeted manual inspection is useful for interpreting flagged records and confirming that the key and tie rules represent the actual event definitions. The two approaches complement each other: automation can apply explicit rules consistently, while review is needed to judge whether the rules and exceptions are appropriate.

Investigate patterns rather than dismissing isolated flags without explanation. Useful signals include:

• Unexpected subject IDs or a sharp difference in records per subject.
• Duplicate composite keys, especially when uniqueness is expected.
• Time decreases, irregular sequences, or same-time records in an undocumented order.
• Records whose subject, event type, or values differ after matching to their source.
• Many mismatches concentrated after a particular merge, transformation, or file boundary.

Every diagnostic has limits. A duplicate key can be a real pair of events if the key omits a distinguishing field. A chronological sequence can be correct while an observation is assigned to the wrong subject. Matching records can still carry a consistently incorrect value if the comparison source is not authoritative. Likewise, an ID that looks unusual is not proof of a merge; it is a reason to verify the reference mapping and processing rule.

Common Mistakes

• Using total rows as proof of alignment. Equal totals can conceal a swap, a missing row paired with an extra row, or incorrect subject assignment. Compare counts and values at an event key.
• Treating every repeated time as a duplicate. Multiple valid events may share a time. Define a key that distinguishes them and apply documented tie rules.
• Converting IDs before checking uniqueness. Numeric conversion or normalization can collapse distinct labels. Check for collisions and validate the mapping first.
• Calling a chronology flag an error without checking conventions. A decrease is a rule violation only if nondecreasing time is required for that input. Investigate against the documented event semantics.