Build Protocol · Decision

Apply rigorous process to decisions that cost money, time, or opportunity—before committing, not after.

Inherits the 8 Iron Rules from build-protocol. Adds 3 decision-specific rules and a 10-step workflow tuned for high-stakes choices.

When to Use

Triggers (any one):

• Decision commits >$1,000 or >1 day of effort
• Decision is hard to reverse (stocks, hardware, vendor contracts, hiring)
• Multiple alternatives with real tradeoffs exist
• Investment, trading, or portfolio questions
• Technology selection, supplier choice, buy-vs-build
• Explicit: "should I buy X", "compare options", "pick a vendor", "选哪个", "怎么选"

Don't use for:

• Reversible, low-cost choices (which coffee to order)
• Pure knowledge production (use build-protocol instead)
• Decisions already made—this is pre-decision, not post-rationalization

Inherits from build-protocol (8 Iron Rules)

Decision-specific 3 New Iron Rules

The Decision Workflow (10 Steps)

Pre-decision (Steps 1–4)

Step 1 — Research: Gather options

• List all candidates (don't anchor on first option)
• Source: web search, product reviews, market data, expert opinions
• Output: options list with brief description of each

Step 2 — Set constraints

• Budget ceiling (hard limit)
• Timeline (when must decision be made / when does it take effect)
• Hard-no's (non-negotiable disqualifiers)
• Risk tolerance (for investments: max drawdown you can stomach)

Step 3 — Fetch real-time data ⚠️ non-skippable

• Stocks: curl "https://stooq.com/q/l/?s=SYMBOL.us&f=sd2t2ohlcv&h&e=csv"
• Crypto: CoinGecko API or Binance spot price
• Products: scrape current listing price (Amazon/retailer)
• Services: current vendor pricing page (not cached / not PDF)
• If real-time data is unavailable → state explicitly, do not substitute document prices

Step 4 — Compare on dimensions (build comparison matrix)

• Define 4–8 scoring dimensions relevant to this decision
• Score each option per dimension (1–5 or weighted %)
• Make tradeoffs explicit; no option should be "best on all dimensions"

Decision (Steps 5–7)

Step 5 — Apply methodology

• Investments: PE ratio (vs sector median), DCF estimate, technical levels (MA50/MA200), catalyst timeline
• Purchases: TCO (total cost of ownership over 3 years), not just sticker price
• Technology/vendor: Gartner-style magic quadrant or weighted decision matrix
• Show your work. If you used PE, show the number. If you used DCF, show the inputs.

Step 6 — Plan B and exit conditions

• Investments: hard stop-loss level, reason to exit (not just price but thesis invalidation trigger)
• Purchases: return policy window, resale value estimate
• Tech/vendor: contract termination terms, migration cost estimate
• Define these before committing, not after things go wrong

Step 7 — Make decision + document rationale

• State the chosen option clearly
• One-paragraph "Why This" (not why the others are bad—why this one fits the constraints)
• One-paragraph "Why Not the Alternatives" (must be honest, not dismissive)
• Date-stamp the decision (facts change; you need to know how old this reasoning is)

Post-decision (Steps 8–10)

Step 8 — Execute with position sizing

• Investments: size = (account risk per trade) ÷ (entry − stop-loss). Never max-leverage on first entry.
• Purchases: confirm budget compliance before checkout
• Tech/vendor: phased rollout if possible; don't migrate 100% on day one

Step 9 — Track P/L daily (not weekly, not monthly)

• Record entry price, current price, unrealized P/L in a daily log
• For non-investment decisions: track KPIs that validate the decision (e.g., tool adoption rate, cost savings vs projection)
• Daily tracking catches thesis-breaking events early; weekly/monthly is too slow

Step 10 — Review and adjust (kill bad bets fast)

• Weekly: is thesis still intact? Did the stop-loss get hit?
• Monthly: compare actual outcome vs pre-decision projection
• If thesis is broken: exit at stop-loss, do not average down hoping it recovers
• Log lessons in a decision postmortem (even for winners—understand why it worked)

The "Sycophancy of Precision" Warning ⚠️

The problem: Writing +12.85% feels more credible than "about +13%". But precision ≠ accuracy. When the underlying data is an estimate or an outdated figure, adding decimal places is misleading—it manufactures false confidence.

How it shows up:

• AI stitches together multi-source data and presents blended numbers as if they're exact
• Historical document prices get reused as if they're current
• Compound calculations give precise outputs from imprecise inputs

The rule:

• Any number derived from estimates → append "(est.)" or "(含估算)"
• Any number from a source >24h old → append the source date
• Round to 2 significant figures when inputs are uncertain; don't carry false precision
• Example: +12.85% (est., based on 3-day average) not just +12.85%

Real-time Data Sources Required

🔴 Never use: Prices from documents, spreadsheets, or chat history. Even a price from yesterday's analysis is stale.

Anti-patterns (Decision-specific)

Gotchas

• Polymarket / prediction market cost basis ≠ current MTM value (look up current contract price before calculating P/L)
• Document prices expire within 24h for liquid assets; within weeks for products
• AI recommendation confidence ≠ data freshness — a confident-sounding AI answer with no live data check is high-risk
• MA/RSI are lagging indicators — they describe past price action, not future movement; use as context, not predictions
• DCF sensitivity is high — small changes to discount rate or terminal growth change the output by 30–50%; always run a range, not a single number
• Position sizing compounds errors — if your entry price is wrong by 5%, your stop-loss distance is wrong too; use real-time price in sizing calculation

References

• references/decision-workflow.md — Full 10-step workflow with per-step checklists
• references/investment-playbook-template.md — Generic investment playbook template (anonymized)
• references/audit-script-decision.sh — Bash script to verify methodology transparency and data freshness

Related Skills

• build-protocol — Parent skill for long-form knowledge production (8 Iron Rules source)
• academic-research-hub — For decisions requiring deep literature review
• feishu-bitable — For tracking decision logs and P/L records in Bitable

Distilled: 2026-04-30 · Inherits: build-protocol v1.1 Validated on: Investment decision audits, technology selection, major purchase comparisons