Skip to content

Negotiation Intelligence Algorithms

Ciprian-LocalPulse edited this page Jul 31, 2026 · 1 revision

Negotiation Intelligence Algorithms

Part of Pillar IV — Negotiation Intelligence. Consumes Cortex Scoring Model output; feeds Persona Mirror Drafting and Energy Shield Decision Fatigue Model.

Purpose and Naming Note

The original whitepaper names this pillar the "Ghost Negotiation Matrix" and specifies covert tactics — fabricated withdrawn offers, deliberately manipulative delay. This specification implements the legitimate, valuable core of that pillar — data-driven pricing and leverage analysis — under the name Negotiation Intelligence, with the covert mechanisms removed per Design Philosophy. The engineering value of "know your leverage before you respond" does not require deception to work.

What This Pillar Actually Computes

flowchart TD
    A[Commercial thread flagged by Cortex] --> B[Leverage Analysis]
    A --> C[Pricing Analysis]
    B --> D[Leverage Score + factors]
    C --> E[Pricing Recommendation + rationale]
    D --> F[Negotiation Brief]
    E --> F
    F --> G[Presented to Founder — transparent, editable]
    G --> H[Optional: informs Persona draft tone]
Loading

Leverage Analysis

Leverage is scored from real, observable factors — never fabricated ones:

Factor Signal source Direction
Deal urgency for counterparty Deadline language, thread velocity (from Cortex Scoring Model) Higher urgency on their side → more leverage for founder
Alternative options available to founder CRM pipeline data — how many comparable active opportunities exist More alternatives → more leverage for founder
Relationship depth and history Thread history length, past deal outcomes Deeper relationship → typically lower price-sensitivity leverage, higher trust leverage
Price anchoring already in thread Prior numbers mentioned in the conversation Existing anchor constrains the negotiation range
Market rate reference (if configured) Operator-supplied comparable-rate data Deviation from market rate flagged either direction
flowchart LR
    F1[Counterparty urgency] --> Score[Leverage Score]
    F2[Founder's alternatives] --> Score
    F3[Relationship depth] --> Score
    F4[Existing price anchor] --> Score
    F5[Market rate reference] --> Score
    Score --> Brief[Negotiation Brief:<br/>score + every contributing factor listed]
Loading

Pricing Analysis

Pricing recommendations are generated from the founder's own historical pricing data (past deals, accepted vs. rejected quotes) plus any configured market-rate reference — never from a generic, undifferentiated benchmark presented as if it were specific to this founder's business. See Negotiation Pricing and Leverage for the full pricing model.

Transparent Scarcity Signaling

Where the original whitepaper's covert mechanisms manufactured false scarcity ("I have withdrawn the resource allocation"), this specification permits scarcity signaling only when it reflects something real: an actual competing opportunity, an actual capacity constraint from Energy Shield Decision Fatigue Model, or an actual deadline. The system will never generate scarcity language unless it can point to the underlying real evidence it's derived from — this is enforced by the same factual-claim check described in Persona Mirror Drafting.

flowchart TD
    A[Scarcity claim candidate] --> B{Backed by real evidence in AnalysisResult / CRM / Calendar?}
    B -->|Yes| C[Permitted: reference the real constraint]
    B -->|No| D[Rejected: no fabricated scarcity, ever]
Loading

The Negotiation Brief

Every recommendation ships as a brief with visible reasoning, not a bare number:

{
  "thread_id": "",
  "leverage_score": 62,
  "leverage_factors": [
    {"factor": "counterparty_urgency", "contribution": "+18"},
    {"factor": "founder_alternatives", "contribution": "+9"},
    {"factor": "relationship_depth", "contribution": "-4"}
  ],
  "pricing_recommendation": {"suggested": 4200, "range": [3800, 4600], "basis": "historical_close_rate"},
  "scarcity_signal": null
}

This shape mirrors the explainability contract established in Data Schemas Reference — the founder sees exactly what the number is built from and can disagree with any individual factor.

See Also

Clone this wiki locally