Validate decision makers before sending the contract

<context>
I'm about to send the contract for signature on a deal. Before I do, I want to validate the decision makers: confirm the signing authority is current, the buying group roles are correct, and nothing has changed at the prospect that would re-route the contract.

My deal at contract stage:
- Prospect company / domain: [COMPANY]
- Planned signer (name, title): [NAME, TITLE]
- Contract value (annual): [DOLLAR AMOUNT]
- Contract term: [LENGTH]
- Buying group I've been working with (name, role): [LIST]
- Date of last meaningful touch with the signer: [DATE]
- Stage in CRM: [Negotiation / Closing]
</context>

<task>
1. Use Lusha to validate the planned signer:
   - Confirm the signer's current title matches what's on the contract
   - Confirm the signer is still at the prospect company (catches departures that happened during the deal)
   - Check the signer's seniority level against the contract value (a $250K annual contract typically requires VP or higher signing authority; $1M+ typically requires C-suite)
   - Surface the signer's job start date. If they joined recently, their authority may not yet cover this contract size.
2. Validate the buying group roles I've been working with:
   - Confirm each contact's current title matches my notes
   - Flag any contact who has departed, been promoted, or changed roles since the last touch
   - Surface anyone in the buying group whose role change means their position on the contract approval chain has shifted
3. Use Lusha's signals layer to scan the prospect for structural changes since my last meaningful touch:
   - Executive departures (especially anyone in the contract approval chain: CRO, CFO, CSTO, CTO)
   - Leadership hires (anyone new in the approval chain who may want to review)
   - M&A as the acquired party (acquired companies often freeze contracts during integration)
   - Security incidents (may trigger new procurement scrutiny)
   - Major reorganizations (changed reporting lines = changed approval routing)
4. Return a clear pre-close decision:
   - SEND: signer validated, buying group current, no structural changes. Safe to send the contract today.
   - HOLD (verify one thing first): minor issue caught (stale contact info, recent change worth confirming, signer's authority at this dollar amount uncertain). Prescribe the specific verification.
   - HOLD (structural change): significant change at the prospect that materially affects the contract path. Surface what changed and the right next move (re-route the contract, re-validate with new owner, pause for procurement re-check).
5. If the planned signer has departed, surface the verified replacement candidate (using the find-new-champion logic) and recommend re-validation before sending.
</task>

<constraints>
- Validation is binary on each check. The contact is at the company or they aren't, the title matches or it doesn't. Don't soften with "probably still there."
- The signer authority check is approximate (Lusha doesn't return signing limits), but seniority + recent role can flag the obvious mismatches.
- Do not invent contacts, roles, or signals. Surface only what Lusha returns.
- A SEND decision means the contract can go out today. A HOLD decision means specific verification first. Be clear which.
</constraints>

Input: Deal at [Cloud data platform] about to send for signature. Planned signer — Brian R., Chief Financial Officer. Contract value — $480K annual. Contract term — 24 months. Buying group worked with: Keegan R. (SVP Sales Americas), Patrick H. (VP RevOps), Dwarak R. (VP AI Engineering). Last touch with Brian: 11 days ago. CRM stage — Closing.

Output: HOLD — structural change. Two material events have happened at the customer account in the days surrounding the planned send. Below is the real result from running the prompt against the live Lusha connector.

Pre-close decision: HOLD — structural change

The signer is validated and the buying group is current. However, two structural changes in the last 30 days create real risk that the contract will get re-routed if sent today. Recommended hold of 5-7 business days while one verification touch closes the gap.

Signer validation

Signer is fine. The issue is downstream.

Buying group validation

Buying group roles are current. The issue is in the approval chain that touches the contract but isn’t in your touched contacts list.

Structural changes at [Cloud data platform] since last touch

1. New Chief Revenue Officer Jonathan B. — start date March 31, 2026 (CRITICAL for routing)

• Jonathan is approximately 6 weeks into his role. He sits above Keegan R. in the Sales reporting chain. New CROs typically want visibility into active vendor contracts for their team — especially contracts at this dollar tier — during their first 90 days.
• Contract impact: Brian R. (CFO) has signing authority and the contract will technically be valid if signed. But the contract may get held up post-signature in procurement coordination when Jonathan’s office finds out a GTM vendor contract was signed without his pre-briefing. The result is delayed implementation, not delayed contract — but reps who skip the new-CRO briefing often lose the customer’s onboarding momentum.

2. New Chief Security & Trust Officer Mayank U. — start date April 1, 2026 (CRITICAL for procurement gate)

• The CSTO role is brand new at [Cloud data platform]. Mayank’s office is in the process of formalizing security and procurement review processes. Existing vendor contracts going through the current process work fine, but new vendors being signed without coordination with his office risk being re-routed once the new process formalizes.
• Contract impact: A $480K, 24-month contract for a sales productivity platform will almost certainly go through security review at [Cloud data platform]. If the security review happens through the legacy process (pre-Mayank), the deal closes. If Mayank’s office gets involved, the review may extend by 30-45 days.

Prescribed verification before sending

1. Brief Jonathan B. (new CRO) on the contract before sending — 5 business days

• Approach: Coordinate with Keegan R. to make a brief introduction to Jonathan B., framed as “wanted to give you visibility on the GTM stack contract in motion before signature.”
• Outcome you’re protecting: Smooth post-signature onboarding without the new-CRO surprise

2. Confirm with Patrick H. (VP RevOps) which procurement process this contract goes through — 2 business days

• Approach: Quick refresh with Patrick — “is this going through the standard security review or the new CSTO-coordinated process?”
• Outcome you’re protecting: A 30-45 day security review extension if the process changed mid-deal

Decision summary

• Send the contract today: Possible. The signer is valid. But two structural risks at the prospect are unresolved and create real post-signature slip risk.
• Hold 5-7 business days, run the two verification touches, then send: Recommended. Adds a week to the timeline but materially de-risks the close-to-onboard transition.

The verified contact and signal data reused from earlier gallery runs — zero new credits consumed.