## Annotation protocol

### 1. Know the task

- The **XBRL reference formula** comes from this company's filed calculation
  linkbase and is treated as the formula ground truth.
- Do not invent, validate, or rewrite the accounting formula.
- Your task is only to check whether each XBRL parent and child is mapped to the
  correct row in the displayed PDF table.
- Use only the displayed image, the XBRL-to-PDF reference mapping, and the
  extracted statement rows. Do not retrieve the filing, hidden provenance, or
  another annotator's answers.

### 2. Work independently

- Use only your assigned slot: **Annotator 1** or **Annotator 2**.
- Do not switch slots or inspect the other annotator's progress.
- Judge every case independently.

### 3. Compare the row mappings

Check the reference table term by term:

1. Does the XBRL parent label point to the correct PDF parent row?
2. Does every XBRL child label point to the correct PDF child row?
3. Does the extracted PDF label describe the same financial item as the XBRL
   label, allowing harmless wording differences such as note references?
4. Are the mapped rows in the displayed statement and the intended table
   context?
5. Are any rows missing, duplicated, cropped, or too ambiguous to identify?

Keep these three sign concepts separate:

- **XBRL operation:** the fixed calculation-linkbase weight, displayed as
  **Add (+1)** or **Subtract (-1)**. It must not be edited or re-annotated,
  and it is not a unit or display scale.
- **XBRL fact sign:** the sign of the semantic fact stored in the filing. This
  sign is not necessarily visible in the rendered statement.
- **PDF display sign:** parentheses or a printed minus sign used to present a
  deduction to readers. It is not a second calculation operation.

For example, `Interest expense (233)` can store a positive XBRL fact of `233`
and use **Subtract (-1)** in the calculation relation. Its contribution is
`-233`, not `-(-233)`. Conversely, a cost may be printed as the positive number
`9,855` and still use **Subtract (-1)**. Never apply the XBRL operation and the
PDF display sign twice. Do not use visible arithmetic alone to reject a
reference relation; displayed totals may also differ slightly because of
rounding.

### 4. Use the paired image views

- Start every case in **Masked**, which is also the main benchmark input.
- Open **Original numbers** only when values help resolve a row, unit, duplicate label, or crop.
- Switching views does not change the task: verify PDF-to-XBRL row mappings only.
- Do not derive, validate, or rewrite the XBRL formula from the visible numbers.
- A printed parenthesis or minus sign does not by itself make a mapping wrong.
- The system records whether the original-number view was opened before saving.

### 5. Choose one alignment decision

**Aligned**

Every XBRL parent and child is mapped to the correct visible PDF row. Leave the
pre-filled row mappings unchanged and do not select any Issues.

**Misaligned**

At least one XBRL term points to the wrong PDF row, and the correct row is
visible in **All statement rows**. Select every applicable Alignment issue and
correct only the wrong PDF row IDs.

Use **Misaligned** only for an incorrect PDF row mapping. If every mapped row is
correct but the XBRL relation itself still appears questionable, do not change
row IDs and do not choose **Misaligned**.

**Not verifiable**

The mapping cannot be checked from the displayed evidence because a required
row is missing, cropped, unreadable, duplicated beyond resolution, in a
different table or context, or the XBRL reference itself appears questionable.
Select an Alignment issue and explain the problem in Notes. Do not rewrite the
formula; cases flagged as a possible XBRL issue go to expert review.

For a questionable formula or weight, choose **Not verifiable**, select
**Possible XBRL reference issue**, and describe the concern in Notes.

### 6. Correct a misalignment

- Use **Mapped parent PDF row** only if the parent mapping is wrong.
- In **Child row mappings**, keep every XBRL child label unchanged and edit only
  the **Mapped PDF row ID** cell for an incorrectly mapped child.
- Keep one row for every XBRL child. Do not add or delete formula terms.
- The system preserves every XBRL coefficient automatically.
- If the correct PDF row is not available, choose **Not verifiable** instead of
  guessing.

### 7. Handle units and display scale

- A caption such as **in millions** or **in thousands** is normally a common
  display scale for the monetary rows in that table.
- A common display scale does not change an XBRL coefficient. Never use
  `1,000` or `1,000,000` as a coefficient.
- USD, shares, percentages, and per-share values are different units. A unit
  mismatch may indicate that the XBRL term was mapped to the wrong PDF row.
- If the needed unit or scale is cropped and prevents row identification,
  choose **Not verifiable** and explain what is missing.

### 8. Assign confidence

- **High:** every referenced row and label match is clear.
- **Medium:** the decision is supported, but one visual or wording cue is weak.
- **Low:** substantial ambiguity remains; explain it in Notes.

Before saving, confirm that you checked the parent and every child mapping. The
goal is PDF-XBRL row alignment, not manual accounting-formula annotation.