Publié 765T
The live path is preview, authorize, execute, then verify
You describe the outcome. Flow plans, runs, and reports back with what changed and the element IDs. The gate sits inside that path — it is not a click on every element, and it is not a self-driving modeler.
Cette note est pour l’instant en anglais.
You state the outcome
A useful brief names the document, the result, and the actions the job actually needs — open, inspect, edit, save, export, snapshot. That scoped task is the approval envelope. Flow should not stop the chat to ask for a Yes on every command already inside that envelope.
What the gate actually is
Changes run through a permission level, a dry run, and a structured read-back. The sequence you will see named on the product is preview, authorize, execute, then verify. When the job is done, Flow reports what it changed, with element IDs, so you can check any of it.
- Preview freezes the intended edit before anything writes
- Authorize binds that preview to the task, the document, and the allowed tools
- Execute runs only what that binding named
- Verify reads the model back; a successful API call is not the same as a finished BIM job
What this is not
It is not a chore of approving every single change. It is also not a promise that Flow models a building on its own. If the runtime cannot mint a valid capability, that is a product defect to record — not a reason to bypass the gate, and not a reason to treat the run as unsupervised.