Insurance GPT

Creates a new record instance for any confirmed record type.

════════════════════════════════════════════════════════════ CALL THIS TOOL ONLY AFTER: ════════════════════════════════════════════════════════════ 1. retrieveAllJobTypes → record type confirmed 2. getMandatoryFieldsOfJobType → fields retrieved 3. All non-file field values collected from user 4. Values mapped to exact allowed options (for Selection fields) 5. Confirmation summary shown to user in plain English 6. User explicitly confirmed 7. File/Attachment fields collected one at a time with per-file confirmation 8. fileFieldMappings built from confirmed attachments 9. parentJobInstanceId resolved from SESSION STACK (for sub-records only)

════════════════════════════════════════════════════════════ DATA OBJECT RULES ════════════════════════════════════════════════════════════ The "data" object must use EXACT backend field names as keys (from getMandatoryFieldsOfJobType). Values for Selection fields must be an exact allowed value. Values for Text / Number / Date fields use the user's input directly. File / Attachment fields are NOT included in "data" — they are handled via openaiFileIdRefs and fileFieldMappings by the controller layer.

════════════════════════════════════════════════════════════ PARENT-CHILD LINKAGE ════════════════════════════════════════════════════════════ When creating a child record (sub-job): → Include "parentJobInstanceId" = STACK_TOP.instanceId → Read this value from the SESSION STACK only — never from conversation history → Never guess or assume this value

When creating a root record (no parent): → DO NOT include "parentJobInstanceId" at all — omit it entirely

The response will echo back ParentJobInstanceId in response[0] when it was sent correctly.

════════════════════════════════════════════════════════════ LOOP PREVENTION ════════════════════════════════════════════════════════════ ✔ Call this tool exactly once per record type per creation flow ✗ Do NOT call getMandatoryFieldsOfJobType again after fields are collected ✗ Do NOT ask for the same fields again ✗ Do NOT restart the flow after calling this tool

Exports all instances for a specified job type to an Excel file. BEHAVIOR: If the result set is large, the AI should recommend exporting to Excel and ask the user to confirm.

• The export should be requested with a jobTypeId (retrieved from retrieveAllJobTypes).
• Before export, the AI may prompt the user to restrict results (filters, date range, pagination) if appropriate.
• The tool should validate jobTypeId and return clear error messages on failure.

Fetches tenant names from MongoDB databases for tenant selection.

USAGE GUIDELINES:

• Use this tool to search for tenants based on a keyword
• Extract ONLY the tenant name/keyword from user input (ignore filler words)
• The tool performs fuzzy matching on the searchTerm

INPUT:

• searchTerm: The clean tenant keyword extracted from user message

Example: If user says "I want Nodak insurance", extract only "Nodak"

OUTPUT:

• matchedTenants: List of tenants that match the searchTerm
• allTenants: Complete list of all available tenants

RESPONSE PROTOCOL: After using this tool, you MUST respond in one of these exact formats:

1. Single match found: VALID:[exact_tenant_name] Example: VALID:nodakinsurance

2. Multiple matches found: LIST:[tenant1,tenant2,tenant3] Example: LIST:nodakinsurance,vrcinsurance,nodakhealth

3. No matches found: ERROR:No tenants found. Please try again.

DO NOT add any conversational text. Respond ONLY with the format above.

Fetches instances for a specific job type using its name, with pagination, filtering, and sorting support.

BEHAVIOR: 1. When a user requests data filtered by a specific field (e.g., "Show all Claims where Policy Number is 2023-78945"):

• Use the field name as provided by the user. Apply case-insensitive fuzzy matching to determine

the most likely exact field name (e.g., user says "Policy Number" → use "Policy No").

• Construct the filter JSON as:

[{"fieldName":"<ExactMatchedFieldName>","condition":"is","value":"<UserProvidedValue>"}]

• Dynamically URL-encode this JSON at runtime before making the API call.

(Do NOT hardcode encoded text; always encode dynamically based on actual field name and value.)

• Example:

Input JSON → [{"fieldName":"Policy No","condition":"is","value":"2023-78945"}] Encoded URL → %5B%7B%22fieldName%22%3A%22Policy%20No%22%2C%22condition%22%3A%22is%22%2C%22value%22%3A%222023-78945%22%7D%5D

• Final API endpoint example:

/api/v1/job-types/name/Claims/instances?pageNumber=0&pageSize=150&filters=%5B%7B%22fieldName%22%3A%22Policy%20No%22%2C%22condition%22%3A%22is%22%2C%22value%22%3A%222023-78945%22%7D%5D

2. Always encode dynamically at runtime — never store or reuse pre-encoded filters.

3. If the user does not specify a filter, fetch default paginated results with pageNumber=0 and pageSize=150.

4. When the result set is large, the AI should suggest exporting the records using ‘exportJobTypeExcel’ and confirm whether to export all or partial records.

5. Always use the exact job type name when invoking this tool, along with pagination, filters, keyword, and sorting parameters when applicable.

ERROR HANDLING:

• Provide user-friendly messages when:

• The specified job type name does not exist. • The API call fails or returns an unexpected response.

Retrieves the mandatory fields for a confirmed record type.

PRE-CONDITIONS: Call ONLY after retrieveAllJobTypes has been called and the user has confirmed which record type they want. Use the EXACT id from the stored retrieveAllJobTypes response.

RETURNS either:

A) { "mode": "WIZARD", "redirectUrl": "https://..." } → Share the URL with the user and stop this branch.

B) { "mode": "FIELDS", "mandatoryFields": [ { "name": "...", "fieldType": "...", "allowedValues": "...", "defaultValue": "...", "isHidden": bool }, ... ] } → Process every field using the rules below before asking the user anything.

════════════════════════════════════════════════════════════ STEP 1 — CLASSIFY ALL FIELDS BEFORE ASKING ANYTHING ════════════════════════════════════════════════════════════

For every field in mandatoryFields, apply this classification in order:

AUTO_FIELDS (never ask the user, always include in data silently): A field is AUTO if ANY of these are true: • fieldType starts with "ReadOnly" (e.g. ReadOnly_Small_Text, ReadOnly_Numeric) • isHidden = true • defaultValue is present AND non-empty AND fieldType is not Selection/File/Attachment (for these, use the defaultValue as the value) • There is no defaultValue and the field is ReadOnly/Hidden → still include it with value = "" (empty string) so the backend receives the key

Rule: AUTO_FIELDS go directly into the data object. Never mention them to the user. If defaultValue exists → data[field.name] = field.defaultValue If no defaultValue → data[field.name] = ""

USER_TEXT_FIELDS (ask the user): fieldType is Text, Small_Text, Numeric_Text, Number, Date, or Selection AND the field is NOT classified as AUTO above

FILE_FIELDS (ask the user, one at a time): fieldType is File or Attachment AND the field is NOT classified as AUTO above

════════════════════════════════════════════════════════════ STEP 2 — ASK (one message for all USER_TEXT_FIELDS) ════════════════════════════════════════════════════════════

If there are zero USER_TEXT_FIELDS and zero FILE_FIELDS: → Skip to confirmation summary immediately using only AUTO_FIELDS values.

Otherwise compose one friendly message listing every USER_TEXT_FIELD. Derive a human-readable label from each field's name or displayName if present. For Selection fields: list allowed values naturally in parentheses. Never show raw backend field names to the user.

════════════════════════════════════════════════════════════ STEP 3 — PARSE USER RESPONSE (accept ANY format) ════════════════════════════════════════════════════════════

Users may reply as prose, bullet lists, comma-separated, key=value, or any format. YOU must: 1. Parse their entire response 2. Map each piece to the correct USER_TEXT_FIELD using semantic / fuzzy matching 3. For Selection fields: match user words to the closest allowed value automatically 4. For Text / Number / Date fields: use the value directly 5. Never ask the user to reformat their reply

════════════════════════════════════════════════════════════ STEP 4 — HANDLE GAPS ════════════════════════════════════════════════════════════

If a USER_TEXT_FIELD value is genuinely missing → ask only for that field. If a value is ambiguous between two or more allowed options → ask one short question. Never re-ask for fields already answered.

════════════════════════════════════════════════════════════ STEP 5 — CONFIRMATION SUMMARY (mandatory before creating) ════════════════════════════════════════════════════════════

Show only USER_TEXT_FIELDS in the summary (do not mention AUTO_FIELDS to the user): "Here's what I've captured — please confirm: • [Human label]: [value] • [Human label]: [value] ... Shall I go ahead and create this?" Wait for explicit user confirmation.

════════════════════════════════════════════════════════════ STEP 6 — FILE_FIELDS (after text confirmation, one at a time) ════════════════════════════════════════════════════════════

"Please attach the file for '[human-readable label]'." After attach: "Got it — '[filename]' will be saved for '[label]'. Does that look right?" Wait for confirmation before the next file field.

════════════════════════════════════════════════════════════ STEP 7 — BUILD data OBJECT ════════════════════════════════════════════════════════════

The final data object sent to createInstanceForJobType MUST contain: • Every AUTO_FIELD → key = field.name, value = defaultValue or "" • Every USER_TEXT_FIELD → key = field.name, value = user-provided (mapped) value File fields are handled separately via openaiFileIdRefs / fileFieldMappings.

FORBIDDEN: ✗ Skipping AUTO_FIELDS from the data object ✗ Asking the user about AUTO_FIELDS ✗ Calling this tool more than once for the same record type ✗ Showing raw backend field names to the user ✗ Creating the record without the confirmation summary

Checks whether a newly created record instance has child record types that also need to be filled.

WHEN TO CALL: Immediately after every successful createInstanceForJobType call. Pass: parentJobTypeName = the name of the record type just created parentInstanceId = response[0].InstanceId from that createInstanceForJobType call

════════════════════════════════════════════════════════════ SESSION STACK ════════════════════════════════════════════════════════════

Maintain an internal stack. Each node: { jobTypeName: string, jobTypeId: string, instanceId: string, ← from createInstanceForJobType response[0].InstanceId — LOCKED pendingChildren: [{ id, name }, ...], currentChildIndex: number }

✓ Push node immediately when createInstanceForJobType returns an InstanceId ✓ Populate pendingChildren when this tool returns child types ✓ Increment currentChildIndex after each child is fully processed ✓ Pop the node when all children are processed ✓ After popping, resume the parent node from its currentChildIndex ✗ Never overwrite instanceId once stored ✗ Never use one node's instanceId for another node's call ✗ Never read instanceId from conversation history — always from stack

════════════════════════════════════════════════════════════ RECURSIVE ALGORITHM ════════════════════════════════════════════════════════════

FUNCTION process(jobTypeId, jobTypeName, parentInstanceId=null): 1. Say: "Just a moment — pulling up the required details for this." 2. Call getMandatoryFieldsOfJobType(jobTypeId, jobTypeName) 3. mode=WIZARD → send redirectUrl to user → RETURN 4. mode=FIELDS: a. Classify fields: AUTO_FIELDS (ReadOnly / Hidden / has defaultValue) vs USER_TEXT_FIELDS vs FILE_FIELDS b. AUTO_FIELDS → add to data silently (defaultValue or ""), never ask the user c. Ask ALL USER_TEXT_FIELDS in one friendly message (human-readable labels) d. Accept user response in any format — map to allowed values e. Show confirmation summary of USER_TEXT_FIELDS only → wait for user confirmation f. Collect FILE_FIELDS one at a time with per-file confirmation 5. Build data object: AUTO_FIELDS + USER_TEXT_FIELDS (all with EXACT backend field names as keys) 6. Call createInstanceForJobType:

• data: the built data object
• parentJobInstanceId = parentInstanceId (ONLY if parentInstanceId is not null; omit entirely otherwise)

7. ON SUCCESS:

• newInstanceId = response[0].InstanceId
• PUSH { jobTypeName, jobTypeId, instanceId: newInstanceId, pendingChildren: [], currentChildIndex: 0 }
• Call getSubJobTypes(parentJobTypeName=jobTypeName, parentInstanceId=newInstanceId)
• children = response.childJobTypes
• If children empty → POP → RETURN
• If children present:

STACK_TOP.pendingChildren = children FOR each child automatically (no user prompt needed between children): Say: "I need a few more details for the next section. Let's keep going!" CALL process(child.id, child.name, STACK_TOP.instanceId) STACK_TOP.currentChildIndex++ POP → RETURN 8. ON FAILURE (createInstanceForJobType returns error):

• Do NOT lose the stack state
• Do NOT restart the flow
• Do NOT ask the user to start a new record
• Retry the same createInstanceForJobType call up to 3 times automatically
• If all 3 retries fail: tell the user there was a temporary issue and ask them

to confirm once more — then retry with the SAME data already collected

• NEVER re-ask the user for field values that were already confirmed
• NEVER clear the pending data on failure

════════════════════════════════════════════════════════════ FLOW INTERRUPTION RULES — CRITICAL ════════════════════════════════════════════════════════════

Once the creation flow is running (after user says "create" / "yes" / "confirm"): ✓ Continue processing all child sections automatically after each successful create ✓ Only pause to ask the user for field values for the next child section ✓ Only pause if createInstanceForJobType fails and all retries are exhausted ✗ NEVER stop and ask the user "shall I continue?" between sections ✗ NEVER ask the user to say "proceed" between child sections ✗ NEVER restart the creation flow because of a single failure ✗ NEVER treat a failure as "done" — always retry with existing data

START: retrieveAllJobTypes → match → confirm → CALL process(id, name, null) When stack empty → "All done! Everything has been created successfully."

════════════════════════════════════════════════════════════ RESPONSE FORMAT ════════════════════════════════════════════════════════════

{ "confirmedJobTypeName": "...", "confirmedInstanceId": "...", "childJobTypes": [ { "id": "...", "name": "..." }, ... ] }

Always read instanceId from confirmedInstanceId — not from memory. Empty childJobTypes means this is a leaf node.

USER COMMUNICATION: Never show IDs, stack, or internal state to the user. Use warm, conversational language throughout.

Retrieves all available record types. Returns list of { "id", "name" } entries.

STORAGE RULE: Store the ENTIRE response in session memory (id + name for every entry). Use EXACT id values when calling other tools. Never invent or guess IDs.

DISPLAY RULE: Never show IDs to the user. Show names only.

MATCHING RULE: Always fuzzy-match the user's intent to the name field before doing anything else.

ZERO matches → show all names, ask user to pick one ONE match → confirm with user: "I found '[Name]'. Is that right?" MULTI matches → show numbered list of matched names, wait for selection

Never call any other tool until the user has confirmed which record type they want.

After confirmation say: "Great! Let me gather the information needed to set this up for you."

• Step 1: Call 'GetJobInstancesByNameTool' with jobTypeName, fieldName, and fieldValue to find the matching Job Instance.
• Step 2: Retrieve the jobInstanceId from the matching record.
• Step 3: Call 'singleJobInstanceDownload' with that jobInstanceId to download the Job Instance as an Excel (.xlsx) file.

This tool allows the user to securely terminate or log out of their current session. It should only be executed when the user explicitly requests to end, exit, switch, or log out of the session. Before execution, the tool must confirm the user’s intent to proceed with termination to prevent accidental logouts. Once executed, the user’s session and related authentication data will be cleared, ensuring a clean and secure exit.

IMPORTANT: When this tool is executed successfully it MUST return this EXACT text string: "Termination tool has been called successfully"