ZorovalDocs

Docs / Working as a team / Collaboration

Collaboration

The judge inherits your team's agreement about what counts as wrong. If the people on your team disagree, no model resolves that for you, so the disagreement has to be worked out in the open.

Why one person cannot do this

Open coding looks like solo work. It is not, and teams that treat it that way get a taxonomy that quietly encodes one person's blind spots.

Different people looking at the same trace see genuinely different failures:

A taxonomy built by one of those four measures one of those four perspectives. The rate will be real, and it will be a rate for the wrong thing.

The taxonomy becomes your vocabulary

The most underrated effect of this work is linguistic. Once a team has a confirmed list of failure modes, quality conversations change shape:

BeforeAfter
"The agent felt worse this week.""Hallucinated external fact went from 44% to 71% on the 14th."
A bug report describing one bad output in three paragraphs."Another gate failure case, trace 2b95e07f."
"Did the prompt change help?""Wrong output format dropped nine points and nothing else moved."
Onboarding an engineer by having them read old incidents.Onboarding them by having them read the code list and label ten traces.

That vocabulary outlives individual people. It is the part of this work that keeps paying after the person who started it has moved to another team.

Calibration: the exercise worth doing

Calibration means two or more people coding the same traces independently and then comparing. Disagreement is not a failure of the exercise, it is the entire output of it.

  1. Pick ten traces nobody has codedInclude a few that are clearly fine. Agreement on negatives matters as much as agreement on positives.
  2. Code them independentlyNo discussion first. Discussion before coding produces agreement that is not real.
  3. Compare, one trace at a timeFor each disagreement, ask which of three things happened: different reading of the same evidence, different evidence entirely, or different definition of the code.
  4. Fix the definition, not the peopleAlmost every disagreement worth acting on is a scope problem. Rewrite the code name until both readings become impossible. Do not average two labels into a vaguer one.
  5. Re-code the disputed tracesOnce the name is fixed, go back and apply it to the traces you disagreed on. If it still does not settle them, the name is not finished.
Rule of thumb

If two people who know the product cannot apply a code to the same ten traces and agree, the code is not ready to monitor. Send it back to axial coding.

A workable division of labour

WhoDoesTime
Domain expertFirst open coding pass on a sample. Names what is wrong in domain terms.One or two sittings, then occasional
EngineerSecond pass for mechanical failures, checks that the evidence points at real operations, owns fixes.One sitting, then per release
Both togetherAxial coding and calibration. This is the meeting that matters.An hour, once, then monthly
Whoever owns qualityChooses the monitored codes, watches the dashboard, calls regressions.Minutes daily

Everyone you nominate works in the same workspace, on the same traces, the same codes and the same verdicts. Nobody has a private copy of the taxonomy, because a private copy is how two people end up meaning different things by the same code name.

What goes wrong