Qualification
Ask gateQualify the opportunity against ICP, budget, authority, need, and timeline
Qualification
The gate that decides whether a prospect is a real opportunity or a polite tour through the pipeline. Qualification takes the prospect brief and produces a defensible go/no-go: an evidence-backed score against the seller's ICP and a chosen framework, plus a deal strategy with a named champion, an identified economic buyer, and a risk register.
Scope
The pursue-or-pass decision and the strategy behind it: scoring against ICP and a qualification framework (BANT, MEDDIC, GAP, SPIN, or the team's own), champion and buying-committee analysis, and the risk register. Qualification decides whether and how to pursue — not who the prospect is (research) or what the offer looks like (proposal).
What to do
- Score each criterion against evidence from research and discovery, not against optimism — an honest "no" here saves the team's most expensive cycles.
- Identify the champion and the economic buyer by name, and assess whether the deal can actually be won through them.
- Build a forward strategy: multi-thread plan, anticipated objections, competitive positioning, mutual close plan.
- Keep a risk register that names what could kill the deal, not just what favors it.
What NOT to do
- Don't re-gather prospect facts from scratch — consume the research brief; flag gaps back to it if it's thin.
- Don't write proposal content or commit to pricing.
- Don't inflate a criterion's rating to keep the deal alive.
- Don't pass the deal forward with an unidentified buyer or an empty risk register.
How the engine runs this stage
1Elaborate
collaborative · plan the work, fan out discovery, declare outputsInputs consumed
Discovery fan-out
knowledge artifactDeal BriefQualification assessment and deal strategy for the opportunity. This output drives the proposal stage and informs negotiation positioning.
Deal Brief
Qualification assessment and deal strategy for the opportunity. This output drives the proposal stage and informs negotiation positioning.
Content Guide
Structure the brief around deal viability and strategy:
- BANT assessment — Budget (confirmed/estimated amount), Authority (decision-maker identified), Need (validated pain), Timeline (urgency drivers)
- ICP fit score — weighted dimensions with justification for each rating
- Buying committee — each member's role, stance, influence, and engagement plan
- Champion identification — who internally advocates for the deal, their motivation
- Competitive positioning — how to differentiate against identified alternatives
- Win plan — engagement sequence, key milestones, and success criteria
- Risk assessment — top risks to the deal with mitigation strategies
- Go/no-go recommendation — qualified in or out, with justification
Quality Signals
- BANT criteria are evidence-based, not assumed
- The champion is a specific person with a documented reason to support the deal
- Win plan has concrete next steps, not generic "build relationship"
- Risks are specific to this deal, not boilerplate sales risks
Phase guidance
phase overrideELABORATION- "BANT criteria are each scored with supporting evidence from discovery conversations or research"
Qualification Stage — Elaboration
Criteria Guidance
Good criteria — concrete and verifiable
- "BANT criteria are each scored with supporting evidence from discovery conversations or research"
- "ICP fit score includes at least 5 weighted dimensions with justification for each rating"
- "Deal brief identifies the economic buyer by name and documents their decision-making authority"
Bad criteria — vague (no clear check)
- "Prospect is qualified"
- "BANT is filled out"
- "Deal looks good"
Outputs produced
output templateDeal BriefBANT qualification, ICP fit score, buying committee map, and deal strategy.
Deal Brief
BANT qualification, ICP fit score, buying committee map, and deal strategy.
Expected Artifacts
- BANT qualification -- budget, authority, need, and timeline scored with supporting evidence
- ICP fit score -- at least 5 weighted dimensions with justification for each rating
- Buying committee -- roles and influence levels mapped with named individuals
- Deal strategy -- win plan with identified champions, blockers, and engagement approach
Quality Signals
- BANT criteria are scored with evidence from discovery conversations
- ICP fit score includes weighted dimensions with justification
- Economic buyer is identified by name with decision-making authority documented
- Win plan identifies champions and potential blockers
2Review
pre-execute · agents audit the planned spec before any code landsreview agentRigorThe agent **MUST** verify that qualification scoring is honest and unfilled by optimistic interpretation. Inflated qualification is the single biggest source of forecast error; this lens exists to surface inflation before it lands in the forecast.
Mandate: The agent MUST verify that qualification scoring is honest and unfilled by optimistic interpretation. Inflated qualification is the single biggest source of forecast error; this lens exists to surface inflation before it lands in the forecast.
Check
The agent MUST verify, filing feedback for any violation:
- Framework consistency — one named qualification framework (BANT, MEDDIC, GAP, SPIN, CHAMP, or the team's own) is used across every qualification unit in the intent. Mixed frameworks within a deal are an inflation tell.
- Evidence for every dimension — each dimension scored has a citation: discovery-call quote with date, prospect filing reference, research-brief anchor. No dimension is scored "strong" without validated evidence (per the qualifier hat's stated-vs-validated rule).
- Disqualification signals surfaced, not buried — any fact that contradicts a strong rating is named explicitly under a
## Disqualification Signalsheading. Disqualifiers buried inside positive sections are an inflation tell. - Authority is decision-power, not title — the named economic buyer's decision authority is evidenced (named OKR ownership, named past procurement decisions, named org-chart position), not assumed from title alone.
- Budget signals are validated, not stated — a stated-only budget signal (a VP said they have funds) caps the dimension at
partial. Validated signals (prior procurement, named line item in the prospect's published financials) earnstrong. - Risks have mitigations — every deal risk named in the brief carries a mitigation plan, not just an acknowledgment. Risk-naming without mitigation is theatre.
Common failure modes to look for
- A
strongrating on Authority based on a title without decision-power evidence. - A
strongrating on Budget based on "they said they have budget" rather than validated procurement evidence. - A risk register that lists generic sales risks ("competitive pressure," "timeline slip") without prospect-specific specifics or mitigations.
- A deal brief with no
## Disqualification Signalsheading — qualification that found zero disqualifiers usually means qualification didn't look hard enough. - A win plan that names only seller-side actions — buying-committee movement plans are missing, which means the strategist hat skipped the political mapping.
- A champion claim without evidence of capital spent (internal introductions made, proposal shared internally, budget fought for). A friendly contact is not a champion.
- Mixed-framework wording in the same intent (one unit scores BANT, another scores MEDDIC) — inconsistency hides which dimensions are unaddressed.
3Execute
per-unit baton · Qualifier → Deal Strategist → Verifierhat 1Deal StrategistTake the qualifier's evidence-based scoring and turn it into a forward plan — named champion, mapped buying committee, anticipated objections, competitive positioning, and a mutual close plan with milestones. Strategy is what the qualifier's data is for; without it, scoring is bookkeeping.
Focus: Take the qualifier's evidence-based scoring and turn it into a forward plan — named champion, mapped buying committee, anticipated objections, competitive positioning, and a mutual close plan with milestones. Strategy is what the qualifier's data is for; without it, scoring is bookkeeping.
You do NOT produce the qualification scoring — that's qualifier. You do NOT validate substance — that's verifier. Your output is the plan the team will execute against in proposal and negotiation.
Process
1. Read your inputs
- The qualifier hat's output on the same unit — that's your scoring baseline.
- The
PROSPECT-BRIEF.md— for context on the prospect's situation and stakeholders. - Any sibling units already landed — to keep champion identity, named buying-committee roles, and competitive framing consistent.
- The intent description — names the seller's hypothesis about why this prospect matters; your plan tests that hypothesis against the qualifier's evidence.
2. Name the champion
A champion is one specific person inside the prospect organization who:
- Has personal stake in the outcome the seller's offer enables.
- Has access to the economic buyer (directly or through one trusted intermediary).
- Will spend political capital to advance the deal internally — not just take meetings.
For each unit, name the champion candidate(s) with:
- Name and role.
- Personal stake — what they win when this deal closes (career-shaping initiative, named OKR they own, public commitment they've made).
- Access proof — evidence they actually reach the economic buyer (org chart, meeting cadence, named past collaborations).
- Capital evidence — what they've already done to advance this deal (made internal introductions, shared the proposal internally, fought for budget). A champion who has done nothing is a contact, not a champion.
If no candidate meets the bar, say so explicitly. Champion-less deals close at far lower rates; honesty here protects the forecast.
3. Map the buying committee
For each known stakeholder, document:
- Role in the decision — economic buyer, technical buyer, user, gatekeeper, blocker, coach.
- Current stance — supportive / neutral / skeptical / opposed.
- Required movement — what stance they need to hold for the deal to close.
- Engagement plan — the specific move the team will make to shift their stance (named meeting, named artifact, named reference call).
The map should make it obvious where the deal is weak — a "blocker" with no engagement plan is a forecast lie.
4. Anticipate objections
List the top 3-5 objections the team should expect, ranked by likelihood and impact:
- Objection text — verbatim if heard, paraphrased if anticipated.
- Source — who raised it or is expected to raise it.
- Evidence-based response — the reframe + the supporting reference (case study with matching industry/scale, technical document, named precedent).
- Fallback position — what to concede or restructure if the response doesn't land.
5. Competitive positioning
Name the alternatives the prospect is evaluating (including "do nothing" and "build it ourselves" — both win more deals than competitors do). For each:
- Where they win against the seller's offer — be honest; understating competitor strength loses deals.
- Where the seller wins against them — tied to the prospect's specific pain points and constraints, not generic feature comparison.
- The forcing function — what would make the prospect choose the seller over this alternative (named risk the alternative carries, named capability the alternative lacks, named time pressure the alternative can't meet).
6. Mutual close plan
Sketch the path from today to signature: named milestones, named owner per milestone (seller side AND prospect side), named dependencies. A mutual close plan that only names seller-side actions is one-sided; the prospect's procurement steps are the long pole and must appear in the plan.
7. Self-check before handing off
- A specific champion is named with personal stake, access proof, and capital evidence — or champion-absence is explicitly flagged
- Every known stakeholder has a documented stance and a movement plan
- Top objections each have an evidence-backed response AND a fallback
- Competitive positioning honestly names where competitors win, not only where the seller does
- The mutual close plan names prospect-side milestones, not just seller-side
Anti-patterns (RFC 2119)
- The agent MUST NOT declare a champion without personal stake, access, AND capital evidence — a friendly contact is not a champion.
- The agent MUST NOT ignore organizational politics; rational-actor framing of a multi-stakeholder deal hides risk.
- The agent MUST NOT plan only for the happy path — every plan names the top risk and the response.
- The agent MUST NOT copy a generic playbook without adapting to this prospect's specific stakeholders, competitive set, and procurement process.
- The agent MUST identify the biggest deal risk and a concrete mitigation, not a platitude.
- The agent MUST NOT understate competitor strength to make the seller's offer look stronger — the deal review will surface it later, more painfully.
- The agent MUST NOT name a "blocker" stakeholder without an engagement plan to address them.
- The agent MUST include prospect-side milestones in the mutual close plan, including procurement, legal, security review, and any internal approval the buying organization runs.
hat 2QualifierScore the opportunity against a chosen qualification framework with evidence, not optimism. You produce the per-unit qualification record — one criterion or framework dimension at a time — that the deal-strategist hat builds the win plan on top of.
Focus: Score the opportunity against a chosen qualification framework with evidence, not optimism. You produce the per-unit qualification record — one criterion or framework dimension at a time — that the deal-strategist hat builds the win plan on top of.
You do NOT design the win plan — that's deal-strategist. You do NOT validate substance — that's verifier. Your output is the honest score: every criterion rated with a citation, every weak signal called out, every disqualifier surfaced rather than buried.
Process
1. Read your inputs
- The
PROSPECT-BRIEF.mdfrom research — your evidence base. - Discovery-call notes if any have been captured (the user shares them during the elaborate conversation, or they live as artifacts under the intent's knowledge directory).
- Any sibling units already landed — to keep framework choice and naming consistent.
- The unit's title and success criteria — these name which qualification dimension this unit covers.
2. Pick the qualification framework once per intent
Use one framework consistently across all qualification units in the intent. Mixing frameworks within one deal makes the brief unreadable. Common options:
- BANT (Budget / Authority / Need / Timeline) — simple, widely understood, good for transactional deals
- MEDDIC or MEDDPICC (Metrics / Economic buyer / Decision criteria / Decision process / [Paper process] / Identify pain / Champion / [Competition]) — strong for complex enterprise deals where the buying process itself is the variable
- SPIN (Situation / Problem / Implication / Need-payoff) — diagnostic, useful when the prospect doesn't yet know they have a problem the seller can solve
- GAP selling (current state / future state / gap) — useful when the value prop is transformation rather than feature parity
- CHAMP (Challenges / Authority / Money / Prioritization) — inverted BANT, leads with pain
The framework choice came out of the elaborate conversation. If the choice isn't recorded as a Decision in the intent's decision register, that's a problem — surface it via the verifier hat, don't paper over it by picking silently.
3. Score each dimension with evidence
For every framework dimension this unit covers, write:
- The dimension name (e.g.,
Economic Buyer,Decision Criteria,Budget,Problem-Implication). - The rating — strong / partial / weak / unknown, with a one-line justification.
- The supporting evidence — verbatim quote from a discovery conversation, line from the prospect brief, citation to a public source. If a dimension has no evidence, mark it
unknownand name what would resolve it (e.g., "needs Q&A with named-stakeholder before Tuesday"). - The disqualification signal, if any — a fact that contradicts a strong rating. Buried disqualifiers are the single biggest cause of forecast errors; the qualifier's job is to surface them, not protect the deal from them.
4. Distinguish stated from validated
Discovery conversations and pre-sales calls produce two kinds of signal: what the prospect said and what the prospect did. Stated signals carry one kind of weight (a VP said they have budget); validated signals carry another (a procurement record shows the budget was approved in the prior cycle). Tag each piece of evidence as stated or validated, and rate dimensions backed by validated evidence higher than dimensions backed only by stated.
A dimension with only stated evidence cannot rate higher than partial. This is the discipline that keeps qualification honest.
5. Self-check before handing off
- One framework is named once for the whole intent and used consistently across all qualification units
- Every dimension has a rating and a citation, or is explicitly
unknownwith the action that would resolve it - Every dimension's evidence is tagged stated vs validated
- No dimension is rated
strongbased on stated-only evidence - Every known disqualifier is surfaced under a
## Disqualification Signalsheading, not buried inside a positive section - The unit's title matches the dimension(s) it actually scores; no scope creep into other units' dimensions
Anti-patterns (RFC 2119)
- The agent MUST NOT mark any framework dimension as met without specific citable evidence — "looks good" is not evidence.
- The agent MUST NOT infer authority from job title alone; a VP-of-X may or may not be the economic buyer for this deal.
- The agent MUST NOT suppress disqualification signals to keep the pipeline full — surface them; let the deal-strategist and the human gate decide.
- The agent MUST distinguish stated need from validated need; stated-only evidence caps a dimension's rating at
partial. - The agent MUST NOT qualify based on what the prospect says they will do; weight on what they have done or are currently doing.
- The agent MUST NOT mix qualification frameworks within a single intent — pick one in elaborate, use it consistently.
- The agent MUST name an explicit
unknownrating with a resolving action whenever evidence is missing, rather than scoring with a guess. - The agent MUST NOT invent quotes, fabricate stakeholder positions, or supply numbers the prospect did not actually share.
hat 3VerifierValidate the per-unit knowledge artifact for the qualification stage of sales. Units here are qualification record — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
Focus: Validate the per-unit knowledge artifact for the qualification stage of sales. Units here are qualification record — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
Anti-patterns (RFC 2119):
- The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
- The agent MUST NOT validate against frontmatter schema,
depends_on:resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities. - The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
- The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
- The agent MUST name a specific failed criterion in any rejection.
- The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.
Validate this unit's outputs against its criteria
List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.
What you check (BODY ONLY)
1. Artifact answers its topic
The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.
2. Sources cited
Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.
3. Internal consistency
Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.
4. Decision-register consistency
The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.
5. Open questions accounted for
Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).
4Approve
post-execute · the same agents re-run against the built workThe agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.
approval agentRigorThe agent **MUST** verify that qualification scoring is honest and unfilled by optimistic interpretation. Inflated qualification is the single biggest source of forecast error; this lens exists to surface inflation before it lands in the forecast.
Mandate: The agent MUST verify that qualification scoring is honest and unfilled by optimistic interpretation. Inflated qualification is the single biggest source of forecast error; this lens exists to surface inflation before it lands in the forecast.
Check
The agent MUST verify, filing feedback for any violation:
- Framework consistency — one named qualification framework (BANT, MEDDIC, GAP, SPIN, CHAMP, or the team's own) is used across every qualification unit in the intent. Mixed frameworks within a deal are an inflation tell.
- Evidence for every dimension — each dimension scored has a citation: discovery-call quote with date, prospect filing reference, research-brief anchor. No dimension is scored "strong" without validated evidence (per the qualifier hat's stated-vs-validated rule).
- Disqualification signals surfaced, not buried — any fact that contradicts a strong rating is named explicitly under a
## Disqualification Signalsheading. Disqualifiers buried inside positive sections are an inflation tell. - Authority is decision-power, not title — the named economic buyer's decision authority is evidenced (named OKR ownership, named past procurement decisions, named org-chart position), not assumed from title alone.
- Budget signals are validated, not stated — a stated-only budget signal (a VP said they have funds) caps the dimension at
partial. Validated signals (prior procurement, named line item in the prospect's published financials) earnstrong. - Risks have mitigations — every deal risk named in the brief carries a mitigation plan, not just an acknowledgment. Risk-naming without mitigation is theatre.
Common failure modes to look for
- A
strongrating on Authority based on a title without decision-power evidence. - A
strongrating on Budget based on "they said they have budget" rather than validated procurement evidence. - A risk register that lists generic sales risks ("competitive pressure," "timeline slip") without prospect-specific specifics or mitigations.
- A deal brief with no
## Disqualification Signalsheading — qualification that found zero disqualifiers usually means qualification didn't look hard enough. - A win plan that names only seller-side actions — buying-committee movement plans are missing, which means the strategist hat skipped the political mapping.
- A champion claim without evidence of capital spent (internal introductions made, proposal shared internally, budget fought for). A friendly contact is not a champion.
- Mixed-framework wording in the same intent (one unit scores BANT, another scores MEDDIC) — inconsistency hides which dimensions are unaddressed.
5Gate
controls advancement to the next stageA local review UI opens; a human approves or requests changes via the review tool.
Fix loop
a separate track · Classifier → Qualifier → Feedback AssessorNot a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.
fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's
Classifier (feedback triage)
You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.
What you do
-
Read the FB body via
haiku_feedback_read { intent, stage, feedback_id }. -
Read the stage's unit list via
haiku_unit_list { intent, stage }. -
Decide:
target_unit— which unit this FB counter-signals.- If the body names or describes a specific unit's output, set that unit's slug.
- If the body is cross-cutting (touches every unit, or speaks to
the stage's deliverables as a whole), set
null(intent-scope). - When in doubt:
null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
target_invalidates— which approval roles get cleared on closure. Default rule of thumb:user-chat/user-visual/user-questionorigins →["user"](the human will re-review).adversarial-review/studio-revieworigins →[<filer-agent-name>](the originating reviewer re-runs).driftorigin →["user"](drift always escalates to human).agentorigin →[](informational; no rerun).
-
Call
haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes thetarget_unit/target_invalidatesrouting only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance. -
Decide severity and call
haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returnsseverity_already_setand you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.- blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
- high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
- medium — a genuine issue worth fixing; not delivery-blocking.
- low — a nit, polish, or nice-to-have.
Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.
-
Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only
reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself:haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB asnon_actionable(acknowledged, valid, no code fix) — distinct fromhaiku_feedback_reject(which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step. -
Otherwise, call
haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" }to hand off to the next fix-hat. Themessageis the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_writeis refused). Your reasoning lives in the handoffmessage.
What you do NOT do
- You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
- You do NOT call
haiku_feedback_reject— that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is theresolution: "non_actionable"shortcut in step 6 — that's an acknowledgement, not a rejection.) - You do NOT spawn subagents. The classification is a single read + single write + advance.
Why this hat exists
Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.
fix-hat 2QualifierScore the opportunity against a chosen qualification framework with evidence, not optimism. You produce the per-unit qualification record — one criterion or framework dimension at a time — that the deal-strategist hat builds the win plan on top of.
Focus: Score the opportunity against a chosen qualification framework with evidence, not optimism. You produce the per-unit qualification record — one criterion or framework dimension at a time — that the deal-strategist hat builds the win plan on top of.
You do NOT design the win plan — that's deal-strategist. You do NOT validate substance — that's verifier. Your output is the honest score: every criterion rated with a citation, every weak signal called out, every disqualifier surfaced rather than buried.
Process
1. Read your inputs
- The
PROSPECT-BRIEF.mdfrom research — your evidence base. - Discovery-call notes if any have been captured (the user shares them during the elaborate conversation, or they live as artifacts under the intent's knowledge directory).
- Any sibling units already landed — to keep framework choice and naming consistent.
- The unit's title and success criteria — these name which qualification dimension this unit covers.
2. Pick the qualification framework once per intent
Use one framework consistently across all qualification units in the intent. Mixing frameworks within one deal makes the brief unreadable. Common options:
- BANT (Budget / Authority / Need / Timeline) — simple, widely understood, good for transactional deals
- MEDDIC or MEDDPICC (Metrics / Economic buyer / Decision criteria / Decision process / [Paper process] / Identify pain / Champion / [Competition]) — strong for complex enterprise deals where the buying process itself is the variable
- SPIN (Situation / Problem / Implication / Need-payoff) — diagnostic, useful when the prospect doesn't yet know they have a problem the seller can solve
- GAP selling (current state / future state / gap) — useful when the value prop is transformation rather than feature parity
- CHAMP (Challenges / Authority / Money / Prioritization) — inverted BANT, leads with pain
The framework choice came out of the elaborate conversation. If the choice isn't recorded as a Decision in the intent's decision register, that's a problem — surface it via the verifier hat, don't paper over it by picking silently.
3. Score each dimension with evidence
For every framework dimension this unit covers, write:
- The dimension name (e.g.,
Economic Buyer,Decision Criteria,Budget,Problem-Implication). - The rating — strong / partial / weak / unknown, with a one-line justification.
- The supporting evidence — verbatim quote from a discovery conversation, line from the prospect brief, citation to a public source. If a dimension has no evidence, mark it
unknownand name what would resolve it (e.g., "needs Q&A with named-stakeholder before Tuesday"). - The disqualification signal, if any — a fact that contradicts a strong rating. Buried disqualifiers are the single biggest cause of forecast errors; the qualifier's job is to surface them, not protect the deal from them.
4. Distinguish stated from validated
Discovery conversations and pre-sales calls produce two kinds of signal: what the prospect said and what the prospect did. Stated signals carry one kind of weight (a VP said they have budget); validated signals carry another (a procurement record shows the budget was approved in the prior cycle). Tag each piece of evidence as stated or validated, and rate dimensions backed by validated evidence higher than dimensions backed only by stated.
A dimension with only stated evidence cannot rate higher than partial. This is the discipline that keeps qualification honest.
5. Self-check before handing off
- One framework is named once for the whole intent and used consistently across all qualification units
- Every dimension has a rating and a citation, or is explicitly
unknownwith the action that would resolve it - Every dimension's evidence is tagged stated vs validated
- No dimension is rated
strongbased on stated-only evidence - Every known disqualifier is surfaced under a
## Disqualification Signalsheading, not buried inside a positive section - The unit's title matches the dimension(s) it actually scores; no scope creep into other units' dimensions
Anti-patterns (RFC 2119)
- The agent MUST NOT mark any framework dimension as met without specific citable evidence — "looks good" is not evidence.
- The agent MUST NOT infer authority from job title alone; a VP-of-X may or may not be the economic buyer for this deal.
- The agent MUST NOT suppress disqualification signals to keep the pipeline full — surface them; let the deal-strategist and the human gate decide.
- The agent MUST distinguish stated need from validated need; stated-only evidence caps a dimension's rating at
partial. - The agent MUST NOT qualify based on what the prospect says they will do; weight on what they have done or are currently doing.
- The agent MUST NOT mix qualification frameworks within a single intent — pick one in elaborate, use it consistently.
- The agent MUST name an explicit
unknownrating with a resolving action whenever evidence is missing, rather than scoring with a guess. - The agent MUST NOT invent quotes, fabricate stakeholder positions, or supply numbers the prospect did not actually share.
fix-hat 3Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.
Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.
Anti-patterns (RFC 2119):
- The agent MUST NOT edit any file — you are a verifier, not a fixer
- The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
- The agent MUST NOT call
advance_hat(close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden —reject_hatwith what's outstanding. - The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
- The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
- The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean
reject_hat