fdeops 5.1.21 → 5.1.22

package/bin/fde.js

@@ -1773,21 +1773,33 @@ function looksLikePersonName(s) {
 function signerFromLine(text) {
   const t = String(text || '').replace(/^[-*+]\s+/, '').trim()
   if (!t || /\?|\b(?:not|nobody|unclear|maybe|might|whether|could|should|if|unless|pending|unconfirmed)\b/i.test(t)) return ''
+  // A component/budget/release approver is not the engagement's acceptance
+  // signer. Infer only a bare authority statement or explicit outcome/test
+  // sign-off; leave other scope wording in the original note for agent review.
+  const roleWords = text => text.trim().split(/\s+/).every(word => word.match(ROLE_TOKEN)?.[0] === word)
+  const candidate = (match, who, rolePrefix = false) => {
+    if (!match || !looksLikePersonName(who)) return ''
+    const before = t.slice(0, match.index)
+    const after = t.slice(match.index + match[0].length).replace(/\[source:[^\]]*\]/gi, '').trim()
+    if (before.trim() && (!rolePrefix || !roleWords(before))) return ''
+    if (!/^(?:(?:on\s+)?(?:the\s+)?(?:acceptance tests?|(?:customer |delivered )?outcome))?[.!]?$/i.test(after)) return ''
+    return who.trim()
+  }
   // "Priya (VP Eng) signs off" → Priya. "Finance controller (Helena) signs off" → Helena.
   const titled = t.match(new RegExp('\\b' + SIGNER_NAME + '\\s+\\(' + SIGNER_NAME + '\\)\\s+' + SIGNER_VERB + '\\b'))
   if (titled) {
     const before = titled[1].trim()
     const inside = titled[2].trim()
-    if (looksLikePersonName(before) && ROLE_TOKEN.test(inside)) return before
-    if (looksLikePersonName(inside)) return inside
-    if (looksLikePersonName(before)) return before
+    if (looksLikePersonName(before) && roleWords(inside)) return candidate(titled, before)
+    if (roleWords(before) && looksLikePersonName(inside)) return candidate(titled, inside)
+    return ''
   }
   const paren = t.match(new RegExp('\\(' + SIGNER_NAME + '\\)\\s+' + SIGNER_VERB + '\\b'))
-  if (paren && looksLikePersonName(paren[1])) return paren[1].trim()
+  if (paren && looksLikePersonName(paren[1])) return candidate(paren, paren[1], true)
   const named = t.match(new RegExp('\\b' + SIGNER_NAME + '\\s+' + SIGNER_VERB + '\\b'))
   if (!named) return ''
   const who = named[1].trim()
-  return looksLikePersonName(who) ? who : ''
+  return candidate(named, who)
 }
 
 function setSigner(eng, who) {

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.21",
+  "version": "5.1.22",
   "private": true,
   "description": "Thin stdio MCP sink for FDEOps ingest (stage \u2192 propose \u2192 apply). Zero runtime dependencies.",
   "bin": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops",
-  "version": "5.1.21",
+  "version": "5.1.22",
   "description": "Skills for forward deployed engineers across strategy, architecture and engineering. Use individual tasks or @fde coordination; local customer memory supports continuity.",
   "bin": {
     "fdeops": "bin/install.js",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "fdeops",
-  "version": "5.1.21",
+  "version": "5.1.22",
   "description": "Skills for forward deployed engineers across strategy, architecture and engineering. Use individual tasks or @fde coordination; local customer memory supports continuity.",
   "author": {
     "name": "Subash Natarajan",

package/skills/fde/references/pick-three.md

@@ -29,23 +29,23 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | **Dependency** | How many other initiatives are blocked waiting for this? | 0 (standalone) → 5 (critical path for 3+ others) |
 | **Cost of delay** | What happens each week this doesn't ship? | 1 (nothing) → 5 (measurable loss or regulatory exposure) |
 
-**Triage score = Impact + Dependency + Cost of delay** (simple sum, 3-15 range).
+**Triage score = Impact + Dependency + Cost of delay** (simple sum, 2-15 range).
 
 **3. Sort into three lanes:**
 
 | Lane | Score | Action |
 |------|-------|--------|
-| **Now** (max 3) | 11-15 | Active work this phase. FDE and team capacity allocated. |
-| **Next** (max 5) | 7-10 | Sequenced for the following phase. Dependencies tracked but not started. |
-| **Later** (unlimited) | 3-6 | Captured, not committed. Revisit at next triage. |
+| **Now** (max 3) | 11-15 | Proposed active work, subject to actual capacity, dependencies and authority. |
+| **Next** (max 5) | 7-10 | Proposed sequencing; dependencies tracked but not started. |
+| **Later** (unlimited) | 2-6 | Captured, not committed. Revisit at next triage. |
 
-**The cap matters.** "Now" has exactly 3 slots. Not 4, not "3 plus this small one." Discipline is the product.
+**The cap matters.** Three is a maximum, not a quota. Use fewer or zero Now items when capacity, unresolved dependencies or required permissions prevent useful authorized work. Check who is available, effort within the phase and shared bottlenecks; one engineer cannot be allocated to several full-capacity initiatives at once. The score bands are a starting point, not automatic lane assignments: high-scoring blocked work waits, and a lower-scoring prerequisite may come first with an explained rationale. Keep uncertain allocations proposed rather than inventing capacity or approval.
 
 **4. Handle the political override.** When a powerful stakeholder pushes a low-scoring initiative into "Now":
 
-- Show the displacement: "Adding X to Now means Y drops to Next. Y is currently blocking Z and W."
-- Let them choose: "Which of the current three should Y replace?" Making the trade-off visible makes the conversation honest.
-- If they override without trading: log it. `decisions.md`: "Initiative X added to Now without displacement by <who>. Capacity impact: <what slows>."
+- Show the capacity and dependency trade-off. If Now is full for the available team, adding X requires deferring work or an explicitly agreed capacity change; a vacant slot alone is not capacity.
+- Ask the responsible decision-maker to resolve the actual choice, without assuming three items are already active. Record the supplied choice and its source under the existing confirmation rules.
+- An override cannot waive required permissions or create capacity. Keep an unresolved request proposed, with its impact, rather than reporting it as an allocated commitment.
 
 **5. Set the triage cadence.** Triage is not a one-time event:
 
@@ -55,15 +55,15 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | Standard (1-4 weeks) | Weekly | New P0 from sponsor |
 | Programme (months) | Bi-weekly | Quarterly review, team change, market shift |
 
-**6. Communicate the triage result.** The output is not just a priority list - it's a commitment:
+**6. Communicate the triage result.** Distinguish a proposed allocation from an authorized commitment:
 
-> "We're committing to these three initiatives this phase: [A, B, C]. Here's why, here's what they deliver, and here's what's explicitly deferred: [D, E, F, ...]. If priorities change, we re-triage - we don't add without removing."
+> "For the available capacity, I propose [eligible items, or none] this phase. Here's what they deliver, what is blocked or deferred, and which allocation still needs confirmation. Existing agreed work remains agreed; changes need the appropriate decision authority."
 
 ## Artifact
 
-**`decisions.md`** - the triage table with scores, lanes, **and an explicit Kill / Later commitment**. Dated. Updates the same Now/Next/Later plan already uses; do not open a second plan section. Referenced by plan and status.
+**`decisions.md`** - the triage table with scores, lanes, and proposed or agreed deferrals. Keep status and decision sources explicit. Update the same Now/Next/Later section plan already uses under the record-confirmation rules; do not open a second plan section. Standalone work returns the draft without initializing records.
 
-Required closing block (plan will not treat triage as done without it):
+For a recorded triage result, preserve this closing block. A draft may contain pending allocations and deferrals; missing agreement must not be filled with invented acceptance:
 
 ```markdown
 ## Triage - <date>
@@ -75,21 +75,21 @@ Required closing block (plan will not treat triage as done without it):
 ### Kill / defer (not this phase)
 | Initiative | Why not now | Who accepted |
 |------------|-------------|--------------|
-| ... | ... | <name, date> |
+| ... | ... | <pending, or supplied name, date and source> |
 
-Commitment: we ship only Now. Additions require a removal.
+Allocation: <proposed, or agreed with source>. Now contains only work feasible within the stated capacity and authority. Additions require a capacity and dependency check, and displacement when full.
 ```
 
 **`reality.md`** - if triage revealed that the engagement scope is larger than the timeline supports, update the assessment.
 
 ## Checkpoint
 
-Walk the FDE through: the 3 "Now" initiatives and why, the top "Next" items and what triggers their promotion, and the one initiative that will generate the most political pushback for being in "Later." Prepare the FDE for that conversation.
+Walk the FDE through: the proposed or agreed Now items and available capacity, the Next items and what enables their promotion, and any real trade-off requiring a decision. Explain an empty Now lane when applicable; do not fill it to satisfy the title.
 
 ## Principles
 
-- "Now" has 3 slots. Not 4. Discipline is the product.
-- Every addition requires a removal. Visible trade-offs beat invisible overload.
+- Now has at most three items and must fit actual capacity and dependencies.
+- Every addition requires a capacity check; displace work when full rather than silently overloading the team.
 - Triage is recurring, not one-time. The list changes; the discipline doesn't.
 - A logged override protects the FDE. An unlogged override blames them.
 - The initiative everyone wants but nobody will trade for is the one to watch.

package/skills/fde/references/score-use-cases.md

@@ -4,13 +4,15 @@
 
 **Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from poc, load those - they carry forward.
 
-The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
+The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring makes assumptions and trade-offs visible; it does not replace evidence or judgment. These ordinal ratings are a discussion aid, not calibrated estimates of value or a reason to override a hard constraint.
 
 ## Method (you do this work)
 
 **1. List every candidate.** From the brief, from discovery conversations, from the FDE's own observations. Include the ones the customer hasn't said aloud but the codebase implies - a high-churn module with no tests is a candidate even if nobody named it.
 
-**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. If discover already ranked candidates with (Value × Data readiness) / Complexity, reuse that order; this table extends the conversation. Do not invent dimension scores from a thin brief - write `unknown` and ask.
+Before ranking work for the proposed step, identify hard feasibility, access, data-permission and policy constraints. Keep blocked or unverified candidates visible with the affected step, owner or authority gap, and evidence needed to reconsider. A high score cannot make dependent work eligible. An authorized design or evidence check may proceed while implementation is blocked; a sponsor's preference does not grant missing API or data permission.
+
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. Reuse discovery's evidence and rationale, rechecking whether the candidates are eligible for the same next step. Do not invent dimension scores from a thin brief - write `unknown`, return a conditional recommendation and ask only what changes the decision.
 
 | Dimension | 1 | 3 | 5 |
 |-----------|---|---|---|
@@ -27,11 +29,11 @@ Score = (Business value × Urgency × Stakeholder alignment) / (6 - Feasibility)
 ```
 
 Why this formula:
-- **Multiplied numerator** - all three must be present. A high-value problem with no urgency or no sponsor scores low because it won't ship.
+- **Multiplied numerator** - a lower rating reduces the score relative to otherwise identical ratings. Because every scale starts at 1, the formula does not establish that urgency, sponsorship or permission is present; eligibility must be checked separately.
 - **Feasibility inverted** - harder problems get a higher denominator, pulling the score down. A feasibility of 5 (easy) gives denominator 1; feasibility of 1 (hard) gives denominator 5.
 - **Data readiness as multiplier** - for data-dependent use cases (ML, analytics). For pure engineering work, set to 3 (neutral) unless data quality is genuinely a factor.
 
-**4. Rank and present.** Sort by score. Present the top 3 to the FDE and the sponsor:
+**4. Rank and present.** Compare eligible candidates; show up to three useful options and list blocked work separately. If an uncertain input could reverse the order, show the plausible alternative rankings and the smallest permitted check that distinguishes them, with its owner or an explicit ownership gap. Do not hide uncertainty in a precise-looking score or delay independent authorized work while waiting. The following scores illustrate a recommendation, not a commitment:
 
 ```markdown
 | Rank | Use case | Value | Urgency | Feasibility | Data | Alignment | Score | Recommend |
@@ -49,7 +51,7 @@ Why this formula:
 **6. Handle the CEO's pet project.** Sometimes the highest-scoring use case isn't the one the most powerful stakeholder wants. That's information, not a problem:
 
 - Present the scores honestly - the stakeholder sees you're being rigorous, not political.
-- If they override: log it in `decisions.md` as a deliberate choice, note the trade-off, and build what they chose. The FDE who was honest about the trade-off is protected when the override creates problems.
+- If the responsible decision-maker overrides the ranking, preserve the choice, source and trade-off under the existing record-confirmation rules. Check capacity and required permissions before dependent work; an override changes preference, not hard constraints or acceptance authority. An unconfirmed choice remains proposed.
 
 ## Artifact
 
@@ -59,12 +61,12 @@ Why this formula:
 
 ## Checkpoint
 
-Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to poc or plan.
+Walk the FDE through the eligible options, relevant blockers and any uncertainty that could reverse the recommendation. Keep the proposed allocation pending the appropriate decision authority; silence is not approval. Reuse existing authorization when it covers the next step. If evidence is insufficient, recommend a bounded distinguishing check rather than automatically proceeding with the highest score.
 
 ## Principles
 
-- Score replaces opinion. Visible arithmetic beats invisible judgment.
-- All three conditions (value, urgency, alignment) must hold - or the use case won't ship.
+- Scores expose assumptions; evidence and eligible scope govern the recommendation.
+- A numerical advantage cannot override a hard constraint or unknown permission.
 - The technically interesting problem that scores low gets deferred, not pursued.
 - Present the model; let the human decide. If overridden, log the trade-off.
 - A use case with no active sponsor is a research project, not an engagement deliverable.

package/skills/prioritize/.fde-generated.json

@@ -5,7 +5,7 @@
     "SKILL.md": "07e8a3b485762e6b6897472fe4c934cb63ed0240d8258761be445729714d782d",
     "agents/openai.yaml": "3cfc01668b1bc6ec42d429e9730c68fd01520a7d15ea4289dee265e16bcd6b55",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/pick-three.md": "fa5a5f6db94c72c5a1c6419276d0f7c13ff3067ce075a074af020f736fe3fad8",
+    "references/pick-three.md": "c64a04fd0724b28701bbe334f444d0df93da4d858de993e82ccae04e48b66db9",
     "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
   }
 }

package/skills/prioritize/references/pick-three.md

@@ -29,23 +29,23 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | **Dependency** | How many other initiatives are blocked waiting for this? | 0 (standalone) → 5 (critical path for 3+ others) |
 | **Cost of delay** | What happens each week this doesn't ship? | 1 (nothing) → 5 (measurable loss or regulatory exposure) |
 
-**Triage score = Impact + Dependency + Cost of delay** (simple sum, 3-15 range).
+**Triage score = Impact + Dependency + Cost of delay** (simple sum, 2-15 range).
 
 **3. Sort into three lanes:**
 
 | Lane | Score | Action |
 |------|-------|--------|
-| **Now** (max 3) | 11-15 | Active work this phase. FDE and team capacity allocated. |
-| **Next** (max 5) | 7-10 | Sequenced for the following phase. Dependencies tracked but not started. |
-| **Later** (unlimited) | 3-6 | Captured, not committed. Revisit at next triage. |
+| **Now** (max 3) | 11-15 | Proposed active work, subject to actual capacity, dependencies and authority. |
+| **Next** (max 5) | 7-10 | Proposed sequencing; dependencies tracked but not started. |
+| **Later** (unlimited) | 2-6 | Captured, not committed. Revisit at next triage. |
 
-**The cap matters.** "Now" has exactly 3 slots. Not 4, not "3 plus this small one." Discipline is the product.
+**The cap matters.** Three is a maximum, not a quota. Use fewer or zero Now items when capacity, unresolved dependencies or required permissions prevent useful authorized work. Check who is available, effort within the phase and shared bottlenecks; one engineer cannot be allocated to several full-capacity initiatives at once. The score bands are a starting point, not automatic lane assignments: high-scoring blocked work waits, and a lower-scoring prerequisite may come first with an explained rationale. Keep uncertain allocations proposed rather than inventing capacity or approval.
 
 **4. Handle the political override.** When a powerful stakeholder pushes a low-scoring initiative into "Now":
 
-- Show the displacement: "Adding X to Now means Y drops to Next. Y is currently blocking Z and W."
-- Let them choose: "Which of the current three should Y replace?" Making the trade-off visible makes the conversation honest.
-- If they override without trading: log it. `decisions.md`: "Initiative X added to Now without displacement by <who>. Capacity impact: <what slows>."
+- Show the capacity and dependency trade-off. If Now is full for the available team, adding X requires deferring work or an explicitly agreed capacity change; a vacant slot alone is not capacity.
+- Ask the responsible decision-maker to resolve the actual choice, without assuming three items are already active. Record the supplied choice and its source under the existing confirmation rules.
+- An override cannot waive required permissions or create capacity. Keep an unresolved request proposed, with its impact, rather than reporting it as an allocated commitment.
 
 **5. Set the triage cadence.** Triage is not a one-time event:
 
@@ -55,15 +55,15 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | Standard (1-4 weeks) | Weekly | New P0 from sponsor |
 | Programme (months) | Bi-weekly | Quarterly review, team change, market shift |
 
-**6. Communicate the triage result.** The output is not just a priority list - it's a commitment:
+**6. Communicate the triage result.** Distinguish a proposed allocation from an authorized commitment:
 
-> "We're committing to these three initiatives this phase: [A, B, C]. Here's why, here's what they deliver, and here's what's explicitly deferred: [D, E, F, ...]. If priorities change, we re-triage - we don't add without removing."
+> "For the available capacity, I propose [eligible items, or none] this phase. Here's what they deliver, what is blocked or deferred, and which allocation still needs confirmation. Existing agreed work remains agreed; changes need the appropriate decision authority."
 
 ## Artifact
 
-**`decisions.md`** - the triage table with scores, lanes, **and an explicit Kill / Later commitment**. Dated. Updates the same Now/Next/Later plan already uses; do not open a second plan section. Referenced by plan and status.
+**`decisions.md`** - the triage table with scores, lanes, and proposed or agreed deferrals. Keep status and decision sources explicit. Update the same Now/Next/Later section plan already uses under the record-confirmation rules; do not open a second plan section. Standalone work returns the draft without initializing records.
 
-Required closing block (plan will not treat triage as done without it):
+For a recorded triage result, preserve this closing block. A draft may contain pending allocations and deferrals; missing agreement must not be filled with invented acceptance:
 
 ```markdown
 ## Triage - <date>
@@ -75,21 +75,21 @@ Required closing block (plan will not treat triage as done without it):
 ### Kill / defer (not this phase)
 | Initiative | Why not now | Who accepted |
 |------------|-------------|--------------|
-| ... | ... | <name, date> |
+| ... | ... | <pending, or supplied name, date and source> |
 
-Commitment: we ship only Now. Additions require a removal.
+Allocation: <proposed, or agreed with source>. Now contains only work feasible within the stated capacity and authority. Additions require a capacity and dependency check, and displacement when full.
 ```
 
 **`reality.md`** - if triage revealed that the engagement scope is larger than the timeline supports, update the assessment.
 
 ## Checkpoint
 
-Walk the FDE through: the 3 "Now" initiatives and why, the top "Next" items and what triggers their promotion, and the one initiative that will generate the most political pushback for being in "Later." Prepare the FDE for that conversation.
+Walk the FDE through: the proposed or agreed Now items and available capacity, the Next items and what enables their promotion, and any real trade-off requiring a decision. Explain an empty Now lane when applicable; do not fill it to satisfy the title.
 
 ## Principles
 
-- "Now" has 3 slots. Not 4. Discipline is the product.
-- Every addition requires a removal. Visible trade-offs beat invisible overload.
+- Now has at most three items and must fit actual capacity and dependencies.
+- Every addition requires a capacity check; displace work when full rather than silently overloading the team.
 - Triage is recurring, not one-time. The list changes; the discipline doesn't.
 - A logged override protects the FDE. An unlogged override blames them.
 - The initiative everyone wants but nobody will trade for is the one to watch.

package/skills/score-use-cases/.fde-generated.json

@@ -5,7 +5,7 @@
     "SKILL.md": "d3abc46b68361f6d808191b50183d41eec65eac31cba5d53ef1e22a2ccd7b32f",
     "agents/openai.yaml": "8f4af12758edb1a4648bb7917ef4c52eb4eb209a3917ae3e04904cdd5fd4dec0",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/score-use-cases.md": "bb304cf2de26a2df0b9f2a299e3a6b2760ebce15b8b523d9cb4a584cc26038f8",
+    "references/score-use-cases.md": "a8352b0886731a647fdb0305b22eaa83244f367d797e130ceb3271f112886801",
     "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
   }
 }

package/skills/score-use-cases/references/score-use-cases.md

@@ -4,13 +4,15 @@
 
 **Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from poc, load those - they carry forward.
 
-The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
+The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring makes assumptions and trade-offs visible; it does not replace evidence or judgment. These ordinal ratings are a discussion aid, not calibrated estimates of value or a reason to override a hard constraint.
 
 ## Method (you do this work)
 
 **1. List every candidate.** From the brief, from discovery conversations, from the FDE's own observations. Include the ones the customer hasn't said aloud but the codebase implies - a high-churn module with no tests is a candidate even if nobody named it.
 
-**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. If discover already ranked candidates with (Value × Data readiness) / Complexity, reuse that order; this table extends the conversation. Do not invent dimension scores from a thin brief - write `unknown` and ask.
+Before ranking work for the proposed step, identify hard feasibility, access, data-permission and policy constraints. Keep blocked or unverified candidates visible with the affected step, owner or authority gap, and evidence needed to reconsider. A high score cannot make dependent work eligible. An authorized design or evidence check may proceed while implementation is blocked; a sponsor's preference does not grant missing API or data permission.
+
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. Reuse discovery's evidence and rationale, rechecking whether the candidates are eligible for the same next step. Do not invent dimension scores from a thin brief - write `unknown`, return a conditional recommendation and ask only what changes the decision.
 
 | Dimension | 1 | 3 | 5 |
 |-----------|---|---|---|
@@ -27,11 +29,11 @@ Score = (Business value × Urgency × Stakeholder alignment) / (6 - Feasibility)
 ```
 
 Why this formula:
-- **Multiplied numerator** - all three must be present. A high-value problem with no urgency or no sponsor scores low because it won't ship.
+- **Multiplied numerator** - a lower rating reduces the score relative to otherwise identical ratings. Because every scale starts at 1, the formula does not establish that urgency, sponsorship or permission is present; eligibility must be checked separately.
 - **Feasibility inverted** - harder problems get a higher denominator, pulling the score down. A feasibility of 5 (easy) gives denominator 1; feasibility of 1 (hard) gives denominator 5.
 - **Data readiness as multiplier** - for data-dependent use cases (ML, analytics). For pure engineering work, set to 3 (neutral) unless data quality is genuinely a factor.
 
-**4. Rank and present.** Sort by score. Present the top 3 to the FDE and the sponsor:
+**4. Rank and present.** Compare eligible candidates; show up to three useful options and list blocked work separately. If an uncertain input could reverse the order, show the plausible alternative rankings and the smallest permitted check that distinguishes them, with its owner or an explicit ownership gap. Do not hide uncertainty in a precise-looking score or delay independent authorized work while waiting. The following scores illustrate a recommendation, not a commitment:
 
 ```markdown
 | Rank | Use case | Value | Urgency | Feasibility | Data | Alignment | Score | Recommend |
@@ -49,7 +51,7 @@ Why this formula:
 **6. Handle the CEO's pet project.** Sometimes the highest-scoring use case isn't the one the most powerful stakeholder wants. That's information, not a problem:
 
 - Present the scores honestly - the stakeholder sees you're being rigorous, not political.
-- If they override: log it in `decisions.md` as a deliberate choice, note the trade-off, and build what they chose. The FDE who was honest about the trade-off is protected when the override creates problems.
+- If the responsible decision-maker overrides the ranking, preserve the choice, source and trade-off under the existing record-confirmation rules. Check capacity and required permissions before dependent work; an override changes preference, not hard constraints or acceptance authority. An unconfirmed choice remains proposed.
 
 ## Artifact
 
@@ -59,12 +61,12 @@ Why this formula:
 
 ## Checkpoint
 
-Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to poc or plan.
+Walk the FDE through the eligible options, relevant blockers and any uncertainty that could reverse the recommendation. Keep the proposed allocation pending the appropriate decision authority; silence is not approval. Reuse existing authorization when it covers the next step. If evidence is insufficient, recommend a bounded distinguishing check rather than automatically proceeding with the highest score.
 
 ## Principles
 
-- Score replaces opinion. Visible arithmetic beats invisible judgment.
-- All three conditions (value, urgency, alignment) must hold - or the use case won't ship.
+- Scores expose assumptions; evidence and eligible scope govern the recommendation.
+- A numerical advantage cannot override a hard constraint or unknown permission.
 - The technically interesting problem that scores low gets deferred, not pursued.
 - Present the model; let the human decide. If overridden, log the trade-off.
 - A use case with no active sponsor is a research project, not an engagement deliverable.