Start here: a quick confidence check

• How often do you run portfolio-level catastrophe exposure runs today? Options: Daily, Weekly, Monthly, Quarterly, Ad hoc / event-driven
• Which teams in your organization currently own catastrophe exposure, model validation, and event response? Options: Catastrophe risk team, Actuarial, Underwriting, Claims operations, IT/Integration, Other
• Tell me about the last event where your board or reinsurers requested rapid loss estimates, what happened and how quickly were numbers produced?
• On average, how long does it take from event landfall to your first credible loss estimate? Options: Under 1 hour, 1 to 3 hours, 3 to 6 hours, 6 to 24 hours, More than 24 hours

Where your current approach falls short

• If a single modeling failure during an event would trigger an independent review by the board, what specific failure would that be?
• In the last three years, count the events where actual losses differed from your model estimates by more than 20%. Options: None, 1, 2 to 3, 4 to 6, More than 6
• Describe the most common downstream problem when loss estimates change significantly during an event, and how long it takes to recover.
• Who is first notified internally when a major event occurs, and who must sign off on numbers released externally? Options: CRO, Head of Cat Risk, Chief Actuary, VP of Claims, CIO/CTO, Other roles
• What would have to be true about your current models for you to keep using them after this year? Options: Consistent event accuracy within thresholds, Faster real-time estimates, Lower total cost, Better integration with systems, Executive mandate to retain

Can your systems and data run at event speed?

• Assumed integrations often do not exist, which of the required systems for event runs actually expose production APIs today? Options: Policy administration, Claims system, Exposure/GIS feed, Reinsurance ledger, None of the above, Other
• Name the technical owners for each required system and the usual lead time to obtain credentials and access.
• Count the unique exposure file formats your portfolio produces today that would need mapping. Options: 1, 2, 3 to 4, 5 or more, Unknown
• Are there regulatory, privacy, or contractual reviews that typically delay sharing policy-level data externally? Options: Yes, commonly, Occasionally, Rarely, No
• Estimate the percentage of your exposure records that are geocoded to rooftop level, versus centroid or missing. Options: > 90%, 70% to 90%, 50% to 70%, < 50%, Unknown
• If integration work takes 8 weeks instead of 4, would that change whether you proceed with a pilot? Options: Yes, it would stop the pilot, It would delay but not stop, No, still proceed, Unsure

Who will respond when the event lands

• When the first significant event hits, what part of your response plan do you expect will fail or create the biggest headache?
• List the roles that must be staffed within 72 hours of an event and indicate whether backfill plans exist for each.
• Time to mobilize: what is your expected window to deploy licensed adjusters under current contracts, and are there contractual caps on surge? Options: Under 24 hours, 24 to 48 hours, 48 to 72 hours, More than 72 hours, No surge capability
• Tell me about the last time you used outside aerial imagery or drone services, what worked and where delays occurred.
• Name the top field limitation your claims leader would cite that would stop deployment immediately.

Alternatives you are weighing and why they might keep you where you are

• Who currently provides your catastrophe modeling or event response, and what is the single reason you might stay with that option? Options: Incumbent vendor, Internal team, Multiple vendors, No provider, Other
• List the alternative approaches you have evaluated in the last 12 months, including internal development.
• What would have to be true about the incumbent or internal option for you to choose to stay with it rather than change vendors? Options: Proven speed during events, Lower cost, No integration work, Executive preference, Meets accuracy thresholds
• Has anyone on your leadership team proposed solving this internally instead of using an outside partner? Options: Yes, No, Under discussion
• Estimate the timeline and budget leadership would realistically sign off on for an internal development path. Options: Under 3 months and under $100k, 3 to 6 months and $100k to $500k, 6 to 12 months and $500k to $1M, Over 12 months and over $1M, Unsure

Can you meet the operational prerequisites we need

• Assume regulatory or legal review is required for sharing policy-level data, how long does that process typically take and who must sign it?
• Identify the systems we must integrate with for modeling and response automation, and indicate whether they currently offer accessible APIs. Options: Policy admin, Claims platform, Exposure/GIS feed, Reinsurance accounting, Other
• Does your technical team have staff available to support a multi-week integration project, or would you need to reprioritize or hire? Options: Dedicated staff available, Partial availability, No capacity, would need to hire, Unsure
• Provide the percent of your portfolio data that would require manual cleaning before automated modeling runs. Options: Under 10%, 10% to 30%, 30% to 60%, Over 60%, Unknown
• Are there data retention or contractual restrictions that would prevent storing derived loss estimates outside your network? Options: Yes, No, Requires legal review
• Identify the person or role who must approve production use of an external model and list their acceptance criteria.
• Should policy-level geocoding not be ready within 12 weeks, would that stop a pilot or require a scoped workaround? Options: Stop the pilot, Require a scoped workaround, Proceed with delays, Unsure

If this proves out, what changes for your business

• Suppose the pilot delivers reliable estimates within your thresholds, what would stop you from finalizing a contract that same month? Options: Budget approvals, Procurement timelines, Integration readiness, Legal or compliance, Nothing would stop us
• Describe the ways faster event loss estimates would change your reinsurance buying cadence or sizing decisions.
• Provide the metrics and thresholds you would use to accept model performance for production use.
• Please list the stakeholders who must join a mutual-commit review and their decision authority. Options: CRO, Chief Actuary, VP Claims, CIO/CTO, Procurement, Legal
• Share the timeline you expect between pilot completion and full deployment, including procurement and legal reviews. Options: Under 4 weeks, 4 to 8 weeks, 8 to 12 weeks, Over 12 weeks, Unsure
• Do you anticipate any executive-level objections to signing a vendor for both modeling and response services? Options: Yes, No, Possibly
• Select the single constraint that would kill the deal: data access, budget, legal, integration time, or executive priority. Options: Data access, Budget, Legal or compliance, Integration time, Executive priority, Other
• Map the handoffs between underwriting, actuarial, and claims during an event and highlight where friction occurs.
• Would you be open to a time-boxed pilot limited to a single line of business to shorten decision time? Options: Yes, Maybe, No
• Finally, who should we include on a technical scoping call next week to validate integrations and timelines? Options: Technical lead, Integration owner, Data steward, Claims operations lead, Underwriting lead, Other

• Solution Experience Session

• Confirm the current state and its cost
• You confirm the demonstrated workflow supplies trusted loss numbers suitable for board and reinsurer reporting.
• Provide a representative sample portfolio (or confirm permission to use a secure proxy) for the follow-up model run.
• Walk through an end-to-end portfolio scenario
• You confirm the modeled loss timeline and response-service triggers meet your adjuster deployment and claims SLAs.
• Run the demonstrated portfolio scenario on the provided portfolio and deliver a loss-timeline report plus a comparison to the buyer's current estimates before the next session.
• Show real-time loss estimate progression and confidence
• Share the response-service deployment playbook mapped to the buyer's SLA tiers and proposed adjuster mobilization timelines.
• You agree on the remaining evidence required before a procurement decision and the owners for each item.
• Confirm the decision stakeholders and the acceptance criteria they require for model accuracy and operational readiness.
• Demonstrate response services mapped to loss tiers
• Validate this maps to your need
• Agree remaining evidence and next decision steps

• Solution Experience Session
• Solution Experience Deck
• Solution Brief — Modeling & Response Experience

• meeting
• slides
• document

• Current-State Response Capabilities Mapping
• Surge Staffing and Adjuster Deployment Design
• Data Handoffs and Operational SLA Finalization
• Event Runbook Review and Exercise Planning

• Assemble the exercise evaluation checklist and metrics that will be used to score readiness and identify remediation work.
• List and schedule resolution tasks for dependencies requiring cross-functional input such as licensing verification and vendor contracts.
• Review required data elements and current formats
• A finalized data schema and delivery cadence for event feeds is documented and approved for technical implementation.
• Operational SLAs for data, model turnaround, and claims handoff are defined with measurable metrics and remediation steps.
• A test and acceptance plan for validating the data handoffs before deployment is agreed.
• Produce a data specification document with field definitions, sample records, transport methods, and security requirements.
• Publish an SLA matrix listing metrics, targets, measurement windows, and escalation steps for each operational interface.
• Schedule integration test windows and provide sample payloads for technical teams to validate against acceptance criteria.
• Walk through the consolidated runbook
• A single version of the event runbook is approved for use in exercises and contains clear decision points and escalation steps.
• A schedule and scope for a tabletop exercise and a follow-up live drill are agreed with success criteria.
• All critical open items required for exercise readiness are listed with target completion dates.
• Publish the approved runbook as the authoritative version for tabletop planning and distribute to exercise participants.
• Create and share the tabletop exercise plan with scenarios, participant list, and required pre-reads.
• Confirm scope and success criteria
• A region-by-region map of roles, surge staffing sources, and deployment flow has been documented and agreed as accurate or noted for follow-up.
• A prioritized list of capability gaps that would block an acceptable response is produced with top three gaps identified for immediate resolution.
• A clear list of outstanding evidence or data points required to resolve disputed items is recorded.
• Produce and circulate the region-level current-state map and the prioritized gap list in a single document for asynchronous review.
• Collect missing data feeds and sample files identified during mapping for technical validation in the next session.
• Compile a roster of surge staffing sources with licensing and qualification fields for each region.
• Review prioritized gaps from mapping
• A documented surge staffing model with tiers, numeric thresholds, and activation triggers is agreed.
• An adjuster deployment playbook that covers assignment logic, pre-positioning rules, and demobilization criteria is approved for draft implementation.
• A list of dependencies that must be closed before the surge model can be operational is produced with timelines.
• Produce the surge staffing model document including tiers, numeric thresholds, and activation checklist.
• Draft the adjuster deployment playbook with sequencing diagrams and sample deployment timelines for each tier.
• Agree delivery cadence and transport methods
• Map stakeholder roles and ownership
• Review SLA monitoring and escalation flows in the runbook
• Define surge staffing tiers and thresholds
• Set adjuster deployment rules and sequencing
• Document current surge staffing model and adjuster deployment flow
• Define measurable SLAs and error-handling
• Agree tabletop and live exercise objectives and scope
• Sign-off and next steps
• Create a verification and escalation plan
• Establish timebound escalation and reporting steps
• Map data handoffs and system touchpoints
• Capture unresolved items and dependencies
• Identify and rank capability gaps
• Confirm testing requirements and acceptance criteria

• Ingest and Normalize Policy Exposure Data
• Run Probabilistic Hurricane Simulation
• Run Probabilistic Earthquake Simulation
• Run Probabilistic Wildfire Simulation
• Portfolio Loss and Accumulation Analysis
• Claims Volume and Geographic Concentration Forecast
• Real-time Event Loss Estimates
• Reinsurance Optimization Scenario Runs
• Integrate Loss Outputs to Policy and Claims Systems
• Deploy Licensed Field Adjusters
• Drone-Based Aerial Damage Assessment
• Satellite Imagery Damage Mapping and Analytics
• Mobile Claims Processing Unit Deployment
• Rapid Triage and Prioritization of Claims

Ingest and Normalize Policy Exposure Data

• Which policy administration system(s) will supply the exposure feed (policy export, certificate-level or block-level)?
• What file formats will you provide for policy exposure (ACORD XML, CSV with policy_id and address columns, GIS shapefile, database export)? Options: ACORD XML, CSV (policy_id,address,limit,deductible), GIS shapefile / GeoJSON, Database export (SQL dump), Other
• How often are policy attributes updated in your source (daily batch, intra-day delta, real-time on-change)? Options: Daily batch, Intra-day delta (multiple times per day), Real-time on-change webhook / streaming, Weekly or less frequent
• Do you require normalization of policy-level limits, deductibles, coinsurance and endorsements into canonical fields? Options: Yes, full normalization required, Partial normalization (we will provide mappings), No, we will accept raw fields
• Define the acceptance criteria for exposure normalization (for example, >=98% policy_id match rate, >=95% address geocoding success for primary risk locations).

Run Probabilistic Hurricane Simulation

• Which policy attributes should be used to calculate wind vulnerability (construction class, roof type, year-built, building height)? Options: Construction class, Roof type, Year-built, Building height/number of stories, All of the above
• Specify the geographic granularity for hurricane output you require (policy point, ZIP polygon, county, state). Options: Policy point (lat/long), ZIP polygon, County, State, Other
• Are there coastal surge or storm-surge-specific coverages or sublimits that must be modeled separately from wind (for example, separate deductible or sub-limit fields)? Options: Yes, separate surge coverage exists, No, surge is combined with wind, Not sure—need to confirm
• List any wind vulnerability modifiers your underwriters use (hurricane straps, roof-to-wall connections, mitigations) that should be applied to model vulnerability.
• Provide the set of return periods or exceedance probabilities required for hurricane outputs (for example 1-in-50, 1-in-100, 1-in-250). Options: 1-in-50, 1-in-100, 1-in-250, Custom set (specify below)

Run Probabilistic Earthquake Simulation

• List the seismic exposure attributes you maintain per policy (soil class, foundation type, construction type, occupancy).
• Select preferred intensity measures for earthquake outputs (Peak Ground Acceleration, spectral acceleration at 0.3s, spectral acceleration at 1.0s). Options: Peak Ground Acceleration (PGA), Spectral acceleration 0.3s (SA0.3), Spectral acceleration 1.0s (SA1.0), Other
• Enable site amplification, soil liquefaction, or landslide modules for specific regions where you track geotechnical risk? Options: Yes, enable amplification and liquefaction, Enable amplification only, No, do not enable
• Identify the policy layers or ceded limits that must be mapped to ground-shaking losses (primary layer, XOL layer 1, quota share coverage).
• Estimate the acceptable model uncertainty band for earthquake scenario outputs that the business will accept for decision making (for example +/- 10%, +/- 25%). Options: +/- 10% or better, +/- 25%, +/- 50% or other (specify)

Run Probabilistic Wildfire Simulation

• Describe the wildfire vulnerability attributes you track (vegetation proximity, roof ignitability, defensible space status).
• Provide any historical fire perimeter or burn scar datasets to include in scenario seeding (file type and date range). Options: We will provide GIS perimeters, Use public historical perimeters only, We need assistance obtaining datasets
• Are local mitigation ordinances or municipal defensible-space programs a factor in underwriting and should be reflected as vulnerability adjustments? Options: Yes, reflect municipal programs, No, do not reflect, Unknown—need assessment
• Specify wildfire-specific policy endorsements or sublimits that must be modeled separately (for example, separate wildfire deductible or sublimit by coverage).
• Define the acceptance criteria that will confirm wildfire simulation deliverables (for example, policy-point perimeter hit-rate >=90% and geocoding success >=95%).

Portfolio Loss and Accumulation Analysis

• Identify the exposure aggregation level to use for accumulation reporting (policy point, ZIP centroid, census tract, county). Options: Policy point (lat/long), ZIP centroid, Census tract, County, Custom region
• Select the loss metrics you need in portfolio reports (expected annual loss, average annual loss, probable maximum loss at selected return periods). Options: Expected Annual Loss (EAL), Average Annual Loss (AAL), Probable Maximum Loss (PML) at return periods, Other
• Describe the reinsurance treaty structures to include when calculating accumulation (per-occurrence XOL layers, aggregate stop-loss, quota share).
• By what return periods must accumulation be delivered to stakeholders (for example 1-in-50, 1-in-100, 1-in-250)? Options: 1-in-50, 1-in-100, 1-in-250, Custom (specify)
• Confirm any concentration thresholds that should trigger special reporting (for example a ZIP with >5% of total insured value). Options: Yes, specify threshold, No threshold, Use custom rule (specify below)

Claims Volume and Geographic Concentration Forecast

• Estimate expected claims frequency and average severity by peril based on your most recent loss runs (attach sample if available).
• State the time-to-first-contact SLA your claims team requires post-event (hours), to align triage and adjuster deployment. Options: Within 2 hours, Within 6 hours, Within 24 hours, Custom (specify)
• Name the claims management system and the required interface type for ingesting forecasted volume (API, SFTP batch, manual CSV). Options: API, SFTP batch, Manual CSV upload, Other
• Indicate any triage prioritization rules to encode (for example commercial over residential, limit > $X prioritized, coastal zones first).
• Give an estimate of the peak daily claims handling capacity your operations can absorb before external adjuster deployment is required. Options: <100 claims/day, 100-500 claims/day, 500-2,000 claims/day, >2,000 claims/day

Real-time Event Loss Estimates

• State the acceptable latency for real-time loss estimates during an active event (for example 5 minutes, 30 minutes). Options: <=5 minutes, <=15 minutes, <=30 minutes, Hourly updates
• Indicate the required confidence interval or accuracy band for initial event loss estimates provided to executives and reinsurers. Options: +/- 10%, +/- 20%, +/- 30%, Other (specify)
• Name the streaming interfaces or dashboards where the real-time estimates must appear (web UI, API endpoint, push notification). Options: Web UI dashboard, REST API endpoint, Push notifications / messaging, Email reports
• Define the acceptance criteria for real-time loss outputs (for example latency <=15 minutes and initial estimate within +/-20% of validated loss).
• Attach any regulatory reporting formats or filing schemas the real-time feed must support (for example NAIC schedule templates or local regulator CSV layouts).

Reinsurance Optimization Scenario Runs

• Enumerate the treaty structures and layers you want included in optimization (quota share, per-occurrence XOL layers, aggregate stop-loss).
• Declare target capital or reinsurance spend constraints to respect during optimization (annual budget, attachment points, premium caps).
• Detail the input loss distributions and correlation assumptions you prefer between perils and regions (for example, correlation matrix or independent assumption).
• Confirm whether optimization runs should include probabilistic scenarios, deterministic stress shocks, or both. Options: Probabilistic only, Deterministic shocks only, Both probabilistic and deterministic
• Give an estimate of the number of candidate portfolios or iterations you expect the optimization process to evaluate. Options: <10, 10-50, 50-200, 200+

Integrate Loss Outputs to Policy and Claims Systems

• Declare the destination systems that must receive loss outputs (policy administration system, claims management system, reinsurance accounting).
• Choose the acceptable delivery methods for loss output (REST API POST, SFTP batch CSV, message queue). Options: REST API POST, SFTP batch CSV, Message queue (Kafka/AMQP), Push to internal data lake
• Provide the required field-level mappings from model output to your policy schema (for example map model.loss_total to policy.loss_estimate, model.node_id to policy_point_id).
• Attach a sample policy record export and a sample claims record format we should map into during integration testing. Options: Will attach sample files, Samples not available yet, Need assistance extracting samples
• Confirm the expected delivery cadence for loss outputs to each system (real-time stream, hourly batch, end-of-day batch). Options: Real-time stream, Near real-time (<=15 min), Hourly batch, End-of-day batch

Deploy Licensed Field Adjusters

• Specify the license states and adjuster qualifications required for field adjusters (state adjuster license list, auto/property lines).
• Indicate preferred adjuster deployment models (vendor roster, surge pool, dedicated account team). Options: Vendor roster, Surge pool, Dedicated account team, Hybrid
• Describe target adjuster-to-claim ratios for initial surge and steady-state operations (for example 1:20 during surge, 1:80 steady-state).
• Name any proprietary estimating or claims systems the adjusters must use on-site (for example internal mobile estimating app — provide integration requirements).
• Provide any required background-check or credential verification artifacts we must validate before deployment (license numbers, training certificates). Options: We will provide license numbers, We require vendor to provide credentials, No special artifacts

Drone-Based Aerial Damage Assessment

• Specify the image formats and geospatial deliverables required from drone flights (GeoTIFF, orthomosaic, WKT polygons). Options: GeoTIFF, Orthomosaic, WKT polygons / shapefile, Other
• Indicate FAA or local airspace constraints that affect drone operations in key regions (no-fly zones, waivers required). Options: Waivers required, No known constraints, Need assistance identifying constraints
• Describe the minimum ground sample distance (spatial resolution) and nadir/oblique imaging mix you require for damage assessment.
• Identify turnaround time expectations for processed drone deliverables (flight to orthomosaic delivery in hours/days). Options: <12 hours, <24 hours, 24-72 hours, >72 hours
• Provide any required metadata fields to accompany imagery (flight time, sensor ID, georeference accuracy).

Satellite Imagery Damage Mapping and Analytics

• Specify required satellite product types and resolution (optical 0.5m, multispectral 3m, SAR) for damage mapping. Options: High-resolution optical (~0.5m), Multispectral medium-res (~3-10m), Synthetic Aperture Radar (SAR), Other
• Indicate the maximum acceptable latency from event to usable satellite imagery (hours or days). Options: <6 hours, <24 hours, <48 hours, >48 hours
• Describe analytic outputs you expect from imagery (change-detection polygons, burn severity index, flooded area delineation). Options: Change-detection polygons, Burn severity mapping, Flood extent delineation, Other
• Identify the coordinate reference system (CRS) or GIS projection your GIS team requires for deliverables. Options: WGS84 (EPSG:4326), Web Mercator (EPSG:3857), Company-specific CRS (specify), No preference
• Provide acceptance thresholds for satellite-derived damage layers (for example IOU or hit-rate relative to validated ground truth).

• desired_state
• current_state
• stakeholders
• gaps
• success_criteria
• decision_readiness
• desired_state
• decision_readiness
• current_state
• success_criteria
• gaps
• stakeholders
• desired_state
• success_criteria
• stakeholders
• gaps
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Subscription Order Form
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Data Access and Authorization Agreement
• Integration & API Access Addendum
• Model Validation Acceptance Certificate
• Operational Governance & Roles Charter
• Pricing & Payment Schedule Annex
• Termination, Transition and Data Return Plan
• Regulatory Compliance Addendum

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review, Formal Acceptance Decision (around day 90)
• Monthly Operational Check-in
• Quarterly Realization Review

• Reduce the active critical-ticket count and confirm owners and due dates for remaining high-priority items.
• For any failed or conditional criteria, agree precise remediation tasks and deadlines that will convert conditional outcomes to passes.
• If replacing an incumbent, confirm the decommissioning plan or retention-read-only approach has been scheduled and resourced.
• Publish the formal acceptance record that lists each criterion, pass/fail status, signatory statement, and remediation obligations with dates.
• Create remediation tasks for conditional items with completion owners and firm deadlines and place them in the issue tracker.
• If incumbent decommissioning applies, produce a migration and archive checklist with target completion dates.
• Metric trend review
• Ensure that key operational metrics remain within acceptable bounds or have a concrete remediation plan with dates.
• Re-confirm success criteria and owners
• Update the operational runbook with any agreed SLA clarifications or process changes.
• Prioritize enhancement requests and schedule work items into the next monthly delivery window or backlog.
• Deliver a one-page status summary of metric trends and open critical tickets before the next check-in.
• Quarterly outcomes summary
• Confirm whether quarterly outcomes meet the targets set in the Model Validation Exercise and document any agreed SLA adjustments.
• Clear or escalate persistent blockers and set a time-bound plan to close remaining remediation items.
• Publish the quarterly realization report that maps each target to observed performance and lists agreed SLA or playbook changes.
• Create time-bound remediation tasks for any persistent blockers with escalation points and deadlines.
• Distribute the next quarter priorities and checkpoint schedule to the operational teams.
• Confirm that integrations and data feeds are operating end-to-end and that there are no blockers preventing outcome measurement.
• Establish baseline adoption signals and a short remediation plan for any critical issues to be resolved before the first measurement window.
• Publish a go-live report listing live integrations, data feed status, and onboarding completion rates for all user cohorts.
• Log and prioritize critical defects in the issue tracker with target resolution dates.
• Confirm the data sample and access method that will be used for the first measurement review.
• Present first-period metric data
• Determine whether real-time loss estimate MAPE and time to first valid loss estimate are tracking toward the targets recorded in the Model Validation Exercise.
• Agree a concrete remediation plan for each out-of-target metric, with resolution dates that lead to the acceptance gate.
• Produce a remediation plan that lists each root cause, corrective action, expected metric impact, and a target completion date.
• Deliver updated integration logs and sample output demonstrating fixes for any data or latency issues.
• Confirm the data snapshot that will be used for the acceptance gate analysis in the Model Validation Exercise tab.
• Restate acceptance criteria and numeric targets
• Record a documented acceptance decision with a named signatory for managed/enterprise engagements, or a documented buyer-owner decision for self-serve motions.
• Deployment and migration validation
• Present outcome data against each criterion
• Persistent blockers and remediation status
• Open issues and ticket burn-down
• Diagnose root causes for any gaps
• Enhancement and change requests triage
• Agree corrective actions and timelines
• Operational SLA adjustments and playbook updates
• Document pass, conditional pass, or fail per criterion
• Early adoption signals and usage patterns
• Short checkpoint on training and adoption
• Blockers and open issues triage
• Formal acceptance signatory
• Confirm readiness and timeline to acceptance gate
• Agree next quarter priorities and checkpoints
• Incumbent system wind-down check (if applicable)
• Agree immediate remediation actions