In a TestRail-class case repository, why is the permission to record a result on a run kept separate from the permission to author or edit a case definition?

## The two things a case repository holds A case repository — a TestRail-class standalone product, or a Jira-resident tool such as Xray or Zephyr that lives inside the tracker — stores two kinds of thing that behave nothing like each other. - **Definitions**: the cases, folders, steps, expected results and custom fields. These describe *what the organisation says it tests*. They are shared, long-lived, and referenced by everything downstream. - **Executions**: cycles, runs and the outcomes recorded against them. These are *evidence about one moment*. Individually cheap, collectively the record that release conversations rest on. A single write permission would treat those as the same act. They are not. Editing a definition changes a shared object that other records point at; recording an outcome appends one observation. Almost every product in this class therefore exposes roughly the same separable capabilities, whatever the labels its screens happen to use. | Capability | What the actor changes | What abuse of it costs you | |---|---|---| | **Read** | Nothing | Disclosure — an inventory describes where a system is believed to be fragile | | **Author** | The stored definition | The meaning of every outcome, past and future, that points at it | | **Record a result** | One outcome in one cycle | One data point, visible and correctable | | **Close a cycle** | The cycle's state and what is reported from it | The numbers other people act on | ## Why authoring is the dangerous one A recorded outcome is a claim of the form *this definition, in this cycle, ended this way*. In most products the outcome stores a reference to the definition rather than a frozen copy of its text, so the definition is read at display time. Edit that definition later and every historical outcome attached to it appears to assert something it never asserted. That is a quiet corruption of the record, and unlike a wrong result it does not look wrong: the counts are unchanged and only the meaning has moved. Recording an outcome cannot do that. It adds a row. If the row is wrong, someone records the right one and both remain visible. **The asymmetry in damage is the entire reason the capabilities are separate** -- not tidiness, and not org-chart politics. ## Closing a cycle is a third act, not a bigger version of the second Closing is neither authoring nor recording: it is publishing. It converts a working set of outcomes into a statement that people report upward, and in many products it stops further outcomes landing in that cycle. Keeping it separate means: - an automated push cannot end a cycle early because one partial run happened to finish; - there is a human owner for the moment the numbers stopped being working data; - reopening, where a product allows it, is a visible act rather than a side effect of something else. ## What the split buys you in practice The payoff teams actually feel is the **machine account**. A pipeline that reports outcomes needs exactly one capability: record a result against a cycle that already exists. Grant that and nothing more, and: 1. A stolen or misbehaving pipeline credential cannot rewrite the inventory it reports against. 2. Every automated outcome is attributable to the reporting account, not to whichever engineer's credential happened to be nearest when the job was wired up. 3. The blast radius of a pipeline bug is bounded to data that can simply be re-recorded. Where that credential is stored and how it reaches the job is a pipeline concern with its own answers. What matters here is what the account is permitted to do the moment the credential is spent. ## Where the split leaks in real installations - **Coarse presets.** Many products ship a small set of bundled roles, and the narrowest one that can record results also happens to author. Teams hand the pipeline that preset and call it scoped. - **Convenience creep.** Someone grants close-cycle to the reporting account so it can tidy up after itself, and the pipeline starts ending cycles that humans were still working in. - **Administration as a shortcut.** An administrator-level preset implies every capability at once, and it is the fastest thing to grant when a push starts failing late on a Friday. - **A person's credential in the pipeline.** The job then carries whatever that human can do by hand, across every project they belong to, and dies when they change teams. ## What to ask when you set an actor up 1. Which capability does this actor actually exercise? Write it down before choosing anything. 2. Is there a preset that grants only that? If not, take the narrowest available and record the surplus capability as accepted risk rather than pretending it is not there. 3. Who holds close-cycle for this project, by name? 4. When something looks wrong in the record, can the trail tell you which account did it? If the answer to the last one is no, the split has been named rather than implemented.