symphony-default

Send an outbound SMS to a party on this submission/claim. Use for quick asks (single field, status updates). Avoid for anything requiring an attachment. Always include a rationale explaining why this is the next best step.

Send an outbound email to a party. Use for asks that need detail, document requests, or anything requiring an attachment trail. Threading is automatic when in_reply_to is set to a prior outbound email message_id.

Render a hardcoded letter template to PDF and email it to a party (or to whichever party on the claim holds a given role). Generates a Document row and threads into the comms hub.

Text a party a private link to upload photos, videos, or documents (receipts, estimates) for a submission or claim. Use after a call when the caller indicated they have evidence to share and their preferred follow-up channel is sms/text (or unset). Skip if their preference is 'email' — the inbound-email parser handles attachments. Pass exactly one of submission_id or claim_id; the link is scoped to that record.

Place an outbound phone call to a party via Retell. Use when: (a) the party's preferred_channel is 'voice' and the next outreach is conversational rather than a document ask, (b) ≥3 required fields are still missing or the loss narrative is empty/<1 sentence (a call collects ambiguous info faster than SMS), or (c) the most recent prior call's transcript shows it didn't reach its objective (caller hung up, agent didn't get past identity, line dropped). Default to SMS for short asks and email for documents. Provide a focused objective, a short ordered list of talking points, and a voicemail summary in case the recipient doesn't pick up. Always include a rationale.

Schedule a future outbound phone call. Use when you've decided a call is right but timing matters — e.g. callback windows the recipient gave you, or backing off a few hours after a missed call attempt. The adjuster can cancel or run-now from the UI. Use initiate_outbound_call when you want to call right now.

Merge a single field into submissions.captured_fields. Use when you derive a value from a message (e.g., reporter texts back "Oct 4 morning" → set loss_date). Key must match an existing FieldDefinition. Triggers a re-evaluation of required_fields_status.

Add or remove an entry on submissions.conversion_blockers. Use when something is preventing the submission from being converted that does not show up in required_fields_status (e.g., reporter says policy has lapsed, contradiction between policy address and reported address).

Schedule a future SMS or email follow-up. Use when you've asked once and want to nudge again if there's no reply by a deadline. Always pick a reasonable due_at (24-48h for first SMS retry, 3-7 days for email). The adjuster can cancel or run-now from the UI.

Cancel a scheduled follow-up activity (followup_sms / followup_email) by its activity_id. Use this when the reason for the follow-up has been resolved — e.g., after the holdback release is approved, cancel the 30/60/180-day receipt-reminder follow-ups for that exposure since the holdback is no longer outstanding. Idempotent: cancelling an already-completed or already-cancelled follow-up returns ok=false but does not error. Always include a clear `reason` (the rationale field).

Terminal. Convert the current submission into a Claim row. The claim driver will then open exposures explicitly via `create_exposures`. `coverage_codes` records your coverage hypothesis as advisory metadata on the conversion activity — pick the coverage codes you believe the loss implicates, but no exposure rows are created here. Only call when (a) required_fields_status is all satisfied AND (b) conversion_blockers is empty AND (c) you can confidently pick the coverage codes implicated. This action requires human approval.

Terminal. Flip the submission to escalated and pull the driver out. Use for: contradictory info that you cannot resolve, signs of fraud, policy lapsed, attorney represented from the start, third-party liability beyond personal property scope.

Verify whether the claim's policy was in force at the date of loss. The deterministic lookup + plain-language rationale are computed as soon as you call this tool; when human approval is required, the adjuster sees the AI's verdict on the approval card and can confirm or override before it lands on the claim. The verdict is persisted to claim.extended_fields.policy_verified + policy_verification_notes and recorded as a 'policy_verification' work-activity. Call this as the FIRST step on a fresh claim. Call with no arguments — the lookup happens server-side.

Open one or more Exposures on the claim. Each exposure is the unit money attaches to — one Exposure per CoverageGrant the loss actually implicates. Use `policy_snapshot.coverageGrants` as the source of truth for `coverage_grant_id` (do not invent IDs); typical burst-pipe pattern is Coverage A (dwelling) + Coverage C (contents), plus D (ALE) if the home is uninhabitable. `claimant_party_id` is normally the insured (reporter on the submission); use a different party only when a third party is the claimant for that coverage line. `valuation_method` defaults to the CoverageGrant's own valuation_method — only override when you have a specific reason. Existing exposures on the same coverage_grant_id are silently skipped (idempotent on retry). Requires human approval when autopilot is off.

Set reserve amounts on one or more Exposures on this claim. Reserves are the insurer's running internal estimate of what each exposure is likely to cost — split into `reserve_indemnity` (paid to/for the insured for the loss itself: repairs, contents, ALE) and `reserve_expense` (fees, vendor costs, independent adjuster, etc.). At intake/exposure opening, base the number on cause-of-loss severity and the CoverageGrant's limit. Once an inspection or repair estimate is on file, re-call this tool to true up reserves to the estimate's per-coverage RCV — reserves are documentation and should track the latest evidence. Per-exposure `rationale` explains how you arrived at the amount (e.g., 'mid-size burst pipe, drywall + flooring two rooms ≈ $20k indemnity' or 'trued up from inspection report: Coverage A RCV $7,171.32'). Requires human approval when autopilot is off; auto-applied when autopilot is on.

Compute the deterministic payout breakdown for each exposure once the inspection report's per-coverage RCV and recoverable depreciation are known. The tool takes RCV and recoverable_depreciation per exposure (you read these off the verified inspection report fields and split per coverage), then deterministically: (1) computes ACV = RCV − depreciation, (2) applies the policy deductible exactly once — to the exposure with the highest RCV — using the deductibleAmount from that coverage's grant (typical: Coverage A's $1,000), (3) computes net_acv_payable_now = ACV − deductible (or just ACV for non-bearer exposures), (4) writes `depreciationAmount`, `appliedDeductibleAmount`, and `recoverableDepreciationOutstanding` to each Exposure. Returns the per-exposure breakdown including net_acv_payable used as the input to `propose_payment`. Auto-applied — pure math + DB write, no human gate.

Zero out the outstanding recoverable depreciation (RCV holdback) on an exposure. Use this when the receipt-submission window has expired without receipts being provided (default: 180 days from the initial payment). The Config carries the timeline as a rule; the driver calls this tool only after the timer fires. Per-call `reason` is required — typically cites the cumulative timer (e.g., '180 days elapsed without receipts; per Config rule the holdback is forfeited.'). Auto-applied — no human gate; clearing an already-zero holdback is a no-op.

Propose a payment for a SINGLE exposure. ⚠️ ONE call per exposure — never combine multiple exposures into one payment. The tool validates that `amount` matches the exposure's own computed payout (reserve_indemnity − depreciation_amount − applied_deductible_amount for non-holdback indemnity; recoverable_depreciation_outstanding for holdback release); a mismatch is a hard error, usually meaning you lumped values across exposures or skipped compute_payout. Creates a `payments` row at `status='proposed'` and a `pending_approval` activity that the adjuster sees on the claim's Overview tab. The adjuster can edit the amount before approving, or reject with a reason. Once approved, the payment row flips to `issued` and the driver re-ticks. Payee logic is deterministic: insured-only when amount < $5,000 OR the exposure is not Coverage A/B (mortgagee has insurable interest in dwelling only); joint with the highest-priority mortgagee on the policy otherwise. Pass the per-exposure breakdown for the initial post-inspection payment — it surfaces in the approval UI as a calculation explanation. For holdback-release payments, set is_holdback_release=true and amount=outstanding holdback; breakdown can be null. Per-call `rationale` is shown alongside the proposal — cite the calculation.

Attach a party to this claim with a role (e.g., 'inspector', 'contractor', 'public_adjuster'). Creates a party_on_claims row so the party appears in the stakeholders list and can be messaged via send_email / send_sms. Idempotent on (claim, party, role) — re-calls return alreadyLinked=true without duplicating. Use for stakeholders the driver brings into the claim itself (a default inspector for an inspection, a contractor the insured engages, an attorney). The insured/reporter is already linked on claim creation — don't re-add them.

Merge a single key/value into claims.extended_fields. Key must match an existing claim-scope FieldDefinition (rendered in your context under field_definitions). Use this to record decisions like `inspection_status='scheduled'`, `inspection_scheduled_at=<ISO 8601>`, or `inspector_party_id=<uuid>`. Value type should match the FieldDefinition.type (ISO 8601 for datetime, enum string for enum, etc.). Internal bookkeeping — not gated by autopilot.

Override or set the classification of a document (e.g., correct a misclassified estimate that should be an inspection_report). Used when the automated classifier got it wrong or for manually-uploaded documents. Internal bookkeeping — runs without approval even when autopilot is off.