Solution-Options Matrix with Weighted Trade-offs

Tier: Core · Hands-on time: ~30 minutes

The options matrix is the artifact clients and ARBs actually read, and AI collapses its production cost from a day to an hour. The risk is not fabrication so much as laundering: a model that both weights the criteria and scores the options has made the decision for you while appearing to be neutral analysis. This playbook splits the roles — you fix the weights from the engagement's real priorities, the AI drafts candidate scores with reasons, and every score you disagree with becomes a conversation, not a silent overwrite.

When to use

• •
  An engagement or design review requires a documented comparison of 2–4 candidate architectures before commitment.
• •
  Stakeholders disagree about direction and a structured trade-off is the honest way to surface why.
• •
  You have a preferred option and need to check yourself against the alternatives you have been discounting.

Skip AI when there is genuinely one viable option — a matrix with a predetermined winner is theater, and reviewers can smell it.

Prerequisites

• An LLM chat assistanta Claude Project preloaded with the engagement's requirements register and constraint register (pb-01, pb-03) gives materially better cells.
• A spreadsheet for the live matrix — the chat drafts; the sheet is the artifact.
• The candidate listarchitectures you consider genuinely viable, sketched at one paragraph each.
• Verified inputs for cost-sensitive cellsif cost is a criterion, pb-05-style verification applies to every number that enters the matrix.

The workflow

1. 1.

   Set the weights first, alone, in the spreadsheet. Before any prompt: list your criteria and assign weights that sum to 100, from the engagement's actual priorities. For Rajesh's Meridian order-status agent, the client's non-negotiables were data residency and time-to-market, so compliance 30, delivery speed 25, run cost 20, ops burden 15, lock-in 10. Write one sentence justifying each weight — the ARB will ask.

2. 2.

   Have AI stress-test the weights — not set them. Paste the weighted criteria: "Argue against my weighting. What would a CFO, a CISO, and the client's ops lead each change, and why? Do not propose a new weighting." Adjust if persuaded; record what changed. The weights are now frozen.

3. 3.

   Draft the matrix with argued cells.

   Copy

   Score three candidate architectures for the Meridian order-status agent
   against my frozen criteria. Candidates:
   A) Managed-agent platform in the client's existing cloud (fully managed
      runtime + managed knowledge base)
   B) Framework-based build (LangGraph-class) on the client's container
      platform, self-managed vector store
   C) Extend the client's existing contact-center vendor's AI add-on
   
   Criteria and weights (FROZEN — do not alter or re-rank):
   compliance/residency 30, delivery speed 25, run cost 20,
   ops burden 15, lock-in 10.
   
   For every cell: score 1–5, then a 2–3 sentence argument citing a
   specific property of the option. Mark any argument that depends on a
   service limit, price, or regional capability with [VERIFY]. Do not
   compute weighted totals — I will do that in the spreadsheet.
   Then list, per option: the strongest argument AGAINST it that a
   competent rival architect would make.
   

4. 4.

   Move scores to the spreadsheet and re-score by hand. Transfer cells one at a time, adjusting any score you disagree with and noting why in a comment. Cells you change are your judgment on record; cells you keep are your endorsement. Either way, every cell is now yours. The spreadsheet computes the totals — models miscount weighted sums often enough that arithmetic stays deterministic.

5. 5.

   Clear the [VERIFY] tags. Every flagged cell gets the pb-05 treatment: vendor doc, today's date, register row. A trade-off matrix that turns on an invented regional limitation is the exact failure this track exists to prevent.

6. 6.

   Pressure-test the conclusion. Two closing prompts: "Which single weight change would flip the ranking?" (sensitivity — if a 5-point shift flips it, say so in the brief), and "Steelman the losing options for one paragraph each" (the ARB pre-read writes itself from this). Then write the recommendation in your own words, with the sensitivity note attached.

Verify before you trust it

• Weights were never touched by the model. Diff the spreadsheet weights against your step-1 originals. Any drift means the analysis restarts — a matrix with negotiated weights is the model's decision, laundered.
• Every [VERIFY] cell has a source and date. No verified-claims register, no matrix. Limits, prices, and regional claims are checked against vendor docs today, not remembered.
• Arithmetic is deterministic. Weighted totals computed by the spreadsheet, not the chat. Recompute one row by hand as a sanity check.
• Scores survive the flip test. Re-read the cells for your preferred option as if a rival wrote them. If every cell conveniently favors your favorite, the drafting anchored you — re-score the two closest options blind, criteria shuffled.

Restricted-environment variant

Candidate architectures reveal client systems and intent. Per the pb-03 register: redact to structural descriptions ("client's existing cloud", "[CONTACT-CENTER-VENDOR]") — matrix logic survives placeholder names intact. For stricter engagements, run drafting on a client-tenancy endpoint (Bedrock/Azure OpenAI in the client's subscription) or local Ollama; the weights step, spreadsheet arithmetic, and verification pass involve no AI and need no variant. Never paste rival-vendor commercial terms received under NDA into any external tool — score those cells from your own reading.