D3 Reference Guide¶

Discuss → Debate → Decide Worksuite's structured decision-making framework.

Unfamiliar term? See the AWE Glossary.

Version: 1.0 | April 2026 | Internal — Confidential

1. Overview¶

D3 is how Worksuite makes non-trivial decisions. Every structured decision follows the same three phases: Discuss the problem to surface perspectives, Debate the options to pressure-test tradeoffs, Decide and commit with an owner and next actions.

That's it. Three phases, one meeting, one decision.

D3 is part of P3: Performance in the 3 Ps operating principles — it's the mechanism that turns Single-Threaded Ownership into durable decisions instead of lingering ambiguity.

Why D3 exists¶

Traditional corporate decision-making was built for a world where consensus felt safer than commitment. Decisions were socialized through a RACI matrix, staffed through a RAPID chart, vetted in a pre-meeting before the meeting, revisited in a follow-up, and ultimately decided by whoever had the stamina to keep scheduling the conversation. By the time something was "decided," the context had shifted, the owner was unclear, and the next action was "let's circle back."

Every layer added latency. Every participant added veto power. Decision quality degraded with every new stakeholder added to the thread.

D3 eliminates all of that:

Every D3 ends with a decision. Not "more research needed." Not "let's table this." A decision, a decider, and a next action.
Ownership is explicit. The STO owns the decision. Participants bring context and recommendations — they don't share accountability.
Preparation is the point. The decision quality is set before the meeting by how well the problem was defined and the options were framed. The meeting is where that prep converges.
Agentic tooling compresses the prep. Albus (and equivalent agents) assembles the context, surfaces prior decisions, and drafts the problem statement. Humans decide; agents prep.

When to use D3¶

Use D3 when:

Two or more ICs disagree on a material tradeoff (scope, resource allocation, technical direction)
A decision affects more than one STO's work product (cross-TSB coordination, PSB investment)
A tradeoff crosses functional boundaries (BSA and TSA disagreeing on a CSB's scope, Services and Platform disagreeing on ownership)
An STO wants to pressure-test a judgment call before committing
A decision has second-order effects the STO wants named out loud

Don't use D3 for:

Unilateral STO decisions within scope. If a TSA decides to refactor a module inside a BC they own, that's not a D3 — it's a build choice.
Trivial operational calls. "Which Slack channel should this go in?" is not a D3.
Status updates. D3 is for deciding, not reporting.
Discovery or exploration. If the problem isn't defined yet, the answer is the Problem Definition Framework, not a D3.
Rubber-stamping a decision that's already made. If the STO already knows the answer and just wants air cover, that's theater — say the decision and move on.

2. The Three Phases¶

2.1 Discuss¶

Purpose: Surface the problem and gather perspectives. No debate yet. No recommendations yet. Just shared understanding.

Who's in the room: - The STO for the decision (usually a BSA, TSA, or function owner) - Participants with direct context (other ICs whose work is affected) - Anyone with relevant domain expertise - An agent (Albus or equivalent) for context retrieval and decision capture

Who's NOT in the room: - Observers with no decision stake - Upward stakeholders "who want visibility" — they get the decision artifact, not a seat - Anyone added to the invite because "they might want to weigh in"

What happens: 1. The STO states the problem as defined (via the Problem Definition Framework) 2. Participants surface facts, constraints, or perspectives the problem definition missed 3. The group agrees on the problem statement before any options are discussed 4. Open questions are named — but not answered yet

Output: A shared problem statement. Every person in the room can articulate what's being decided in one sentence.

Time budget: 10–20 minutes. If Discuss takes longer, the prep was insufficient — the STO should have done this work before the meeting.

The bar for "done": - The problem is clearly stated and agreed - All relevant facts and constraints are on the table - No one is still trying to redefine the question

2.2 Debate¶

Purpose: Pressure-test options, surface tradeoffs, challenge assumptions. This is where disagreement is welcome and expected.

Who leads: The STO, but the STO does not dominate. The STO's job is to hear the strongest version of every option.

What happens: 1. Options are named explicitly (usually 2–4, pre-drafted by the STO or agent) 2. Each option is stress-tested: what are the second-order effects? what breaks? who's affected? does it scale? 3. Assumptions are challenged. "You're assuming X — is that true?" 4. The group explicitly names tradeoffs: what are we giving up with each option?

What Debate is NOT: - Not a consensus-seeking exercise. Disagreement at the end is fine. - Not a vote. D3 is not democratic. - Not a place to re-open the problem definition (that happened in Discuss). - Not a negotiation. If participants are horse-trading scope, the STO has lost the room.

Time budget: 15–30 minutes. If Debate runs long, the options weren't pre-framed well enough.

The bar for "done": - Every material option has been stated and stress-tested - Tradeoffs are named explicitly - The STO has heard the strongest version of each option - Participants have nothing new to add

2.3 Decide¶

Purpose: Make the decision, assign the owner for the next action, close the loop.

Who decides: The STO. Full stop.

What happens: 1. The STO states the decision clearly: "We're going with option B." 2. The STO states the reasoning in one or two sentences (not a speech — a rationale) 3. The next action is named, with an owner and a date 4. The agent (or notetaker) captures the decision in the decision log

What Decide is NOT: - Not a consensus check ("does everyone agree?"). The STO decides; agreement is a bonus. - Not a committee vote. - Not deferred ("let me think about it and get back to you" — that's D3 failure; see §9 Anti-Patterns). - Not a compromise that pleases everyone by satisfying no one.

Time budget: 5–10 minutes.

The bar for "done": - Decision is stated in one sentence - Reasoning is captured in one or two - Next action has an owner and a date - Decision is logged (Slack channel, decision doc, or agent-captured artifact)

When D3 fails to reach a decision¶

Three scenarios, three responses:

STO isn't ready to decide. This means prep was insufficient. Adjourn, reframe, and reschedule — but within 48 hours, not "next quarter."
New information surfaced that changes the problem. Close the D3 without a decision and open a new one with the updated problem statement.
Genuine impasse among peers on a cross-STO decision. Escalate to the CSA (or the appropriate function leader). The CSA is the tiebreaker when peer D3 fails — not an approver who participates in every D3.

3. Roles¶

3.1 The STO (Single Threaded Owner)¶

The STO owns the decision end-to-end. They:

Define the problem before the D3 (using the Problem Definition Framework)
Pre-draft the options and the likely tradeoffs
Facilitate the D3 (or designate a facilitator for scale)
Make the call in Decide
Own the decision artifact and the next action

The STO is accountable for the outcome of the decision, not just the process. Running a clean D3 that produces a bad decision is still a bad decision.

3.2 Participants¶

Participants bring context, options, and thinking. They:

Come prepared (see §5 Prep)
Surface facts, constraints, and tradeoffs
Challenge assumptions
Propose options
Accept the STO's decision and move on

Participants do not share accountability for the decision. Collaboration is expected; accountability is never shared.

3.3 The agent (Albus or equivalent)¶

The agent's role in D3:

Prep: Assemble context (prior decisions, related data, affected parties). Draft the problem statement for STO review. Surface prior art.
During: Capture decisions, next actions, and owners in real time. Flag when Debate is re-opening Discuss.
Post: Write the decision to the decision log. Notify affected parties. Update active-state.md if the decision changes anything tracked.

The agent does not decide. The agent does not advocate. The agent preps, captures, and distributes.

3.4 The tiebreaker¶

When peer D3 genuinely fails:

Within the SA Group (BSAs + TSAs): CSA (Chief Solution Architect) is the tiebreaker
Cross-function (e.g., BSA vs. Services): The function owners escalate; if that fails, COO
Platform direction vs. customer need: CSA, with COO input on strategic implications

Escalation is not failure. Escalation is the system working when peers can't converge. What is failure: escalating without a clean D3 first.

4. Relationship to the 3 Ps¶

D3 sits inside P3: Performance, alongside STO, Solution-Driven Mindset, and Collaborate over Communicate. It's one of four tools that turn focus (P1) and process (P2) into delivered outcomes.

3 Ps layer	D3's role
P1: Prioritization	D3 decides which priorities to resource when there's contention. ICE frames the problem; D3 picks the path.
P2: Process	D3 is the process — the repeatable way of resolving decisions. Standardized agenda, standardized output, standardized capture.
P3: Performance	D3 produces decisions with owners and dates. No decision, no performance.

D3 is also the canonical answer to "Collaborate over Communicate." When alignment is required, run a D3 — not a Slack thread.

5. Prep — Problem Definition Framework¶

The quality of a D3 is set before it starts. A D3 with a sharp problem statement and well-framed options decides in 30 minutes. A D3 without them is an hour of discovery that ends without a decision.

The Problem Definition Framework is the pre-D3 artifact. Four questions, answered before the invite goes out:

Question	What it forces
What's actually happening?	The observable behavior, data, or signal — not the inferred cause
Who's affected?	The specific people, customers, or systems impacted
What's the root cause?	The underlying driver, not the symptom
What does solved look like?	The measurable, time-bound outcome that closes this problem

Only after those four questions have answers does the STO draft options for Debate.

Agent-prepped materials¶

In AWE, agentic tooling compresses the prep:

Agent pulls prior decisions on the same topic from the decision log
Agent surfaces relevant data (customer history, financials, product usage)
Agent drafts the problem statement from the four questions for STO review
Agent identifies stakeholders who should be in the room (and who shouldn't)
Agent drafts 2–4 options based on prior art and context

The STO reviews, edits, and owns. The agent preps; the STO decides.

6. Running a D3¶

Standard agenda¶

D3: [Decision to be made in one sentence]
STO: [Name]
Participants: [Names — each with a specific role/context]
Duration: 30–60 minutes

1. Discuss (10–20 min)
   - Problem statement
   - Key facts and constraints
   - Shared understanding check

2. Debate (15–30 min)
   - Options (pre-drafted, 2–4)
   - Tradeoffs for each
   - Assumption challenges

3. Decide (5–10 min)
   - Decision stated
   - Reasoning captured
   - Next action, owner, date

Time budget¶

Most D3s should fit in 30–45 minutes. If a D3 is scheduled for 60+ minutes, one of three things is true:

The decision is genuinely complex (acceptable, but rare)
The prep was insufficient (common; fix the prep, not the meeting length)
It's not a D3 — it's a working session or a status meeting in disguise

Decision capture¶

Every D3 produces one artifact: the decision record. Minimum content:

What was decided (one sentence)
Why (one to two sentences)
Who owns the next action
When the next action is due
Who was in the room

Decision records live in the appropriate channel (CSB thread, TSB thread, Slack decision channel, or project doc). They do not live in someone's notebook. They do not live only in the agent's memory. They are discoverable.

Owner assignment¶

Every D3 ends with at least one next action. Every next action has exactly one owner and one due date. "We'll all work on this" is not an owner. "Soon" is not a due date.

7. What D3 Killed¶

Old ceremony	What replaced it	Why it died
RACI / RAPID / DACI matrices	STO owns the decision; participants bring context. No chart required.	Responsibility matrices were artifacts of organizations where accountability was diffused across titles. With STO, accountability is a person, not a role on a chart.
Consensus-by-exhaustion	STO decides at the end of Debate, with or without unanimity.	Consensus is not a prerequisite for a good decision. It's a prerequisite for a slow decision.
Pre-meetings before the meeting	Problem Definition Framework + agent-assembled context. The meeting is the meeting.	Pre-meetings existed to compensate for unclear problem statements. Fix the problem statement, not the calendar.
Decision-by-Slack-thread	D3 as a working session. Slack is for bounded updates, not unresolved decisions.	Threads reward the loudest voice and the latest response. D3 rewards the clearest thinking.
"Let's circle back"	Decision at the end of every D3, or an explicit reschedule with a new problem statement.	"Circle back" is how decisions die.
Upward escalation as default	Peer D3 first; escalate to CSA only after peer D3 fails.	Escalating every decision makes leaders into bottlenecks. CSA is a tiebreaker, not an approver.
Status meetings masquerading as decisions	Status is async (Slack, dashboards, `active-state.md`). D3 is for deciding, not reporting.	If a meeting doesn't end in a decision, it shouldn't be called a D3.

8. How D3 Scales¶

D3 is a 30–45 minute working session, but the same pattern applies to decisions at every scale.

8.1 IC-level D3 (the common case)¶

Scope: A single decision affecting 1–2 STOs. BSA vs. TSA disagreement on CSB scope. Two TSAs on PSB approach. Resource contention between BCs.

Cadence: Scheduled as needed. Often same-week. Decision within 48 hours of prep.

8.2 Function-level D3¶

Scope: Decisions affecting multiple STOs within a function. Cross-TSB coordination. Platform direction calls.

Owner: CSA (for SA Group), or function owner (for Services, Finance, etc.).

Cadence: Weekly standing slot for the function is common. Ad-hoc when needed.

8.3 Cross-functional D3¶

Scope: Decisions affecting multiple functions. Platform vs. Services ownership. Finance vs. Sales on contract structure.

Owner: The STO whose work product carries the decision. If ambiguous, the function owner who'll implement first.

Cadence: As needed. Usually scheduled with 48 hours of prep.

8.4 Strategic D3¶

Scope: Decisions affecting the company's Objectives or Big 3 Metrics.

Owner: A WLT member (COO, CEO, CSA depending on domain).

Cadence: Standing strategic D3s (weekly WLT, monthly roadmap) plus ad-hoc.

Across all four, the pattern is the same: problem definition → options → Debate → Decide with owner and date. The scope changes; the mechanism doesn't.

9. Anti-Patterns (What D3 Is NOT)¶

D3 without prep¶

A D3 where the STO opens with "so what's the problem we're trying to solve?" has already failed. Prep is the point. No Problem Definition Framework, no D3.

D3 that's actually a status update¶

If the meeting ends without a decision, it wasn't a D3. It was a working session or a status meeting. Call it what it is — don't inflate status meetings by labeling them D3s.

Debate that doesn't end¶

If Debate is still going 40 minutes in, one of three things is true: the options aren't well-framed, the STO isn't pulling the trigger, or it's actually three decisions stacked into one. Split them.

Consensus theater¶

The STO asks "does everyone agree?" at the end. Participants nod. No one pushed back. The STO declares consensus. A week later, the quiet dissenter re-opens the decision in Slack. The D3 didn't fail because of disagreement — it failed because dissent wasn't surfaced in Debate.

Decider not in the room¶

The STO skips the D3 and sends a deputy. The deputy runs the meeting. The deputy can't actually decide because they aren't the STO. The meeting ends in "let me run this by [STO]." Loop wasted.

Re-litigating a decision¶

A D3 decided a week ago. Someone brings it back up in Slack because they didn't like the outcome. The STO entertains it. Now every decision is provisional. Culture tax: every future D3 is devalued.

Exception: new information that genuinely changes the problem. That's not re-litigation; that's a new D3 with an updated problem statement.

D3 by committee¶

Seven people on the invite. Each one adds 5 minutes of context. The STO can't hear the signal through the noise. Rule of thumb: if the room has more than 5 people, cut it. The extras get the decision artifact.

Upward escalation without peer D3¶

An IC hits a disagreement and immediately pings the CSA. The CSA's answer: "Have you run a D3 with your peers first?" Escalation is the last resort, not the first move. CSA time is a scarce resource.

D3 as therapy¶

The problem is genuinely a people issue (conflict, misalignment, frustration). D3 won't fix it. That's a People Success conversation, not a structured decision. Name it correctly and route it correctly.

D3 without a next action¶

Decision captured. Reasoning captured. Nobody assigned to do anything. Two weeks later: nothing happened. Every D3 produces at least one owned next action — or the decision wasn't actually a decision.

10. Worked Examples¶

Example 1: Two TSAs disputing PSB scope¶

Situation: TSA Alex initiated a PSB for configurable report filters (see DPEV Example 2). TSA Beth agrees on the need but disagrees on scope: Alex wants to support 4 filter types in the first TSB; Beth argues for 2, with the other 2 as a follow-up TSB.

Pre-D3 prep (Alex, 30 minutes):

Problem Definition: - What's happening? Disagreement on TSB-1 scope for the Filter Framework PSB. Alex: 4 filter types. Beth: 2. - Who's affected? 3 customers with queued filter needs (spans all 4 types). The 2 TSAs who'll own TSB-1 and TSB-2. - Root cause? Tradeoff between time-to-first-customer-value (Beth's view: 2 types ships in 2 BCs) vs. avoiding re-work (Alex's view: 4 types shares a schema migration). - Solved looks like? Agreed TSB-1 scope, with both TSAs aligned on the sequence.

Options drafted: - Option A: TSB-1 supports all 4 filter types. 4 BCs. Ships in ~12 days. - Option B: TSB-1 supports 2 types, TSB-2 adds the other 2. Each is 2 BCs. Ships in 6 days + 6 days. - Option C: TSB-1 is framework-only (no filter types), TSB-2 is all 4 types. 3 BCs + 4 BCs. Ships in 9 days + 12 days.

Day 0: D3 runs (40 minutes)

Discuss (10 min): Alex states the problem. Beth agrees with framing. Both confirm 3 customers are waiting.
Debate (20 min):
Option A: Alex argues migration safety. Beth pushes back — "we can batch the schema changes in Option B's TSB-1 and extend in TSB-2 without a new migration." Alex concedes the schema concern is addressable.
Option B: Beth argues fastest customer value. Alex counters: "we ship to 1 customer in 6 days vs. all 3 in 12 days." Beth accepts that tradeoff.
Option C: Framework-only TSB-1 has no customer-facing value for 9 days. Both reject. Cut.
Decide (5 min): Alex (STO for the PSB) decides Option B. Rationale: first customer ships in 6 days; second customer ships 6 days later; the remaining customer waits 12 days total — same as Option A but with earlier wins. Schema extensibility is handled in TSB-1's first BC.
Next action: Alex updates the PSB proposal by EOD. Beth confirms TSB-2 scope in the updated doc by tomorrow EOD.

Decision record (Slack #sa-decisions):

Decision: PSB Filter Framework → TSB-1 supports 2 filter types (region, department); TSB-2 adds 2 more (date range, custom fields). Why: First customer value in 6 days beats complete value in 12. Owner: Alex (PSB update by 2026-04-16 EOD). In the room: Alex, Beth, Chris (data layer TSA), Albus.

Elapsed time: 40 minutes for the D3. ~30 minutes prep. Total: ~70 minutes for a decision that unblocked 3 customer commitments.

Example 2: Resource contention between CSBs¶

Situation: Two BSAs (Dana and Evan) both need TSA Chris's time in the same week. Dana: a renewal-blocking compliance fix for a $400K ARR customer. Evan: a new CSB for a net-new $150K ARR opportunity with a contract-signing deadline.

Pre-D3 prep (the BSA who raised it, Dana, 20 minutes):

Problem Definition: - What's happening? Chris is 100% allocated next week across Dana's compliance fix and Evan's new CSB. One of the two will slip. - Who's affected? Dana's customer (renewal decision on 2026-04-24). Evan's prospect (contract signature on 2026-04-22). Chris. - Root cause? Two time-sensitive customer commitments converged on the only TSA with the relevant domain expertise. - Solved looks like? A sequence that honors both customer commitments, or an explicit decision on which slips and how it's communicated.

Options: - Option A: Dana's fix first (3 days), Evan's CSB starts after. Evan's prospect gets notified of a 3-day slip. - Option B: Evan's CSB first (3 days), Dana's fix after. Dana's customer's renewal decision may be at risk. - Option C: Chris splits time 50/50. Both slip by 2 days. - Option D: Another TSA picks up one. (Prep showed: TSA Beth has the compliance domain context from a prior BC.)

Day 0: D3 runs (30 minutes)

Discuss (10 min): Dana frames. Evan adds: his prospect will walk if slipped — they have a competitive bid in play.
Debate (15 min):
Option A: Evan vetoes — "slipping means losing the deal."
Option B: Dana pushes back — "renewal risk on $400K is bigger than $150K net-new."
Option C: Chris rejects — "50/50 means neither ships clean. Both slip and the quality suffers."
Option D: Beth confirms she can take the compliance fix. Adds 1 day for ramp vs. Chris, but still fits in the renewal window.
Decide (5 min): BSA Dana, as STO of the CSB most at risk (renewal), defers to the BSA-TSA coordination norm: Option D. Beth takes the compliance fix; Chris takes Evan's CSB. Dana owns the customer comm about the TSA change.
Next action: Dana notifies customer today. Beth and Chris confirm capacity with their other CSBs by EOD.

Decision record:

Decision: Beth takes Dana's compliance fix. Chris takes Evan's CSB as planned. Why: Preserves both customer commitments. Beth has prior compliance domain context; ramp cost is 1 day, fits within renewal window. Owner: Dana (customer notification by EOD 2026-04-15); Beth + Chris (capacity confirmation by EOD). In the room: Dana, Evan, Chris, Beth, Albus.

Elapsed time: 30 minutes.

Note: If D3 had failed (both BSAs insisting on Chris), escalation would go to the CSA as tiebreaker, not to Chris's manager. The CSA owns resource allocation disputes across the SA Group.

Example 3: A non-build strategic decision¶

Situation: Worksuite has a legacy reporting module (ReportsV1) still used by 3 customers. Maintenance overhead is ~2 TSA-days per quarter. V2 is feature-complete for 2 of the 3 customers. One customer (Zephyr Corp, $280K ARR) uses a V1-only feature (custom formula fields) that V2 doesn't support. Question: sunset V1, migrate Zephyr, or build formula-field support into V2?

Pre-D3 prep (CSA as STO, 45 minutes with Albus):

Problem Definition: - What's happening? V1 maintenance cost is growing faster than V1 usage is shrinking. 2 TSA-days/quarter is ~$40K/year in loaded cost. Zephyr is the only V1 customer with a V1-exclusive feature dependency. - Who's affected? Zephyr Corp (renewal in Q3). 2 other V1 customers (migration required either way). Platform TSAs maintaining V1. - Root cause? Deferred sunset. V2 shipped 9 months ago; V1 maintenance was never formally retired. - Solved looks like? A decision on V1's lifecycle and a migration plan for Zephyr (or a commitment to build formula-field parity into V2).

Options (Albus-drafted, CSA-reviewed): - Option A: Sunset V1 in 90 days. Migrate Zephyr to V2 with a workaround (CSV export + external formula handling). Save $40K/year. - Option B: Sunset V1 in 6 months. Build formula-field parity into V2 as a TSB (est. 2 BCs = 6 days of TSA time). $40K/year savings starts in month 7. - Option C: Keep V1 indefinitely for Zephyr. Freeze V1 changes; maintenance drops to ~1 day/quarter. $20K/year ongoing cost. - Option D: Do nothing. Re-evaluate next year.

Day 0: D3 runs (50 minutes — complex decision, more participants)

Discuss (15 min): CSA frames. BSA for Zephyr confirms the customer uses formula fields in 4 workflows. Platform lead confirms the maintenance number. Finance confirms the loaded cost calc.
Debate (25 min):
Option A: BSA pushes back hard — "a workaround is a renewal risk; Zephyr has a competitor bid they've been hinting at." CSA weighs this.
Option B: Platform lead: "6 days of TSA time is a real cost, but it's a one-time cost for permanent savings." BSA supports — "formula-field support is something we'd want in V2 long-term anyway."
Option C: CSA rejects — "indefinite parallel-maintenance is how tech debt compounds. We've done this before and regretted it."
Option D: Rejected without discussion.
Decide (10 min): CSA decides Option B. Rationale: one-time TSA investment (6 days) for permanent savings ($40K/year) AND a feature V2 should have anyway AND retains Zephyr renewal. Break-even is year 1.
Next action: CSA opens PSB for V2 formula-field support. BSA coordinates Zephyr migration plan once PSB ships. Platform lead sets V1 sunset date (T+6 months).

Decision record (Slack #strategic-decisions):

Decision: Build formula-field support into V2 (PSB). Sunset V1 6 months after PSB ships. Migrate Zephyr to V2 at sunset. Why: $40K/year permanent savings for a one-time 6-day investment; preserves Zephyr renewal; V2 gets a feature it should have. Owner: CSA (PSB scoping by 2026-04-22); BSA (Zephyr migration plan by T+5mo); Platform lead (V1 sunset comms plan). In the room: CSA, BSA (Zephyr), Platform lead, Finance rep, Albus.

Elapsed time: 50 minutes for the D3. ~45 min prep. Unblocked a decision that had been deferred for 9 months.

11. How Agentic Tooling Accelerates Each Phase¶

Agentic tooling isn't bolted onto D3 — it's baked into prep, capture, and distribution.

Prep¶

Activity	Agent role
Problem definition drafting	Agent drafts answers to the four Problem Definition Framework questions from context, STO reviews and edits
Prior decisions	Agent searches the decision log for related past D3s — "you decided something similar in D3-142 six weeks ago, here's what and why"
Options drafting	Agent drafts 2–4 options based on prior art and the problem statement. STO picks which to take into Debate.
Stakeholder identification	Agent proposes who should be in the room based on the affected work products. STO trims.
Data assembly	Agent pulls relevant data (customer history, financials, product usage, team capacity) into a pre-read

During¶

Activity	Agent role
Decision capture	Agent writes the decision record in real time — what was decided, why, owner, date
Tradeoff tracking	Agent flags when a tradeoff is being assumed but not stated out loud
Phase tracking	Agent flags when Debate is re-opening Discuss ("you're redefining the problem — park it or restart the D3")
Time budget	Agent warns when a phase is running long

Post¶

Activity	Agent role
Decision log write	Agent writes the decision to the canonical log (Slack channel, doc, or structured store)
Distribution	Agent notifies affected parties with the decision and the relevant next actions
`active-state.md` update	Agent updates any live initiatives whose state changes based on the decision
Follow-up tracking	Agent flags to the STO when next-action due dates are approaching or slipping

The multiplier effect¶

A D3 that would have taken 90 minutes without agent prep fits in 40 minutes with it. Over a quarter of ~30 D3s, that's 25 hours of STO time reclaimed. Over a year, it's multiple full weeks.

But the bigger lever is decision quality, not decision speed. Better prep → sharper options → cleaner debate → decisions that don't need re-litigating. The most expensive D3 is the one you have to run twice because the first one missed a tradeoff.

Quick Reference¶

D3 at a glance¶

Phase	Purpose	Time budget	Output
Discuss	Problem statement, shared understanding	10 – 20 min	Agreed problem
Debate	Options, tradeoffs, assumption challenges	15 – 30 min	Pressure-tested options
Decide	Decision, reasoning, next action	5 – 10 min	Decision record

Escalation path¶

Peer D3  →  Function-level D3  →  CSA / Function owner  →  COO / CEO
          (if cross-function)    (as tiebreaker)

CSA is a tiebreaker, not an approver. Skipping to escalation without a peer D3 first is an anti-pattern.

Decision rules¶

Decision wasn't reached? Either prep was insufficient (adjourn, re-prep, reschedule in 48 hrs) or it's a genuine impasse (escalate).
Debate ran 40+ minutes? Options weren't well-framed in prep. Reframe and restart, or split the decision.
More than 5 people in the room? Cut the room. Extras get the decision artifact.
No next action with an owner and date? It wasn't a decision.
Someone re-opening a decided D3 a week later? Unless new information surfaced, the answer is "already decided." Protect the process.
Same disagreement coming up in D3 repeatedly? It's a structural issue, not a decision problem. Route to People Success or the function owner.

The one-line test¶

A D3 is successful if, within 10 minutes of the meeting ending, the decision, the reasoning, the owner, and the date are written somewhere that everyone affected can find.

If any of those four are missing, it wasn't a D3. It was a conversation.

ICE — frames the problem a D3 decides about. Well-framed ICE → shorter, cleaner D3s.
DPEV — the SDLC for builds. When DPEV's Discuss phase surfaces a decision that can't be resolved in the build team, it escalates to a D3.
Worksuite Operating Principles — §P3 Performance — D3 is one of four P3 tools alongside STO, Solution-Driven Mindset, and Collaborate over Communicate.

Document maintained by the CSA. Source of truth for D3 behavior: operating-principles.md §P3. Companion to frameworks/ice-framework.md and frameworks/dpev-guide.md.