cross-system-renewal-qa

name

cross-system-renewal-qa

description

Use when answering renewal-risk questions that need BOTH the document knowledge graph (graphrag: QBRs, calls, account plans, deals, competitors, concerns) AND structured business data (Neocarta + BigQuery: ARR, usage, tickets, subscriptions) — e.g. ARR at risk, competitive threats, usage decline, champion moves, renewal timing, or anything asking for a dollar figure or percentage. Do not answer from graphrag alone when the question needs a number that only lives in BigQuery.

Cross-System Renewal Q&A

Questions in this category need both data sources — neither one alone is sufficient, and it's easy to answer confidently from just one and miss that the other was needed:

• graphrag (neo4j-graphrag_* tools): the document knowledge graph — QBRs, call notes, account plans, deals, competitors, concerns, releases. Answers "what was raised, by whom, in which document, is it resolved, who's the champion."
• Neocarta + BigQuery (neocarta_* + bigquery_* tools): structured business data — ARR, usage, tickets, subscriptions, contract terms. Answers "how much, how many, when." Use neocarta_* tools first to find which BigQuery table/column has what you need, then query BigQuery directly for the actual figures.

Before writing an answer to a question like this, use at least one tool from each group. If you're about to answer and haven't called a neocarta_* or bigquery_* tool yet, stop — check whether the question asks for a number (ARR, usage %, a date, a count). If it does, that number lives in BigQuery, not in the documents, and the answer is incomplete without it. Likewise, if you've only queried BigQuery/Neocarta, check whether the question needs document context (what was actually said in a QBR, who's mentioned by name) that only graphrag has.

On the graphrag side, prefer Cypher over fulltext/vector search

The documents have already been extracted into a structured entity graph — Account, Person, Concern, Deal, Competitor, Release nodes connected by RAISED, EVALUATING, CHAMPION_OF, WORKS_AT, MOVED_FROM, LOST_TO, LOST_BECAUSE, RESOLVES relationships. These questions are almost always relationship-traversal questions ("which accounts raised an unresolved concern," "did a champion who left resurface elsewhere"), and the graph already encodes the answer directly — you don't need to re-derive it by guessing keyword variants over raw chunk text.

1. Start with get_neo4j_schema_and_indexes to see the actual labels, relationship types, and indexes available — don't assume, confirm.
2. Answer with read_neo4j_cypher / search_cypher_query against that structured graph first. E.g. MATCH (a:Account)-[:RAISED]->(c:Concern) WHERE NOT (c)<-[:RESOLVES]-(:Release) RETURN a, c directly answers "unresolved concerns," in one query, with no ambiguity.
3. Only fall back to fulltext_search/vector_search when Cypher genuinely can't get you there — e.g. you need the exact wording of a quote, or something that plausibly wasn't captured as a structured entity at all. Don't reach for full-text search as the default way to explore the graph; it's a fallback, not the primary method.

If you notice yourself calling fulltext_search more than once or twice for the same question, stop and check the schema again — that's usually a sign the answer was already one Cypher query away.