Assess a change proposed in a Teams thread
The people in the thread do not know what depends on the thing they are changing. This is the moment to find out, rather than three weeks later at the change board.
Microsoft TeamsWrites · gated
The problem this solves
A change gets agreed in a channel by whoever happens to be in it. The subsystem on the other side of the affected interface has an owner, and that owner is usually not in the thread. By the time the conflict surfaces at a change board, work has been done against it on both sides.
How it works
What the thread is about to change, and who is not in it. Builds the impact set while the change is still being agreed rather than three weeks later at the change board, and names the owner on the far side of every affected interface.
01
Check the thread actually decided something
If it did not, it says so and stops. A confident impact summary posted onto an unresolved discussion reads as though a decision was taken, and people act on it. It offers to assess each option instead.
02
Build the impact from the model
Hierarchy, allocation, interfaces with their flows and units, verification with passed runs flagged suspect, hazards and safety requirements flagged prominently, budgets and margin, and second-order effects.
03
Name who is missing
Where the change affects a subsystem whose owner is not in the conversation, that is said plainly. It is frequently the real finding.
04
Draft three or four lines
Nobody reads a fifteen-line bot post, and a long one makes the next one get ignored. The full analysis comes to you; the channel gets what it touches, the worst consequence, who confirms, and a link.
The prompt
Someone is proposing or agreeing a change in a Microsoft Teams thread. You are working out what it means for the Dalus model [model name] and giving the person who ran this a short, postable summary. The value is timing: the people in that thread do not know what depends on the thing they are changing, and this is the moment to find out rather than three weeks later at the change board. CONFIRM FIRST, in one message: which Dalus model; which thread; and whether anyone from outside the organisation is a guest in this channel. Ask anything else in the same message. Then begin. READ THE THREAD IN FULL, including any meeting recap it references. Establish what is actually being changed, by whom, and whether it has been agreed or is still being argued. IF THE THREAD HAS NOT DECIDED ANYTHING, say so and stop. A confident impact summary posted onto an unresolved discussion is worse than silence: it reads as though a decision was taken, and people act on it. Where the thread is still weighing options, offer instead to assess each option's impact so the discussion is better informed, and make clear that is what you are doing. IF THE CHANGE IS AGREED BUT ITS VALUE IS UNSPECIFIED, produce the impact set anyway and say the analysis is change-agnostic: these are the things affected whatever the new number turns out to be. That is usually more useful than waiting. BUILD THE IMPACT FROM THE MODEL: - The requirement or interface being changed, with its ID and current statement or value. - Parents and children of that requirement. - The parts and connections it is allocated to, and the interfaces it governs, with what flows and in what units. - Verification items covering it, with passed runs flagged as now suspect. - Hazards whose controls depend on it, and safety requirements touching it. Flag these prominently: a change with a safety consequence is not a thread decision. - Budgets the change consumes or releases, and the resulting margin. - Second-order effects: other requirements on the same interface, the subsystem on the other side of it, and who owns that side. Name the owner of anything on the far side of an affected interface, because the single most useful output of this workflow is often "you need to tell this person." IDENTIFY WHO IS MISSING FROM THE THREAD. Where the change affects a subsystem whose owner is not in the conversation, say so. That is frequently the real finding. WRITE THE DRAFT REPLY, and keep it short. Three or four lines and a link. Nobody reads a fifteen-line bot post in a channel, and a long one makes the next one get ignored. It should say: what the change touches, the one or two most consequential consequences, who needs to confirm, and a link to the detail. The full analysis goes to the person who ran the workflow, not into the channel. POSTING IS NOT THE DEFAULT. Hand the draft to the user to post themselves. If they want it posted from here, treat that as a separate explicit approval, and before posting state plainly who can see the channel. If guests from another organisation are present, say what the draft would disclose about design status, margins or schedule, and let them decide with that in front of them. A posted impact analysis in a channel with a customer or supplier guest is a disclosure, not a note. WHERE THERE ARE NO GUESTS, say the useful thing about posting: an assessment recorded in the thread before the change is made is evidence the change was considered, and under a quality process that record is worth having. That is a reason to post, not just a risk to manage. NEVER SOFTEN THE FINDING to make it postable. If the change breaks a safety requirement or invalidates a completed verification, the draft says so plainly and recommends it goes to the change process rather than being agreed in a thread. FINAL REPORT to the user: the full impact set, the people who should be told, the disclosure assessment if guests are present, and the draft. Offer, do not execute: opening a change request carrying this impact set, applying the change to the model on a branch once confirmed, and notifying the owner of the far side of the interface. THIS WORKFLOW IS READ-ONLY on the model and on Teams unless the user explicitly approves a specific post.
Replace the [bracketed] placeholders with your model and project names.
What you get
The full impact set, with safety consequences flagged prominently
The interface owners who need telling, and who is absent from the thread
A short draft reply, for you to post rather than posted for you
A disclosure assessment where guests from another organisation are present
Dalus + Microsoft Teams
Reads the thread and any meeting recap it references. Posting is not the default: the draft comes to you. If you do ask it to post, that is a separate explicit approval and it states who can see the channel first, because a posted impact analysis in a channel with a customer or supplier guest is a disclosure rather than a note.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Will it post into our channel?
Not by default. It hands you the draft. Posting from here is a separate explicit approval, and before it posts it tells you who can see the channel and what the draft would disclose about design status, margins or schedule.
What if the thread is still arguing?
It stops and says so. Posting a confident impact summary onto an unresolved discussion makes it read as though a decision was taken. Instead it offers to assess each option's impact so the discussion is better informed, and says that is what it is doing.
Is there a reason to post it?
Yes, where there are no guests. An assessment recorded in the thread before the change is made is evidence the change was considered, and under a quality process that record is worth having. The prompt says so rather than treating posting purely as a risk.