In a mapping between a case repository and an issue tracker, several fields can be edited on both sides. How do you decide who owns each one?

## Ownership is per field, not per system The instinct when connecting two systems is to declare one of them authoritative. It never survives contact, because the two hold different kinds of knowledge and each is right about its own kind. The workable unit is the **field**, and the question for each one is not *which system is more important* but **where is this value actually decided**. That question separates cleanly along one line: - **Facts about the verification event** are decided in the repository: which case ran, in which cycle, on which environment, what the executor observed, which build. The tracker can hold and display them, but no one working in the tracker is in a position to correct them. - **Judgements about the work** are decided in the tracker: how the item is ranked, who will pick it up, which state it is in, which release it is targeted at. These are the output of triage and planning, and the repository has no basis for an opinion. There is a third group that causes most of the trouble: fields that *look* like facts but are edited by people. A summary line written from the failing case and then rewritten by a triager to describe the real defect is the classic example. It starts as a fact and becomes a judgement the moment a human improves it. ## Three write modes, and why three is enough Express every mapped field as exactly one of: 1. **Write once at creation.** The integration supplies the value when the item is created and never touches it again. Correct for anything that describes the moment of discovery: the run, the environment, the observed behaviour, the link back to the case. It is history — updating it later would be falsifying it. 2. **Owned and kept current by one named side.** That side may overwrite; the other side must not write it at all. Correct for a value that has a live, changing truth on one side only. 3. **Not mapped.** Neither system writes it. Correct far more often than teams expect, especially for fields whose whole purpose is to record a human decision. Most fields belong in mode 1 or 3. Mode 2 is the one worth being stingy with, because a field kept current by one side is the only mode where a write can destroy someone else's edit. | Field kind | Mode | Reason | |---|---|---| | The failing case, cycle, environment, build | Write once | It records what happened; later edits would rewrite history | | Free-text summary a triager improves | Write once | It starts as a fact and becomes a human's judgement | | The item's workflow state | Not mapped | Decided by people working the item, in their own process | | Ranking of the work | Not mapped | A planning judgement the filing side cannot make | | A running count of subsequent failures | Owned by the repository | Only the repository sees new runs, and the value genuinely changes | ## The failure this prevents The expensive outcome is the **silent overwrite**. Someone triaging edits a value by hand, using knowledge that exists nowhere in the repository, and a later write puts the machine value back. What makes it corrosive is not the lost edit but what people conclude from it: that the integration is unreliable, that their edits do not stick, and eventually that the whole link is not worth trusting. Trust in an integration is lost in exactly this way — never in one dramatic failure, always in a handful of small edits that did not survive. The second failure is subtler: **ownership assigned by default**. Nobody decides, so the integration writes whatever it can, and ownership ends up meaning *whoever wrote last*. That is not a design, and it produces different answers depending on timing. ## Judgement calls worth having a position on - **When a field has no clear owner, suspect it is two fields.** A single value meaning both *what the run observed* and *what the team concluded* should usually be split, so each half can have an honest owner. - **Prefer write-once to shared ownership.** A creation-time fact plus human editing afterwards is simpler to reason about than any reconciliation rule, and it fails in a way people can see. - **Let the people doing the work own their own vocabulary.** Ranking, state and assignment belong to whoever lives in the queue. An integration that overwrites them is asserting a judgement it is not qualified to make. - **Write the ownership down beside the mapping.** The mode for each field is the part a future reader most needs and the part least likely to be inferable from the configuration alone. ## The one-line version **Ownership follows the decision.** Whichever side genuinely makes the judgement a field records is the side that may write it — and most fields, once you ask that question honestly, turn out to be either a creation-time fact or something the integration should not be writing at all.