Opportunity Dossier and Next Action

1. The real problem: scattered messages do not equal an opportunity decision

Five messages mention a possible pilot. One is enthusiastic, another says budget is unconfirmed, and the latest asks for a technical brief next Tuesday. A single “Qualified” label loses the evidence, assumptions and action needed to move the work. This lesson builds Opportunity Decision Dossier & Next-Action Ledger v1 so decisions are traceable and optimism is never silently converted into certainty.

2. Lesson ownership boundary

PLN-004 owns the opportunity dossier, not identity resolution and not obligation/deadline lifecycle. It consumes contact_refs and organization_ref from upstream models. If a next action later becomes a business obligation, PLN-005 owns that lifecycle. Keeping this boundary explicit prevents the opportunity record from absorbing every adjacent workflow.

3. Bind every decisive claim to exact sources

A dossier needs exact source_refs. “We are interested” can support interest, but it does not prove budget, decision authority or a win. Each stage change in decision history must point to visible source evidence or a clearly labeled observation. An AI-generated summary is a convenience layer, not the original evidence.

4. What provenance contributes

W3C PROV provides a framework for connecting entities, activities and responsible agents. Here it is used as a provenance boundary: which message/entity informed which decision and which human agent was accountable for the transition. PROV does not define sales stages or MAKNOW opportunity policy.

5. Separate objective, value hypothesis and facts

objective describes what the opportunity is trying to achieve. value_hypothesis is a testable explanation of potential value, not a proven fact. “Faster onboarding may create value” is different from “the customer confirmed a 30% saving.” Keep hypotheses typed as hypotheses until direct evidence exists.

6. A stage requires a visible stage reason

A stage without stage_reason is not auditable. The stage must respond to both present and missing evidence. If the only source supporting the current stage disappears, the evaluator must downgrade or return REVIEW_REQUIRED. Stage and confidence are separate: one can be clear while the other remains weak.

7. Confidence is not a magic probability

Confidence is a design summary of evidence completeness and consistency, not a calibrated statistical probability. It must be explainable: which sources support it, which contradictions reduce it, and which unknowns remain. High confidence without adequate source coverage is invalid.

8. Open questions are part of the evidence model

Open questions expose the uncertainty boundary rather than hiding it. “When will budget be approved?”, “Who is the decision maker?” and “Is the technical brief required for procurement?” should remain in open_questions until evidence resolves them. Each important question should map to a next action, blocker or finite recheck.

9. Exactly one primary next action

An active opportunity should expose exactly one accountable primary action, such as “send the technical brief.” If two actions are both marked primary, sequencing and ownership become ambiguous and the correct state is REVIEW_REQUIRED. Secondary actions may exist, but the ledger keeps one explicit next_action and owner.

10. A due date is optional; due-or-recheck is not

RFC 5545 shows that task representations can carry due and status properties, but MAKNOW does not force every opportunity into a fabricated calendar deadline. If an external procurement decision has no known date, use a finite recheck condition such as a portal event or a scheduled review window instead of inventing urgency.

11. Keep BLOCKED, DEFERRED and NO_ACTION_REQUIRED distinct

BLOCKED means a meaningful action exists but a dependency prevents it. DEFERRED means no executable action is justified now and a recheck trigger is the correct control. NO_ACTION_REQUIRED means current evidence does not justify action; it is not a success state. These states prevent a false “always create a task” rule.

12. Keep decision history append-only

Every transition records timestamp, actor, source refs, previous state, new state and rationale. Do not overwrite history. If the opportunity is closed LOST, preserve closed_reason and its evidence. If later evidence satisfies a declared reopen_trigger, append a new transition and recompute the current state from the new evidence.

13. Worked example: pilot with unconfirmed budget

The messages support interest and a request for a technical brief, but budget remains unknown. Keep the stage at EVALUATING, bind stage_reason to the request/interest messages, use medium confidence, preserve the budget question, and assign “send brief” to a named owner. The bounded decision is ACTIVE_ACTION, not WON.

14. Deterministic failure probes

Four shortcuts must fail: (1) remove the only evidence supporting the current stage → REVIEW_REQUIRED; (2) mark two actions as primary → REVIEW_REQUIRED; (3) due date unknown but a valid recheck event exists → DEFERRED without invented urgency; (4) close as LOST and then add evidence satisfying the reopen trigger → preserve closure history and recompute rather than erasing the past.

15. Transfer: procurement with no deadline

In the changed context, a partner is waiting on an external procurement decision and there is no valid calendar deadline. Do not guess a date. Record blocked_by=external_procurement, use DEFERRED, leave executable next action empty, and bind due_or_recheck to an observable event or finite review date. Rebuild the dossier from the changed evidence rather than copying the baseline decision.