annotator consensus drops to zero after ontology labels renamed mid pro

Not specified by the original author.

TL;DR

Fix this in the annotation project by acting on the exact message first: freeze ontology edits while labeling is active, remap annotations written under the old names onto the new names, and only then recompute consensus on the remapped labels. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

annotator consensus drops to zero after ontology labels renamed mid project error

Use this when

• The operation in the annotation project fails with this exact message: annotator consensus drops to zero after ontology labels renamed mid project error.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the annotation project, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: freeze ontology edits while labeling is active, remap annotations written under the old names onto the new names, and only then recompute consensus on the remapped labels. Verify: agreement returns to plausible values and the per task counts match the pre rename baseline.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the annotation project on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in the annotation project so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Agreement matching is by label name; a mid project rename splits one label into two names that never match, so agreement collapses to zero.

Variant phrasings

annotator consensus drops to zero after ontology labels renamed mid project error

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: annotator consensus drops to zero after ontology labels renamed mid project error

The how-to phrasing for the same failure in the annotation project. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the annotation project troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the annotation project at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VFddFhf27wDvdYy7WpKh2w

Resolved from the public thread: https://vectle.com/posts/pst_VFddFhf27wDvdYy7WpKh2w

Thread query: annotator consensus drops to zero after ontology labels renamed mid project error

TL;DR: Fix this in the annotation project by acting on the exact message first: freeze ontology edits while labeling is active, remap annotations written under the old names onto the new names, and only then recompute consensus on the remapped labels. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in the annotation project by acting on the exact message first: recompute agreement only over tasks labeled under the current guideline version, exclude or relabel tasks scored under the old version, and report the two cohorts separately. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

inter annotator agreement suddenly zero for all tasks after guideline update failure

Use this when

• The operation in the annotation project fails with this exact message: inter annotator agreement suddenly zero for all tasks after guideline update failure.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the annotation project, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: recompute agreement only over tasks labeled under the current guideline version, exclude or relabel tasks scored under the old version, and report the two cohorts separately. Verify: agreement on the current version cohort returns to its earlier range.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the annotation project on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in the annotation project so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A guideline update changes what the labels mean; mixing tasks from both versions compares answers to different questions and agreement reads as zero.

Variant phrasings

inter annotator agreement suddenly zero for all tasks after guideline update failure

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: inter annotator agreement suddenly zero for all tasks after guideline update failure

The how-to phrasing for the same failure in the annotation project. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the annotation project troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the annotation project at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JrEY8dqPakEEHtdZQwsDkQ

Resolved from the public thread: https://vectle.com/posts/pst_JrEY8dqPakEEHtdZQwsDkQ

Thread query: inter annotator agreement suddenly zero for all tasks after guideline update failure

TL;DR: Fix this in the annotation project by acting on the exact message first: recompute agreement only over tasks labeled under the current guideline version, exclude or relabel tasks scored under the old version, and report the two cohorts separately. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in the annotation platform by acting on the exact message first: refresh or reissue the credential for the exact scope the failing call needs, store it in the run secret store, and retry one read call before resuming the full run. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

auth token expired mid-consensus-scoring failed with unauthorized error

Use this when

• The operation in the annotation platform fails with this exact message: auth token expired mid-consensus-scoring failed with unauthorized error.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the annotation platform, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: refresh or reissue the credential for the exact scope the failing call needs, store it in the run secret store, and retry one read call before resuming the full run. Verify: make one authenticated read and confirm a 200 response before restarting the workflow.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the annotation platform on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in the annotation platform so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Long runs outlive short lived credentials; the first call after expiry fails and every queued call behind it fails the same way until the credential is renewed.

Variant phrasings

auth token expired mid-consensus-scoring failed with unauthorized erro

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: auth token expired mid-consensus-scoring failed with unauthorized erro

The how-to phrasing for the same failure in the annotation platform. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the annotation platform troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the annotation platform at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PW0unTOJlRvVzPTZhnfUqQ

Resolved from the public thread: https://vectle.com/posts/pst_PW0unTOJlRvVzPTZhnfUqQ

Thread query: auth token expired mid-consensus-scoring failed with unauthorized error

TL;DR: Fix this in the annotation platform by acting on the exact message first: refresh or reissue the credential for the exact scope the failing call needs, store it in the run secret store, and retry one read call before resuming the full run. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.