# Three decisions, mapped: what changed in v1.1.0, sgit.ai > The changes to the article "Three decisions, mapped" in v1.1.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Three decisions, mapped](../../three-decisions-mapped.md) / [Versions](../three-decisions-mapped.md) / v1.1.0 # Three decisions, mapped: what changed in v1.1.0 From v1.0.0 (2026-10-17, `4c750bd9b`) to v1.1.0 (2026-10-18, `bb2978831`), paragraph by paragraph. 7 paragraphs added, 5 removed, 7 changed in place, 44 unchanged. About 355 words added and 188 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [all versions](../three-decisions-mapped.md) 1 unchanged paragraph Summary: The fourth article in the series on agent decision policies puts the pieces together on three scenarios, two of them real. First, deleting an agent's memory in Mondweep Chakravorty's SGit adapter for Ruflo: the behaviour row is defined, implemented and enforced, the decision behind its "approval" is not yet defined, and nothing records what happened. Second, this newsroom's own release, which ships on its own: the behaviour boundary holds at the platform, the workflow is a script and a validator, and the interesting part is a decision nobody wrote down. In every release since this afternoon I shipped with one failing test that predates my changes, and I made that call each time on my own. It should be a written decision with an owner and an expiry. The same evening produced two small cases for the case-law article: a figure that shipped with a date nobody had checked, and a counter that flagged two commits without a leak scan, both of which turned out to be in scratch test repositories, a case the rule did not mean to cover. Third, an illustrative customer refund built on the third design in Hope or enforcement, where the limits are already in the tools, and a new workflow that tries to widen them is caught by a subset check before it runs. Each element is mapped with the policy it belongs to and fourfive states: defined, implemented, enforcedenforced, observed and observed.verified. !shot dn-map.webp | images/ | Three scenarios mapped element by element: memory deletion in the SGit adapter for Ruflo, this newsroom's release, and an illustrative customer refund. Each element is labelled ABP, decision or workflow, with fourfive states: defined, implemented, enforcedenforced, observed and observed.verified. The memory row is enforced but not observed; the newsroom's decision to ship with a failing test is not defined at all; the refund's limits hold at every state because they are inenforced and observed, and nothing verifies the tools.amount under them. | matrix 2 unchanged paragraphs, under In short {#in-short} • **Three scenarios, one map.** Each element gets its policy, behaviour, decision or workflow, and fourfive states. 3 unchanged paragraphs • **The refund is the mature one.** Itsrefund's limits are inmature;theitstools,amountsoisanot.** A new workflow that widens thema limit is caught before it runs.runs; a wrong amount under the limit is not caught at all. 2 unchanged paragraphs, under How to read the map {#how} The [first article in this series](../../three-policies-for-an-agent.md) separates three policies: behaviour (what an agent may do), decision (who chooses at a branch point, on what evidence, within what limits) and workflow (which steps, in what order). It gives each element fourfive states: 3 unchanged paragraphs • **Observed.** We would know afterwards whether it held. In the tables, D · I · E · O are those four states in that order. • **Observed.** We can reconstruct afterwards what happened. • **Verified.** We can prove, against records the agent did not write, that the outcome was right. In the tables, D · I · E · O · V are those five states in that order. 3 unchanged paragraphs, under Scenario 1: deleting an agent's memory {#memory} | Element | Policy | D · I · E · O · V | |---|---|---| | `delete.memory.project` needs approval | Behaviour | Yes · Yes · Yes · No · No | | Who approves, on what evidence | Decision | Partly · No · No · No · No | | Request, verify, approve, delete | Workflow | Partly · Partly · Partly · No · No | 6 unchanged paragraphs, under Scenario 2: this newsroom's release {#newsroom} | Element | Policy | D · I · E · O · V | |---|---|---| | Push only to dev; sgit.ai is read-only | Behaviour | Yes · Yes · Yes · Yes · Yes | | Ship with a failing test that predates the change | Decision | No · n/a · n/a · Partly · No | | The release recipe | Workflow | Yes · Yes · Partly · Yes · Partly | | A leak scan before every commit | Workflow | Yes · Yes · Partly · Yes · Partly | 8 unchanged paragraphs, under Scenario 3: a customer refund {#refund} | Element | Policy | D · I · E · O | |---|---|---| | Refund up to 100 GBP an order | Behaviour | Yes · Yes · Yes · Yes | | Above 100 GBP: team lead, then finance | Decision | Yes · Partly · Partly · Partly | | Propose, check, refund, record | Workflow | Yes · Yes · Yes · Yes | **Behaviour and workflow.** Both are mature, because they are built into the tools: the agent calls `propose_refund`, the tool checks the limit, the refund is made or refused, and it is recorded. There is no path around it, which is the lesson [the policy guards the door](../../the-policy-guards-the-door.md) draws from the Ruflo run. **Decision.** Above 100 GBP a person decides, and the routing is defined. What is only partly there is the part that turns a person's approval into evidence: what they saw, why they agreed, and whether the next similar case can follow it. | Element | Policy | D · I · E · O · V | |---|---|---| | Refund up to 100 GBP an order | Behaviour | Yes · Yes · Yes · Yes · No | | The amount itself, under 100 GBP | Decision | No · No · No · Yes · No | | Above 100 GBP: team lead, then finance | Decision | Yes · Partly · Partly · Partly · No | | Propose, check, refund, record | Workflow | Yes · Yes · Yes · Yes · No | **Behaviour and workflow.** Both are enforced, because they are built into the tools: the agent calls `propose_refund`, the tool checks the limit, the refund is made or refused, and it is recorded. There is no path around it, which is the lesson [the policy guards the door](../../the-policy-guards-the-door.md) draws from the Ruflo run. **The amount nobody checks.** Under 100 GBP, the tool checks that the refund is within the limit, and nothing checks that it is the right amount. An agent that misreads a discount and refunds 90 GBP where 70 was paid passes every control here. That is the failure in Ashish Rajan's Northstar example, and [allowed is not right](../../allowed-is-not-right.md) answers it: the amount needs a decision policy of its own, worked out from the order records by something other than the agent. The [Northstar twin](https://newsroom.sgit.ai/demos/vaults/northstar-twin/index.html) runs that on thirteen cases. **Decision above the limit.** Above 100 GBP a person decides, and the routing is defined. What is only partly there is the part that turns a person's approval into evidence: what they saw, why they agreed, and whether the next similar case can follow it. 16 unchanged paragraphs, under What the three have in common {#common}, The series {#series}, What this does not claim {#limits}… [all versions](../three-decisions-mapped.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/three-decisions-mapped/v1.1.0.html)*