P3-9.5 By What Is the Same Event Continuously Tracked Across Multiple Outputs¶

Section ID: P3-9.5 Version: v2026.07.20

Even if a comparison report, a review-candidate queue, and a target-candidate table play different roles, one sample should still be tracked continuously by the same identification rule whenever possible. That is why a column such as event_id appears repeatedly across multiple tables. If this link becomes vague, it may still be possible to understand that the three outputs are different tables, but it becomes hard to explain again why a given event was promoted and how a given review result later turned into a target candidate. A comparison report, review queue, and target candidate table can play different roles, but the same sample identity and the minimum evidence link should not be broken if possible.

Why Must the Same Event Be Tracked Continuously¶

There are three reasons the same event needs to be traced continuously.

The outputs can therefore split into three, but the identity of the sample should not split with them.

What Becomes the Traceability Criterion¶

In the simplest case, an identifier column such as event_id or sample_id becomes the traceability key. In practice, however, two or three elements may be needed together like this.

For example, even when event_id is the same, the baseline definition or review time can differ. So when tracking the same event, it is safer to leave not only who is it but also when was it read and under what comparison condition.

What Remains and What Shrinks Across the Three Outputs¶

Even for the same event, the column composition can shrink when the purpose of the output changes. But identification criteria and core evidence columns should not disappear too quickly.

The key is to leave trace keys such as event_id and the minimum evidence while reducing explanations that do not fit the purpose of each output.

Example of One Event Moving Through Three Tables¶

Suppose the same event A exists.

1. Comparison report¶

2. Review-candidate queue¶

3. Target-candidate table¶

The three tables have different columns, but all point to the same event_id = A. Only with this link can you later explain again why did A become review_needed = 1.

Why Are Basis Columns Such as note_source Needed¶

One thing often missed when building a target-candidate table is the basis. If only review_needed = 1 remains and every reason for it is thrown away, it becomes difficult later to recheck label consistency.

So even before a target-candidate table becomes a completely clean learning table, it is safer for it to temporarily keep a structure where minimum evidence can still be traced.

A Small Diagram¶

flowchart TD
    A[event_id = A]

    A --> B[Report table<br/>diff<br/>report sentence]
    A --> C[Review queue<br/>review_needed<br/>priority score]
    A --> D[Target-candidate table<br/>late_drop_rate<br/>note_source]

    B --> E[Trace back to comparison evidence]
    C --> E
    D --> E

    E[Why was A promoted?<br/>same sample identity<br/>retained evidence links]

This diagram shows more directly not just that the same event_id repeats across many tables, but why that repetition is needed. Even when the comparison report, review queue, and target-candidate table serve different purposes, it should still be possible in the end to explain why was A promoted. So what matters more than merge code is that the same sample identity + retained evidence creates the traceability structure.

The same identifier column therefore repeats not to mechanically join tables, but to explain later the source of the result and the grounds for the judgment. A comparison report, a review queue, and a target-candidate table should keep the same sample-identification rule whenever possible so that evidence and label candidates can later be reconnected. If this identification rule becomes vague, it becomes difficult to reconnect the same event's comparison evidence, review result, and target candidate.

Sources and References¶

• W3C, PROV-Overview: An Overview of the PROV Family of Documents, provenance and entity linkage overview. Used to check the provenance view that the same event's comparison evidence, review result, and target-candidate columns should remain traceable with their creation context. https://www.w3.org/TR/prov-overview/ / Accessed: 2026-07-20
• Google, Machine Learning Glossary, labeled example, label. Used to check that a labeled example carries features together with a label, supporting the explanation that the same sample identity should stay connected to result-column candidates. https://developers.google.com/machine-learning/glossary / Accessed: 2026-07-20