ICE Reference Guide¶
Intent → Context → Evaluation The universal operating model for solution building across Worksuite.
Unfamiliar term? See the AWE Glossary.
Version: 1.0 | April 2026 | Internal — Confidential
1. Overview¶
ICE is how Worksuite frames any non-trivial problem before it gets built or decided. Every solution, every build, every meaningful decision starts with three questions: what are we trying to achieve (Intent), what's relevant to know (Context), and how will we know we got it right (Evaluation).
That's it. Three components, one page, one shared understanding.
Why ICE exists¶
Traditional product development ran on PRDs — Product Requirements Documents. Ten to twenty pages of features, user stories, acceptance criteria, and edge-case specifications, written by a product manager, consumed by an engineering team, translated into a backlog, implemented by people who never spoke to the customer, tested against criteria that had drifted since the PRD was written, and shipped through a release process designed to manage the risk of all that drift.
Every PRD was a translation artifact. The BSA knew the customer. The product manager translated that knowledge into requirements. The engineer translated requirements into code. The QA engineer translated code behavior into test pass/fail. At each translation, information degraded. By the time something shipped, the customer need and the shipped solution were separated by four handoffs.
ICE eliminates all of that:
- One page, one author, one consumer. The BSA writes the ICE Spec for the TSA who'll build it. They talk face-to-face. No translation layer.
- Outcome, not feature. Intent is the outcome the customer needs — not the screen, button, or API endpoint.
- Testable, not aspirational. Evaluation defines done in measurable terms. "Works well" is not Evaluation. "Renewal decision within 3 hours of report run" is.
- Living, not archival. An ICE Spec is refined in Discuss, stress-tested during Plan, and checked at Verify. It stays relevant because it stays short.
Where ICE shows up¶
| Use case | Who writes | Who consumes | Artifact |
|---|---|---|---|
| Customer Solution Build (CSB) | BSA | TSA (and future BSAs reading the CAP) | ICE Spec inside the CSB (template) |
| Technical Solution Build (TSB) | TSA | Other TSAs, future maintainers | ICE inside the TSB |
| Platform Solution Build (PSB) | TSA(s) | SA Group, CSA | ICE inside the PSB proposal |
| Build Cycle (BC) | TSA | Agent + TSA self-check | Informal ICE (often 3–5 bullets) rolled into the BC plan |
| Non-build decision | Decision STO | D3 participants | ICE framing in the Problem Definition Framework |
ICE is universal. BSAs use it for customer solutions. TSAs use it for platform work. ICs use it to frame decisions before a D3. The shape doesn't change; the scope does.
2. The Three Components¶
2.1 Intent — the outcome, not the feature¶
Purpose: State what success looks like for the customer, platform, or decision. Intent is about outcomes, not implementation.
What good Intent looks like:
"Acme Corp's finance lead can reconcile regional revenue for quarterly planning in under one hour per quarter."
Notice what this doesn't say: nothing about a dropdown, a filter, a UI component, or a database schema. It says what the customer can do when this is done.
What bad Intent looks like:
"Build a region filter dropdown on the quarterly revenue report with CSV export."
This is a feature description, not an outcome. It tells the TSA what to build without saying why. If the TSA finds a better way to achieve the real outcome, feature-framed Intent prevents them from seeing it.
The "so what" test: Read the Intent. If your response is "so what?" or "why does that matter?", the Intent is too narrow. Rewrite until the outcome is obvious.
The length test: Intent is usually one or two sentences. If it's a paragraph, it's trying to be Context too. Split them.
2.2 Context — what's relevant, not everything known¶
Purpose: Give the TSA everything they need to make good decisions, and nothing they don't. Context is ruthlessly edited.
What Context includes:
- Customer state and constraints ("Acme's finance team reviews these reports in the first week of each quarter")
- Relevant prior art ("Similar request came from iMerit last quarter, different structure")
- Technical constraints that shape the approach ("Data is already stored by region in the payment records")
- Timeline pressure ("Next quarter starts in 3 weeks")
- Stakeholder dynamics ("Sarah Chen is the exec sponsor; Lisa Park does the daily workflow")
- Hard constraints ("SOC 2 requirement: region-scoped access must be audit-logged")
What Context does NOT include:
- The full customer history (that's in the CAP)
- Every meeting that happened (not relevant unless it changes the build)
- Information the TSA can retrieve themselves (platform docs, code structure)
- Speculation about what the customer "might want later" (that's scope creep waiting to happen)
- Political commentary ("this customer is always difficult")
The half-page test: Context is usually 5–8 bullets. If Context is over half a page, you're dumping information, not framing it. Edit.
The relevance test: For each bullet in Context, ask: "Would the TSA's approach change if they didn't know this?" If no, cut it.
2.3 Evaluation — how we know it's done¶
Purpose: Define the measurable, testable criteria for done. Evaluation is the contract between BSA and TSA, and the checklist at Verify.
What good Evaluation looks like:
- [ ] Agency admin at BBDO can only see BBDO contractors and payments (verified by cross-agency access test)
- [ ] Existing global admin permissions unchanged (verified against baseline permission set)
- [ ] OMC IT team validates SSO integration still works with new roles
- [ ] Lisa Park confirms the workflow in a live walkthrough
Notice: every criterion is something someone can check. "Verified by test." "Confirmed by Lisa." "Matches baseline." No judgment calls required at Verify.
What bad Evaluation looks like:
- [ ] The feature works well
- [ ] Performance is good
- [ ] Users are happy
- [ ] It's secure
These aren't criteria — they're wishes. None of them can be checked by the TSA or agreed by the BSA. At Verify, "works well" means whatever the verifier wants it to mean.
The testability test: For each Evaluation criterion, ask: "How will the TSA know this passes?" If the answer requires interpretation, rewrite.
The agreement test: BSA and TSA both sign off on Evaluation before Execute starts. If they can't both agree on what done means, Plan isn't done.
3. Who Uses ICE and When¶
3.1 BSA writing a CSB¶
Every CSB has an ICE Spec. The BSA writes it before Discuss, grounded in direct customer conversation. The ICE Spec is the input to DPEV's Discuss phase, where it gets pressure-tested by the TSA.
Typical rhythm:
- Customer conversation — BSA hears the need
- BSA drafts ICE Spec (30–60 minutes, often with Albus assembling prior context)
- BSA reviews with TSA informally, revises if needed
- Discuss meeting — ICE pressure-tested, refined
- Plan phase — Evaluation becomes the basis for acceptance criteria
- Verify — Evaluation is the checklist
3.2 TSA writing a TSB¶
TSAs use ICE for technical builds. The shape is identical, but the audience shifts: the TSA is writing for future TSAs who'll maintain the platform, and for the CSA who's approving the investment.
Technical Intent example:
"The reporting module supports configurable filter dimensions (region, department, date range, custom fields) that any report can define and compose, so new customer filter needs can be met via configuration rather than custom code."
Same structure. Same discipline. Outcome-framed.
3.3 TSA writing a PSB¶
Platform Solution Builds are TSA-initiated. The ICE lives in the PSB proposal and is the basis for the D3 among TSAs and the CSA.
A PSB's ICE has to answer: why is this a platform investment vs. custom work? The Evaluation usually includes both customer-facing outcomes and platform-health criteria.
3.4 ICs framing a decision¶
Any IC facing a non-trivial decision can use ICE to frame the problem before running a D3 or making the call unilaterally. In decision-framing, ICE maps to the Problem Definition Framework:
| ICE component | Problem Definition equivalent |
|---|---|
| Intent | What does solved look like? |
| Context | What's happening? Who's affected? What's the root cause? |
| Evaluation | Observable criteria for "solved" |
ICE and the Problem Definition Framework are the same discipline applied to different artifacts. A well-framed ICE Spec is already most of a D3 prep.
4. The ICE Spec Artifact¶
Where it lives¶
- CSB ICE: Inside the CSB document (template). Not a separate file.
- TSB ICE: Inside the TSB document (template).
- PSB ICE: Inside the PSB proposal.
- Decision ICE: Inside the D3 prep doc.
ICE is not a standalone artifact. It is always embedded in the work product it frames. This is deliberate — ICE lives with the work, not in a separate requirements folder that nobody reads.
Length cap: one page¶
The ICE Spec is one page maximum. If it doesn't fit on one page:
- Intent is too broad. Split the CSB into multiple CSBs.
- Context is an information dump. Edit ruthlessly.
- Evaluation has too many criteria. Consolidate or split scope.
A two-page ICE Spec is a signal, not a style choice. Fix the scope.
Template skeleton¶
## Intent
<!-- One or two sentences. Outcome, not feature. Passes the "so what" test. -->
## Context
<!-- 5-8 bullets. What's relevant to the build, nothing more.
Edit: would the TSA change approach without this bullet? -->
-
-
-
## Evaluation
<!-- Testable criteria. BSA and TSA both agree before Execute.
Every criterion answers "how do we know this passes?" -->
- [ ]
- [ ]
- [ ]
That's the whole template. The structure doesn't change by work product type. Only the content does.
5. ICE's Role in DPEV¶
ICE is the input to DPEV. Each DPEV phase uses ICE differently:
| DPEV phase | What ICE drives |
|---|---|
| Discuss | ICE is the starting point. Participants pressure-test Intent, surface missing Context, and check Evaluation testability. If ICE changes materially in Discuss, the BSA revises it before Plan. |
| Plan | Evaluation becomes the basis for acceptance criteria. Context informs the approach. Intent keeps the TSA anchored when details tempt scope creep. |
| Execute | Intent prevents drift. When the TSA hits a fork ("should I add X?"), the test is: does X serve the Intent? If no, it's out of scope. |
| Verify | Evaluation is the literal checklist. BSA and TSA walk through each criterion. Pass = ship. |
The flow¶
BSA drafts ICE → Discuss (pressure-test) → Plan (Evaluation → acceptance criteria)
↓
Execute
↓
Verify (Evaluation = checklist)
↓
Ship
If any DPEV phase is consistently struggling, look at ICE quality first. Most DPEV failures trace back to weak ICE.
6. ICE and D3¶
ICE is the framing; D3 is the decision. The two work together when:
- BSA and TSA disagree on Intent. ICE was drafted by BSA; TSA thinks the outcome is wrong or too narrow. Run a D3 with the ICE Spec as the prep artifact.
- Two TSAs disagree on Evaluation. Cross-TSB coordination, PSB scope debates. ICE is already the D3 prep.
- Scope creep mid-Execute. The TSA thinks the ICE should be expanded. Pause, run a D3, update the ICE or stay in scope.
Well-framed ICE prevents most D3s. If the BSA writes sharp Intent, the TSA doesn't need to debate the outcome. If Evaluation is testable, Verify isn't a judgment call.
A common pattern: the first time a BSA–TSA pair works together, they run a D3 to calibrate on what "good ICE" looks like. After 3–4 CSBs, the ICE quality is high enough that D3s become rare.
7. What ICE Killed¶
| Old ceremony | What replaced it | Why it died |
|---|---|---|
| PRDs (Product Requirements Documents) | One-page ICE Spec, written by the BSA for the TSA who'll build it. | PRDs were translation artifacts between product and engineering functions that don't exist in AWE. The BSA and TSA talk directly. |
| Backlog tickets written by non-builders | Work enters a BC when the BSA and TSA decide to build it. No queue. | Backlogs were what happened when product people wrote specs for engineers who weren't in the conversation. With no product function, there's no one writing tickets for later. |
| "Requirements gathering" as a discovery phase | ICE written before Discuss. Discuss pressure-tests; it doesn't discover. | Requirements gathering was how product managers avoided committing to an outcome. In AWE, the BSA commits when they write Intent. |
| Acceptance criteria invented during UAT | Evaluation written as part of ICE, agreed before Execute. | UAT-time criteria were a symptom of the PRD→spec→test translation chain. With ICE, the criteria are set upfront and checked throughout. |
| Product managers as translation layer | Direct BSA ↔ TSA communication, grounded in ICE. | Product managers existed to move information between customers and builders. In AWE, the BSA is the customer interface and the TSA is the builder; they speak directly. |
| "We'll know it when we see it" | Evaluation criteria that are literally testable. | Know-it-when-we-see-it is how scope creeps and why projects miss deadlines. Testable criteria force the commitment upfront. |
| Scope documents separate from the work | ICE embedded in the CSB/TSB/PSB, living with the work product. | Separate requirements documents drift from the code. Embedded ICE stays in sync because it's where you're already looking. |
8. Anti-Patterns (What ICE Is NOT)¶
ICE written without the customer¶
For a CSB, the BSA must have a recent, direct customer conversation. ICE written from a BSA's inference about what the customer wants is a requirements document in disguise. If you haven't talked to the customer in the last two weeks, the ICE isn't ready.
Intent that describes a feature¶
❌ "Build a CSV export button on the quarterly report page."
This is what, not why. It tells the TSA to build a button. It doesn't tell them the customer's finance team pastes into spreadsheets to reconcile against their own data. If the TSA realizes mid-build that an API export would be better, feature-framed Intent prevents the pivot.
✅ "Acme's finance lead can reconcile their quarterly revenue against internal totals in under 2 hours, without manual data entry."
Outcome-framed. The CSV button is an implementation choice; the reconciliation workflow is the outcome.
Context as an information dump¶
Eight paragraphs of customer history, platform architecture, prior BCs, and political commentary. The TSA skims it, loses the signal, and builds from the Intent alone. Context should be 5–8 bullets, each of which changes the approach if the TSA didn't know it.
Evaluation that can't be tested¶
❌ "The feature feels fast." ❌ "Users are delighted." ❌ "Performance is acceptable."
These pass Verify only if the verifier wants them to. Replace with:
✅ "Report renders in under 3 seconds with 10K rows." ✅ "Three Acme finance users complete the reconciliation task in a 30-min usability session without asking for help." ✅ "99th percentile request latency < 200ms under 10x current load."
ICE that grows into a PRD¶
An ICE Spec starts at one page. Over three revisions, it grows to three pages with sub-sections, diagrams, edge cases, and a risks appendix. Congratulations — you've rebuilt the PRD. The discipline of one page is load-bearing; if ICE needs more, scope needs less.
Same ICE written three times for similar customers¶
A BSA writes an ICE for Customer A's need. Next quarter, a similar ICE for Customer B. Next quarter, Customer C. This is a signal: the platform should support this natively. A TSA initiates a PSB. (See DPEV Example 2.)
The 3-times rule isn't arbitrary. It's the threshold at which custom work becomes more expensive than platform investment.
Skipping ICE because "we all know what we're building"¶
The team has done this three times. Everyone knows the pattern. Writing ICE feels like overhead. Write it anyway. The ICE takes 15 minutes and prevents the Verify-time argument about what "done" meant. "We all know" is how scope drifts.
ICE as a solo activity¶
The BSA writes ICE alone, sends it to the TSA, and considers Discuss a formality. The TSA reads it, has concerns, doesn't raise them because "the BSA already finalized it." Both ship a compromise neither believes in. ICE is a draft until Discuss; Discuss is where it becomes a contract.
Intent that's too broad¶
❌ "Improve Acme's reporting experience."
This isn't a CSB. It's a CAP-level goal. A single CSB's Intent fits in a 3-day BC or a 3-week TSB. If Intent spans quarters, split it.
Evaluation that punts to the customer¶
❌ "Customer agrees this meets their needs."
This is a blank check. The customer can move the goalposts at Verify. Replace with specific, pre-agreed criteria the customer already signed off on.
9. Worked Examples¶
Example 1: BSA writes an ICE Spec for a customer CSB¶
Situation: Acme Corp's BSA receives a customer request: "We need a quarterly revenue report broken down by region. Our current reporting only shows totals."
ICE draft v1 (BSA, ~20 min):
## Intent
Build a region filter on the quarterly revenue report so Acme can see
revenue by region.
## Context
- Acme asked for this in yesterday's QBR
- Their finance team is frustrated with current reporting
- They have 4 regions
- It's urgent
## Evaluation
- [ ] Report shows revenue by region
- [ ] CSV export works
- [ ] Acme confirms it's useful
Problems with v1: - Intent is feature-framed (region filter) not outcome-framed - Context is thin and missing technical signal - Evaluation isn't testable ("useful" is subjective)
Pressure test in Discuss (15 min):
TSA asks: - "What will Acme's finance team do with this report?" → BSA: "Quarterly planning. They allocate budget by region. Today they reconcile manually against their accounting system — takes ~4 hours per quarter." - "Is this just the quarterly report, or does it apply to other reports?" → BSA: "Just quarterly for now. Monthly and ad-hoc are lower priority." - "Hardcoded 4 regions or configurable?" → BSA: "Hardcoded fine — their regions are stable." - "Acme's 'done' criteria — who signs off?" → BSA: "Their finance lead, Lisa. She does the reconciliation workflow."
ICE v2 (revised post-Discuss):
## Intent
Acme's finance lead can reconcile quarterly revenue by region against
their internal accounting totals in under 30 minutes, replacing the
current ~4 hour manual reconciliation.
## Context
- Acme uses this report in the first week of each quarter for regional
budget allocation
- Data is already stored by region in the payment records — filter is
read-path only, no schema change
- 4 regions, hardcoded to Acme's structure (North, South, EMEA, APAC)
- Finance lead Lisa Park owns the workflow and will sign off
- Next quarter starts 2026-05-01 (16 days)
## Evaluation
- [ ] Quarterly report filters by any of the 4 regions + "All Regions"
- [ ] Filtered totals equal sum of individual region exports (reconciliation
math is correct)
- [ ] CSV export includes region column and respects current filter
- [ ] Lisa Park completes reconciliation in <30 min in a live walkthrough
- [ ] Existing unfiltered report behavior unchanged (regression test)
Why v2 is better: - Intent is outcome-framed (reconciliation time reduction) - Context is signal-dense (timing, data readiness, stakeholder, deadline) - Evaluation is testable (every criterion is something the TSA or BSA can check)
Outcome: BC runs as in DPEV Example 1. Ships in 3 days. Lisa confirms reconciliation in 22 minutes.
Example 2: TSA writes ICE for a PSB's first TSB¶
Situation: TSA Alex recognizes that 3 separate custom filter builds signal a platform need. Initiates the Configurable Report Filters PSB (see DPEV Example 2).
After the D3 agreed on Option B scope (2 filter types first), Alex writes ICE for TSB-1.
ICE for TSB-1: Filter Framework Core
## Intent
The reporting module supports a configurable filter framework that
lets BSAs add region and department filters to any report via
configuration (no TSA involvement required for these two filter types).
Filters compose with each other and export respects active filters.
## Context
- 3 current customers have custom region/department filter implementations
built as one-off BCs (see prior CSBs: Acme, OMC, iMerit)
- Schema currently lacks a filter-dimensions table; needs a migration
(backward-compatible: existing reports unaffected if no filters
configured)
- PSB D3 (2026-04-14) decided: 2 filter types in TSB-1, 2 more in TSB-2
- TSB-2 (Filter UI) depends on TSB-1's API; API contract is the gate
- Performance target: filter evaluation must add <50ms p95 to existing
report latency (current p95: 850ms)
## Evaluation
- [ ] Schema migration applies cleanly to production database (verified
on staging with production data snapshot)
- [ ] New reports/filter-dimensions API endpoints documented and tested
- [ ] Region and department filter types implemented and unit-tested
- [ ] Existing 3 customer reports continue to work unchanged (regression
suite passes)
- [ ] Filter evaluation adds <50ms p95 on 10K-row test dataset
- [ ] TSA Beth (TSB-2 owner) approves the API contract as sufficient
for the UI layer
- [ ] 3 existing custom implementations can be migrated to the new
framework in <1 day each (spot-check on 1 customer during Verify)
Why this works as technical ICE: - Intent frames the platform outcome (BSA-self-serve filters) not the code - Context includes prior D3 decisions, dependencies, and a performance budget - Evaluation is testable at the platform level (schema, API, regression, performance) AND at the consumer level (TSB-2 compatibility, migration feasibility)
Example 3: ICE applied to a non-build decision¶
Situation: Worksuite has ReportsV1 (legacy) and ReportsV2 (current). One customer (Zephyr Corp, $280K ARR) uses a V1-only feature. Question: sunset V1, migrate Zephyr, or build V1's formula-field feature into V2? (Full D3 treatment in D3 Example 3.)
ICE framing for the D3 prep (CSA, ~30 min with Albus):
## Intent
Worksuite's reporting stack is consolidated on V2 within 6 months, with
Zephyr's feature dependencies met natively (not via workaround), and
V1 is fully sunset with no ongoing maintenance cost.
## Context
- V1 maintenance cost: ~2 TSA-days/quarter (~$40K/year loaded cost)
- V2 shipped 9 months ago; sunset was deferred
- V1-V2 feature parity is 100% except formula fields (V1-only, used by Zephyr)
- Zephyr renewal is Q3 2026. Competitor bid exists per BSA.
- 2 other V1 customers have full V2 feature parity — migration is
configuration-only
- Building formula-field support into V2: estimated 2 BCs (6 TSA-days)
- Zephyr's 4 workflows using formula fields are documented
## Evaluation
- [ ] V1 maintenance cost drops to $0/year by 2026-11-01
- [ ] Zephyr's 4 formula-field workflows function identically on V2
- [ ] Zephyr renews in Q3 2026 (no V2 migration friction cited as blocker)
- [ ] 2 other V1 customers migrated to V2 before V1 sunset
- [ ] V1 codebase removed from the repo, platform docs updated
Why ICE works for a non-build decision: - Intent is the desired end-state (consolidated stack, met dependencies, zero maintenance) - Context includes cost data, timeline pressure, and the competitive dynamic - Evaluation is testable — even "renewal happens" is a yes/no outcome
This ICE framing is the D3 prep. Options A–D (per the D3 example) are evaluated against this Intent and Evaluation. The option that best delivers Intent wins.
10. Writing a Good ICE Spec — the checklist¶
Before you send an ICE Spec to Discuss, stress-test it:
Intent: - [ ] States an outcome, not a feature - [ ] Specific: mentions the actor ("Acme's finance lead") and the outcome metric ("under 30 minutes") - [ ] Passes the "so what" test — the value is self-evident - [ ] Fits in 1–2 sentences - [ ] Fits in a single BC or TSB's scope (not a quarterly theme)
Context: - [ ] 5–8 bullets, each of which would change the TSA's approach - [ ] Includes customer/stakeholder state, constraints, deadlines, prior art - [ ] Excludes information the TSA can retrieve themselves - [ ] Fits in half a page
Evaluation: - [ ] Every criterion is testable without interpretation - [ ] Measurable in numbers where possible ("under 3 seconds" not "fast") - [ ] Names the verifier where a person is required ("Lisa Park confirms") - [ ] BSA and TSA agree before Execute starts - [ ] Covers both the happy path and critical regressions
Overall: - [ ] Fits on one page - [ ] Another TSA could pick this up and build from it without asking you - [ ] A BSA/TSA reading it in 6 months still knows why this shipped
11. How Agentic Tooling Accelerates ICE¶
Agentic tooling changes both the speed and quality of ICE.
Drafting¶
| Activity | Agent role |
|---|---|
| Customer context assembly | Agent pulls CAP, recent Granola meetings, Slack threads, prior CSBs into a pre-draft brief |
| Prior art search | Agent surfaces similar ICE from prior CSBs — "we built something like this for Customer X in CSB-042, here's their ICE" |
| Intent drafting | Agent proposes outcome-framed Intent from the customer conversation; BSA edits and owns the phrasing |
| Context curation | Agent lists potentially relevant context; BSA keeps what changes the build |
| Evaluation scaffolding | Agent proposes testable criteria based on the Intent and prior patterns; BSA validates with the customer |
Pressure-testing (Discuss)¶
| Activity | Agent role |
|---|---|
| Missing context detection | Agent flags likely missing Context based on the Intent — "similar CSBs included SSO constraints; is that relevant here?" |
| Testability check | Agent flags Evaluation criteria that aren't measurable and suggests rewrites |
| Scope check | Agent estimates whether the Intent fits in 3 days / 3 weeks and flags if scope seems off |
Maintenance¶
| Activity | Agent role |
|---|---|
| ICE drift detection | Agent flags when code changes significantly diverge from the ICE that initiated them |
| Pattern detection | Agent flags when the same ICE shape is being written for the 3rd time — "PSB opportunity: see CSBs 041, 067, 089" |
| Verify checklist | Agent converts Evaluation criteria into automated tests where possible |
The multiplier effect¶
A BSA drafting ICE from scratch takes 30–60 minutes. A BSA drafting ICE with Albus-assembled context takes 10–20 minutes and produces a sharper draft. Across a BSA's 15–25 CSBs per year, that's 10+ hours of direct time saved — and more importantly, fewer ICE Specs that miss context and require rework at Discuss.
But the bigger lever is pattern detection. An agent that reads every ICE Spec across every BSA can flag PSB opportunities the BSAs individually can't see. This is how the flywheel accelerates: custom work → agent-detected patterns → platform investment → faster custom work.
Quick Reference¶
ICE at a glance¶
| Component | Purpose | Length | "Done" looks like |
|---|---|---|---|
| Intent | Outcome, not feature | 1–2 sentences | Passes the "so what" test |
| Context | What's relevant to the build | 5–8 bullets | Would change the approach if absent |
| Evaluation | Testable criteria for done | 3–7 check boxes | No interpretation required at Verify |
Decision rules¶
- ICE Spec over one page? → Scope is wrong, Context is dumped, or Evaluation is too broad. Fix.
- Intent mentions a UI element or API endpoint? → Rewrite as outcome.
- Evaluation includes "works well" or "feels fast"? → Replace with measurable criteria.
- BSA and TSA can't agree on Evaluation? → Escalate to D3.
- Same ICE written 3 times for similar needs? → PSB signal. See DPEV Example 2.
- ICE draft written without recent customer contact? → Stop. Talk to the customer first.
- ICE disagreement mid-Execute? → Pause. Run a D3. Update the ICE or stay in scope. Never silently expand.
Template — copy-paste starter¶
## Intent
[One or two sentences. What outcome does the customer/platform get?
Not what we build — what can be done after this ships.]
## Context
[5-8 bullets. Each one must change the approach if absent.]
-
-
-
-
-
## Evaluation
[Testable criteria. BSA and TSA both sign off.]
- [ ]
- [ ]
- [ ]
The one-line test¶
ICE is ready if another TSA, reading only this one page and talking to nobody, could start Plan tomorrow and produce a build the BSA would ship.
If any of those — single page, no side conversations, buildable, shippable — fails, the ICE isn't done.
Related frameworks¶
- DPEV — the SDLC. ICE is the input to Discuss; Evaluation is the checklist at Verify.
- D3 — structured decisions. Well-framed ICE prevents most D3s; when D3s happen, ICE is the prep artifact.
- Work Product Templates — where ICE lives: embedded in every CSB, TSB, and PSB.
Document maintained by the CSA. Source of truth for ICE behavior: this doc. Companion to frameworks/dpev-guide.md and frameworks/d3-framework.md.