RAID Log API

The RAID log is where a project writes down what may go wrong and what it leans on: risks (something that may happen and would hurt, scored by probability and impact, with a mitigation and a contingency), assumptions (something taken as true for the plan to hold, reviewed until it is confirmed or fails), issues (something that has happened and hurts now, scored by impact) and dependencies (something the project needs from outside itself). The four kinds share one sequence (CRM-RSK-4) and one table, because the review meeting walks them together and an assumption that fails becomes an issue without changing its key. Each item carries the area it touches, who owns it and who raised it, when it is due or next reviewed, and a status from open through monitoring, mitigating, resolved, closed, occurred and accepted.

Every save of an item writes a version; the versions are read and put back through the endpoints below, under the log's own abilities.

The log is internal. A staff token sees the items of the projects it may see; a client guest's token sees none of them, and an item it asks for is a 404 RESOURCE_NOT_FOUND, never a 403. Every write runs the same action the RAID Log page runs, under the project permissions, and announces itself as a raid_item.* event.

EndpointsCopy Anchor Link

Related

Work Items APIThe stories and tasks a risk's contingency or an issue's fix becomes, once links land.Activity APIWho changed an item and when, beside the versions themselves.raid_item.* eventsThe lifecycle of a project's RAID log: a risk, an assumption, an issue or a dependency raised, changed, moved along its lifecycle, put back to an earlier version and deleted.