InitiativesIdea
Change requests
A change request asks to change an initiative’s plan after it was approved. Whoever raises it says what can’t stand and why. The agent sets out the options and what each would change. The owner, or someone who edits the initiative, decides.
Changing the plan in the open
Section titled “Changing the plan in the open”Once an initiative is approved, people build on what was agreed. While they build, they still find things nobody could know while shaping. A supplier keeps data in the wrong place, or a customer changes their mind.
If anyone could quietly change the plan then, the approval would stop meaning anything. If nobody could, people would go on building a plan they know is wrong. A change request makes the change in the open. Everyone sees the problem and what each option would cost or change, and the decision stays with the initiative.
Raised by the build, or by a person
Section titled “Raised by the build, or by a person”A coding agent building a task raises one when what it builds can’t meet what was agreed. Say an engineer’s Codex is building a switch that turns on single sign-on for all of a customer’s depots at once. It finds that each depot keeps its own sign-in address and certificate. The customer’s IT would still have to set up every depot on its own, which isn’t what the requirement promised. It raises a change request with three options, and names the one it carries on with meanwhile, so the build doesn’t stop for the decision.
- Source. The task it was raised from, the coding agent and whom it works for, and what it found.
- Options. The ways to decide it, each with what it costs.
- Changes in b. What the option in view changes, row by row, here with two new tasks.
- Who chose which option, and when.
You can also propose a change yourself, from the requirement or other row it’s about. Someone in support learns after approval that a customer’s managers also need to see the requests waiting on them. They propose it from the requirement it touches, and the agent writes the options. When the agent judges a new request to be the same problem as one already open, the agent adds it as one more source.
One decision, kept
Section titled “One decision, kept”The owner, or someone who edits the initiative, reads the options and picks one of three ways.
- Choose an option. Its new tasks are added to their slices. The agent updates the requirements and the approach, then the decomposition and the slices to match. It names the request on every change it makes.
- Reject it, and the plan stays. When a coding agent raised it from a slice, that slice gets a task to undo what was built meanwhile and build what was agreed.
- Explore it with the agent first, in the chat, when none of the options is right yet. The agent adds the way you find to the list as one more option.
Until it’s decided, every row the request touches carries its key, so nobody reads a requirement without knowing it may change. Decided requests stay on the initiative, newest first. A new joiner can read why a customer’s depots share one sign-in address.
Requests are decided one at a time. One that depends on another waits until that one is decided. Then the agent reworks it.
Before and after approval
Section titled “Before and after approval”Before approval there are no change requests. What was shaped is changed directly, in the chat. After it, the requirements, the approach and the slices need a change request. So does any piece of the decomposition a started slice rests on.
A change request isn’t a comment or a question. A request waiting on you shows on the initiative’s build, under To do, and in your Decisions. Anyone who can open an approved initiative proposes one.