What should a decision explanation contain?

Show the outcome, version, deciding rule, evidence used, evidence that was unavailable or prohibited, confidence band, and the next allowed action. A list of every input is less useful than the one rule that changed the result.

What belongs in a human review queue?

A record belongs when the evidence is present and the rules do not resolve it, when a hard failure stopped the run, or when the consequence exceeds the permitted automation tier. Do not send every low-confidence record to the same queue.

Explaining decisions and designing review queues

A person reviewing a recommendation should be able to answer one question quickly: “What would I need to disagree with?” That requires a short explanation tied to the record, not a transcript of a model call.

The review view

Section	Show	Why it is there
Result	Outcome, state, and version	Names exactly what happened
Deciding rule	The rule or evidence condition that determined it	Gives the reviewer a place to challenge
Evidence	Source, observed time, and kind	Separates fact from inference
Limits	Missing, prohibited, or conflicting evidence	Prevents false certainty
Next step	Allowed action, owner, and deadline	Makes review operational

Do not make a reviewer reconstruct this from field history. Store the explanation beside the recommendation as a versioned result.

Queue design follows the failure

Use separate queues when the owner or remedy differs.

Queue	Entry condition	Owner	First action
Missing evidence	Required input is absent	Data owner	Capture or repair the input
Rules gap	Inputs are present, outcomes do not resolve	Decision owner	Add a rule or approve an exception
Failed run	The decision did not complete	Operator	Retry safely and inspect the error
High consequence	The result would change an external or durable state	Business approver	Preview and approve the action

One “AI review” queue is easy to build and hard to operate. It hides whether the system needs better data, a better contract, or a healthier job.

A compact explanation object

{
  "outcome": "review",
  "state": "needs-review",
  "version": "routing-v1.4",
  "deciding_rule": "stated-need-is-ambiguous",
  "evidence": [{"field": "form_message", "kind": "observed", "source": "form", "observed_at": "2026-08-23"}],
  "limits": ["company_employee_count missing"],
  "next": {"queue": "rules-gap", "owner": "marketing-ops", "due_at": "2026-08-25"}
}

The object is useful in a CRM property set, a custom object, or an external store. Keep the authoritative business fields separate from generated explanation text.

Preserve the human score and AI suggestion

When AI validates a human-owned score, the comparison is the product. Do not let one field alternate between the rep's answer and the model's answer.

A useful component result looks like this:

meddicc-component-comparison.json

{
  "component": "economic_buyer",
  "rep_score": 2,
  "rep_context": "VP Finance owns the budget and approved the purchase path.",
  "ai_suggested_score": 1,
  "ai_confidence": "high",
  "relationship": "ai_lower",
  "rationale": "The captured calls show influence and evaluation leadership, but no explicit purchase authority.",
  "evidence": [
    {
      "source": "call_transcript",
      "observed_at": "2026-08-18",
      "claim": "VP Finance will present the recommendation to the purchasing committee."
    }
  ],
  "missing_evidence": ["Direct confirmation of budget ownership or final purchase authority"],
  "next_question": "What authority can this person exercise without another approver?"
}

The official score remains the rep's. The AI suggestion creates a question the rep can answer, not a value the system can overwrite. If the rep has evidence outside the captured calls, their context becomes an input to the next evaluation. Preserve who wrote it and when.

The AI evaluation should also be able to exist without a rep score. That gives leadership a provisional evidence view when data entry is incomplete without pretending the accountable assessment exists. Once both sides are present, calculate their delta and retain the comparison history.

Confidence belongs below the suggestion

Store overall AI confidence and component confidence separately from the suggested score. Confidence answers how strongly the accessible evidence supports the interpretation. It does not answer who has authority.

Confidence should usually improve as an Opportunity progresses and accumulates relevant evidence. A lower-confidence disagreement may simply name what needs to be captured next. A high-confidence disagreement should make the leadership question more specific, but it still should not replace the rep's score automatically.

Require the AI to name missing evidence. Without that field, a low suggestion can silently mean either “the criterion is not met” or “the system could not see enough to validate it.” Those are different operating conditions.

Review the queue as a system

Each review row needs a stable record link, an age, a reason code, an owner, and a permitted action. At review time, store the final decision separately from the recommendation. At operating review time, group outcomes by queue and reason code. A queue with many new-evidence items needs a trigger change. A queue with many rules-gap items needs contract work.

Give every queue a service contract

A queue is a workflow, even when the interface makes it look like a list. Define its entry condition, priority rule, owner, response target, allowed actions, exit states, and escalation path. Otherwise the system has only moved ambiguity from the model into a view.

Queue field	Example
Entry	Required company match exists, but two authoritative sources disagree
Priority	Renewal within 90 days, then oldest first
Owner	Revenue Operations data steward
Response target	One business day
Allowed actions	Choose source, request evidence, defer with due date
Exit	Resolved, returned for evidence, accepted exception
Escalation	Decision owner after two business days

Do not use “reviewed” as the only completion value. It says that somebody opened the row, not what they decided or whether the underlying record is now safe to use.

Write explanations for disagreement

An explanation is successful when a reviewer can disagree with one identifiable part. Prefer:

Keep and nurture. The company-size rule decided the outcome: 40 employees, observed from the enrichment provider nine days ago, below the approved threshold of 50. The submitted message was reviewed but did not change the hard rule.

Avoid:

Based on a holistic review of the available signals, this lead appears better suited for nurture at this time.

The second sounds polished but gives the reviewer no rule, source, observation time, or counterfactual. It cannot be tested and it encourages free-text overrides.

Test the review experience

Before launch, ask a reviewer to process examples with missing evidence, conflicting evidence, a clear rules gap, a failed run, and a high-consequence action. Observe whether the reviewer can identify the deciding rule, reach the source record, choose only permitted actions, and preserve a reason without asking the builder for help.

Then measure queue age, entries by reason, final outcomes, overrides by direction, and repeated records. A queue that keeps receiving the same case is not providing human judgment; it is compensating for a rule or data defect that should be fixed upstream.

For a scoring validator, add two measures:

Delta between the human and AI component and total scores.
Correlation between low and high score bands and Opportunity progression.

Persistent disagreement begins as a coaching signal. If several capable reps remain adamant that the model is missing something, inspect the system before declaring a behavior problem. The gap may be a missing business-context rule, an uncaptured source, or an ingestion defect. One implementation found that a context-saving experiment was feeding the evaluator truncated transcripts. The score delta surfaced the leak before anybody filed a system complaint.

That is why justification fields are not decorative overhead. They let RevOps and the AI itself distinguish weak evidence from missing evidence. Not every diagnostic field needs to appear on the rep layout. Keep the rep experience to the minimum needed to own and defend the score, while retaining enough structured reasoning behind the scenes to evaluate the evaluator.