Editing your CAB

A generated blueprint is a first draft, and there are two ways to change it: edit it yourself, or ask the CAB agent to. Both routes end in the same place: a review screen where you accept or discard each change before anything is written.

​

The Blueprint Toolbar

Version History appears only once the blueprint has more than one saved versions, so a freshly generated blueprint shows no version history.

​

Sharing a Blueprint Outside the Platform

Share CAB gives a blueprint to people who do not have a BlueGenAI account. A stakeholder, a client, or a colleague on the business side can read the whole document from a link, without signing up and without being added to the project. This is what makes a blueprint usable as a review artifact. A specification is only worth generating if the people who need to agree with it can read it, and most of them are not platform users. Note that this is a different mechanism from inviting someone to the project. An invitation gives a person a role and a sign-in; a share link gives one document to anyone who has the URL. See Collaboration Features.

​

Editing It Yourself

Edit CAB turns the blueprint into a form. After a few seconds the panel title gains an Editing pill and the toolbar becomes Review with AI, Save Changes, and a close control. The editor knows the blueprint’s structure. You are editing fields, not a document. Click any value to change it. Every list ends with a labelled control for adding an item: + Add acceptance criteria, + Add field, + Add role. Hovering an item offers controls to insert a sibling or remove it. Removals are pending until you save. A removed item stays on screen struck through, so you can see what you are about to lose.

​

One Edit, Start to Finish

Notice the count. One added role produced fourteen further suggestions. Adding a role means deciding what it can reach, which screens mention it, and which stories belong to it, and the review works those out rather than leaving you to find them. That is the review earning its cost; see Reviewing changes below.

​

Asking the Agent Instead

The BlueGenAI CAB Agent tab beside CAB Configuration takes requests in plain language. Its composer reads Ask anything about your CAB, or request changes.... Requests that work: One request can change several sections. A single rule request produced six changes across user stories, the data model, three screens, and the rules section; the agent works out what else the change implies rather than editing only what you named.

​

Reviewing Changes

Both routes land here. Hand edits go through it when you select Review with AI; agent changes go through it automatically. The review looks at your edits, not only at its own suggestions. It reads what you changed, checks it against the rest of the blueprint, and can propose corrections to your wording or to anything your change has knock-on effects for. Running it is a second opinion on your work as much as a way of getting the agent to do some. Each change is labelled by where it came from: Modifications show a WAS row and a NOW row; additions show what is being added. Agent changes carry a one-line reason, your own do not. Selecting a change scrolls the blueprint to it and outlines it, so you see it in context.

​

Deciding What to Keep

Accept or discard each change with the controls on its card. Nothing is applied until you use the toolbar. Discard All drops everything and writes nothing. It does not create a version.

​

Version History

Saving creates a version. Open the clock button to see them. Each entry is a timestamp: no author, no description, no summary. The current version sits at the top, and selecting an older one previews it without restoring.

​

What Is Recorded, and What Is Not

This distinction matters if anyone ever asks you who changed what. While a change is under review, attribution is complete. Every proposed change is marked as yours or the agent’s. Each accept or reject is recorded against a named person with their email address and the time they decided. The agent’s suggestions move through a tracked lifecycle from queued to resolved. Once a change is applied, none of that travels with the blueprint. The document has no edited marker, no record of who edited it, and no per-section history. Reading a finished blueprint tells you what it says, not which parts a person rewrote. Version history records when, not who; versions are named by timestamp, and the save operation is not given a user identity. So the review process is auditable; the finished document is not self-describing. If your organisation needs a change record, capture it during review rather than expecting to reconstruct it afterwards.

​

Working with Other People

Only one person can edit a blueprint at a time. The platform holds a lock while a review is running or awaiting a decision, and checks that the version you started from is still current before applying anything.

​

Your Next Step

A corrected blueprint is what everything downstream is built from.