A quick line snapshot

• How would you summarize the current scrap problem on the candidate line in one sentence?
• Describe the defect capture workflow on a typical shift, from detection to where the record lands today.
• In the last three months, how many consecutive months has scrap exceeded your target? Options: 1 month, 2 months, 3 months, 4 or more months
• Which role on your team will own coordinating the pilot and granting MES or data access? Options: Quality engineer, Continuous improvement manager, Plant manager, IT/MES owner, Not decided

Where the scrap risk actually shows up

• What single defect pattern, if unresolved, would force you to stop shipments or trigger a major corrective action?
• Walk me through the recurring defect types on that line and how operators currently classify them during a run.
• How many defects per million opportunities does the line record when the spikes occur, using your best estimate or historical numbers? Options: <100 DPMO, 100–500 DPMO, 500–2000 DPMO, >2000 DPMO, Don't have a reliable number
• When a defect spike appears today, who is notified and what immediate containment steps are taken?
• Describe the last incident where a material lot, tool change, or environment shift coincided with a defect surge, and what you learned from it.

What stands between you and a faster root-cause

• Who on your floor has authority to stop a line over quality issues, and would they support a pilot that changes a small part of operator workflow?
• Do you have a formal defect taxonomy today, and if so, which of these best describes it? Options: No formal taxonomy, Simple taxonomy maintained by quality, Detailed taxonomy maintained by engineering, Multiple inconsistent taxonomies, Other
• Which MES endpoints or exports currently include defect codes, timestamps, cycle IDs, and lot numbers? Options: Real-time MES transactional API, Scheduled CSV or database extracts, Only manual reports, No MES data available
• Have past attempts to reduce scrap created alert fatigue or added paperwork that hurt adoption? Options: Yes, significant, Somewhat, No, Not sure
• What breaks downstream when operators must spend more time logging defects or following extra steps?
• If we couldn't access one of the required MES endpoints within 4 weeks, would you still proceed with a pilot on that line? Options: Yes, proceed with available data, No, pilot would be blocked, Depends which endpoint is missing

The other options your team is weighing

• If the incumbent vendor or your existing toolchain could prove the same root-cause link in 4 weeks, what would keep you from staying with them?
• List the types of alternatives you are evaluating right now for defect analytics. Options: Spreadsheets and manual Pareto, Standalone SPC software, MES quality add-on, In-house analytics project, Another external vendor
• Under what conditions would your team decide to keep the current approach rather than switching to a new platform?
• Has anyone inside your organization proposed building this capability internally instead of purchasing from an outside vendor? Options: Yes, single internal proposal, Yes, multiple teams proposed it, No internal proposal, Unsure
• Would a working integration to your vision systems and SPC data make you less likely to switch away from your incumbent? Options: Yes, Maybe, it depends, No
• Name the single proof or result that would make you change suppliers within two weeks of pilot close.

Can we actually run the pilot here?

• Do your MES, vision, and SPC systems provide APIs or scheduled extracts we can access under your security policies? Options: Yes, APIs available and accessible, APIs exist but access restricted, Only scheduled extracts available, No API or extracts available
• Identify the owner for each integration point (MES, vision, SPC) and the typical SLA for granting access requests.
• Is 90 days of historical line data, including part IDs, timestamps, defect labels, lot IDs, and key process parameters, stored centrally and permissioned for export? Options: Data is central and ready, Data exists but is fragmented, Data requires cleanup, Not available for export
• Can you commit a subject matter expert to validate field mappings and test API credentials for 4 to 6 hours per week during the pilot? Options: Yes, committed and available, Yes, but limited availability, No SME available, Unsure
• Are there regulatory approvals, data-sharing agreements, or plant access permits that typically take longer than 4 weeks to obtain for projects like this? Options: Yes, often >4 weeks, No, usually <4 weeks, Depends on region or product
• Would a missing integration endpoint prevent the pilot from proceeding? Options: Yes, pilot blocked, No, we can proceed with partial data, Depends on which endpoint is missing

The measure of success we need to see

• At what measurable change in scrap rate would your plant manager commit to a production rollout? Options: <0.5% absolute reduction, 0.5%–1% absolute reduction, 1%–2% absolute reduction, >2% absolute reduction, Provide a custom target below
• List the KPIs you need validated during the pilot, for example scrap reduction percentage, false positive rate, operator entry time, or mean time to root cause. Options: Scrap rate, False positive rate, Operator entry time, Mean time to root cause, Correlation accuracy
• Specify the maximum operator entry time that keeps cycle time acceptable, in seconds or steps. Options: <5 seconds, 5–10 seconds, 10–30 seconds, >30 seconds
• Provide the minimum monthly dollar savings your finance team needs to see to approve the production spend. Options: <$5,000/month, $5,000–$20,000/month, $20,000–$50,000/month, >$50,000/month, Not sure yet
• Name the person or role whose signature would start procurement within seven days of pilot success.

Decision steps and next practical moves

• Outline the decision steps and expected dates that would allow procurement to issue an order within 30 days if the pilot succeeds.
• Confirm whether budget exists for a production rollout this quarter and which budget owner controls that spend. Options: Budget already allocated, Budget requires reallocation, No budget this quarter, Unsure
• Provide the roles and backup approvers needed to greenlight deployment so we can plan the stakeholder invites.
• Estimate the typical response time from your IT or integration team to credential requests and API tests. Options: <24 hours, 1–3 days, 3–7 days, >1 week
• Assuming the pilot meets the targets we agree, can procurement complete contract signature within 14 days? Options: Yes, No, Need to align timelines with procurement

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

• Load 90-Day Production and Defect Data
• Ingest Machine-Vision Images and Metadata
• Connect and Sync MES Defect Streams
• Configure Defect Taxonomy and Entry Forms
• Deploy Shop-Floor Defect Capture UI
• Map Material Lot and Traceability Links
• Ingest Process Sensor and Equipment Data
• Configure SPC Rules and Real-Time Alerts
• Run Correlation Engine and Root-Cause Models
• Create Root-Cause Correlation Dashboards
• Automate Pareto and Trend Reporting
• Tune Alert Sensitivity and Reduce False Positives
• Deploy Platform to Additional Lines

Load 90-Day Production and Defect Data

• Specify the line IDs whose contiguous 90 days of production and defect records we should load (e.g., Line 1, Line A).
• Provide the export file formats you will supply for the 90-day load (choose all that apply). Options: CSV export from MES, Database export (SQL dump), Historian/columnar (Parquet), Delimited flat files, Other
• Indicate the primary key that links production rows to defect records on each line (e.g., serial number, cycle timestamp, part-id + position).
• Attach the typical per-shift or per-day row volume for the specified line(s) to help size ingestion (parts/hour or rows/day). Options: Less than 100k rows/day, 100k–1M rows/day, 1M–10M rows/day, More than 10M rows/day
• Estimate the proportion of records expected to include defect codes or annotations in your historical export (used for model training). Options: <1%, 1%–5%, 5%–20%, >20%
• Confirm the acceptance criteria for the 90-day data load in terms of record completeness and timestamp coverage (example: >=99% timestamps present, max 5% null critical fields). Options: >=99% records and <=1% missing timestamps, >=95% records and <=5% missing fields, Custom acceptance criteria (describe below)

Ingest Machine-Vision Images and Metadata

• List the camera systems or image sources on the line and their primary output (e.g., 2D inspection camera, high-speed line-scan, AOI), including any camera model identifiers you can share.
• Name the image file formats and typical resolution your vision system produces (e.g., JPEG 2048x1536, PNG, TIFF, raw frames). Options: JPEG, PNG, TIFF, Raw/Proprietary, Other
• Identify how each image is linked to a part or cycle in your current data (e.g., cycle timestamp, part serial printed on label, camera timestamp + conveyor encoder).
• Describe your image retention policy for inspection frames on the line (e.g., 30 days on local NAS, 12 months in cold storage). Options: 30 days, 90 days, 12 months, Retain indefinitely, Custom
• Specify whether metadata streams (exposure, inspector verdict, AOI bounding boxes) are exported alongside images and in what schema (CSV, JSON per image, protobuf). Options: CSV sidecar, JSON per image, Combined database table, No metadata available, Other
• Select the connection method available for image ingestion from your vision controller (choose all that apply). Options: SFTP/SMB export drop, HTTP API, MQTT/streaming, Direct NAS mount, No direct export available

Connect and Sync MES Defect Streams

• Which MES endpoints expose defect/event streams for the line (name the endpoint type: REST API, message queue, database table, or flat-file export). Options: REST API, Message queue (Kafka/AMQP), Database table, Scheduled flat-file export, Other
• How many defect code sets (e.g., station-specific defect lists) must be mapped from the MES to the platform for this line? Options: 1, 2–3, 4–10, More than 10
• Does your MES support push notifications or only scheduled pulls for defect updates on the line? Options: Push (webhook/stream), Scheduled pull (daily/hourly), Only manual exports
• Identify the field names in your MES defect payload that link to production (for example: workorder_id, operation_id, lot_id, timestamp).
• Provide the expected latency tolerance for MES-to-platform sync for real-time alerts (e.g., under 30 seconds, under 5 minutes). Options: Under 30 seconds, Under 5 minutes, Under 30 minutes, Batch-only (hourly/daily)
• Confirm the acceptance criteria for MES defect stream synchronization (for example: no more than X minutes lag and >=Y% event delivery accuracy). Options: <=30s lag and >=99% events, <=5min lag and >=95% events, Custom acceptance (describe)

Configure Defect Taxonomy and Entry Forms

• Specify the target taxonomy depth for defect codes on the line (levels of granularity, e.g., category > family > subtype). Options: 1 level (broad), 2 levels, 3 levels, 4+ levels
• Provide three representative defect examples and the current label operators use on the shop floor (use case: map to taxonomy).
• Identify whether defect entry on the line must support image attachment or only text/code selection. Options: Text/code only, Text + image upload, Image-only with auto-tag
• Describe the expected operator selection time target for defect entry on the tablet or HMI (the evaluation target is under 10 seconds). Options: Under 5 seconds, Under 10 seconds, 10–20 seconds, No constraint
• State whether you require conditional entry logic on forms (e.g., selecting 'scratch' reveals depth and length fields). Options: Yes, No
• Select who will own taxonomy governance after deployment. Options: Quality engineering team, Process engineering team, Shared governance, Needs definition

Deploy Shop-Floor Defect Capture UI

• List the operator devices that will run the capture UI by model or OS (e.g., Android tablet Model X, Windows HMI, iOS).
• Name the authentication method operators will use to log defects on the shop floor (e.g., badge scan, username/password, single sign-on). Options: Badge/scan, Username/password, Single sign-on (SSO), No authentication
• Identify the required offline behavior for the capture UI if network is lost (e.g., cache locally for X minutes, disable entry). Options: Cache and sync later, Prevent entry when offline, Allow entry with manual reconciliation
• Describe any accessibility or language requirements for operator screens on the line (languages, icon-only modes, large buttons).
• Choose the target maximum keystrokes or taps per defect entry you need to meet the cycle-time constraint. Options: 1–2 taps, 3–4 taps, 5+ taps, No constraint
• Provide the planned training window for operators on the new UI prior to go-live (hours per operator or scheduled training dates). Options: <1 hour, 1–2 hours, Half-day, Full-day or more

Map Material Lot and Traceability Links

• Identify the source of lot/traceability IDs on the line (ERP lot number, MES lot, barcode printed on pouch, supplier lot). Options: ERP lot, MES lot, Barcode on part, RFID tag, Other
• Provide the scan method available at the point-of-use for lot capture (handheld scanner, fixed barcode reader, operator entry). Options: Handheld scanner, Fixed reader, Operator manual entry, Vision-based OCR, RFID
• Specify the trace depth required downstream and upstream (for example: link defect back to supplier lot and forward to affected workorders). Options: Supplier lot only, Supplier + previous processes, Full upstream + downstream genealogy
• Describe the formatting of lot IDs you use (prefixes, date codes) if parsing rules are required for mapping.
• Select whether batch-to-unit-level traceability is required (per-part serial number linked to lot) or lot-level only. Options: Per-part serial to lot, Lot-level only, Mixed
• Assign the owner responsible for providing lot master-data and batch history during rollout (team or role). Options: Quality engineering, Material planning, MES admin, Other

Ingest Process Sensor and Equipment Data

• List the key sensor types and tags on the line to ingest (e.g., torque sensor tag TQ01, temperature probe TMP_A, vibrational accelerometer AX1).
• Provide the sampling frequency for each sensor class you plan to ingest (e.g., 1Hz, 10Hz, 100Hz, event-driven). Options: Event-driven, 1Hz, 10Hz, 100Hz, Higher
• Identify the historian or PLC connection method available for sensor data (OPC-UA, historian export, MQTT, direct database). Options: OPC-UA, Historian export, MQTT/stream, Direct DB access, Other
• Describe time-synchronization constraints between sensor data and inspection frames (do you provide a common clock or timestamps need alignment?). Options: Common synchronized clock, Timestamps need alignment, No synchronization available
• Indicate whether equipment changeover and tool-event logs are available to correlate with sensor shifts (yes/no). Options: Yes - tool-change events available, No - tool-change not logged, Partial coverage
• Specify retention and archival requirements for high-frequency sensor streams after ingestion (e.g., raw for 30 days, downsampled thereafter). Options: Raw 30 days then downsample, Raw 90 days, Keep raw indefinitely, Custom

Configure SPC Rules and Real-Time Alerts

• Select the statistical process control (SPC) rule set you want applied initially (for example: basic control limits, Western Electric rules, custom multi-rule). Options: Basic control limits, Western Electric rules, Custom multi-rule set, No SPC rules
• Choose the sources for the SPC metrics on the line (inspection measurements, process sensors, tester outputs). Options: Inspection measurements (vision), Process sensors, Test fixtures, Combined
• Indicate alert channels for SPC violations and root-cause flags (choose all that apply). Options: Email, SMS, MES alarm, Operator HMI popup, Third-party messaging
• Describe the debounce windows or alert suppression you require to avoid repeated alarms for the same event (example: suppress identical alert for 5 minutes). Options: No suppression, Suppress for 1–5 minutes, Suppress for 5–30 minutes, Custom
• Identify the team or role that will approve SPC rule changes after deployment. Options: Quality engineering, Process engineering, Production supervision, Cross-functional governance
• Set the initial sensitivity preference for alerts to balance detection vs noise. Options: Conservative (fewer alerts), Balanced, Aggressive (sensitive)

Run Correlation Engine and Root-Cause Models

• Identify three known historical root-cause relationships we should validate during model runs (for example: supplier lot X -> spike in scratch defects; tool #5 -> burr generation).
• Provide the minimum labeled examples per defect type you can supply for model validation (number of defect records with ground-truth labels). Options: <50 examples, 50–200, 200–1,000, >1,000
• Describe the expected runtime SLA for model re-scoring on a line's 24-hour dataset (e.g., under 1 hour, under 4 hours). Options: Under 15 minutes, Under 1 hour, Under 4 hours, No SLA
• Indicate whether you require causal-style outputs (e.g., ranked probable causes with confidence intervals) or only correlation scores. Options: Ranked probable causes, Correlation scores only, Both
• Clarify any forbidden data fields for model training due to privacy or supplier restrictions (for example: supplier cost fields, PII). Options: No forbidden fields, Some supplier fields restricted, PII restricted, Other
• Approve the schedule for initial model runs and validation checkpoints during the pilot (give target dates or cadence). Options: Weekly runs, Bi-weekly runs, Single run at pilot end, Custom schedule

Create Root-Cause Correlation Dashboards

• Select the core KPIs you need on the root-cause dashboard for this line (choose up to five). Options: Defects per million, Scrap rate (%), Top defect causes, Time-to-root-cause (hours), Affected lot count, Other
• Describe the drill-down path an engineer should take from dashboard signal to evidence (example: KPI -> defect trend -> linked images -> sensor traces).
• Identify dashboard user roles that need access and their primary view (quality engineer: full filter; supervisor: summary). Options: Quality engineer (detailed), Process engineer (analytical), Supervisor (summary), Operator (instructions)
• State the desired refresh cadence for dashboards during pilot and production (real-time, 5-minute, hourly, nightly). Options: Real-time (<30s), 5-minute, Hourly, Nightly batch
• Select export formats required for dashboard reports (PDF, CSV of raw evidence links, Excel, scheduled email snapshot). Options: PDF, CSV, Excel, Email snapshot, API access to metrics
• Recommend any pre-built widgets or visualizations you consider mandatory (for example: Pareto by cause, heatmap of line positions).

• Subscription Agreement
• Order Form & Payment Schedule
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Data Processing Agreement (DPA)
• Integration & Data Access Authorization
• Pilot Acceptance Certificate
• Service Level Agreement (SLA) Addendum

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Quarterly Success Review

• Close resolved incident records and update the root-cause knowledge base with confirmed correlations.
• Tune SPC thresholds to reduce alert noise while preserving meaningful signals.
• Patch MES integration to capture missing fields used in root-cause correlations and confirm data flow.
• Restate acceptance criteria and numeric targets from Solution Scope
• Produce a documented acceptance decision against the Solution Scope targets.
• Agree remediation tasks, resolution dates, and a short-term realization tracking plan for any unmet criteria.
• Publish the acceptance decision document with the recorded outcomes and next steps.
• For any failed criteria, define remediation steps with deadlines and track progress to closure.
• Establish the ongoing review cadence and the dashboard views that will be used for realization tracking.
• Metric trends and variance analysis
• Confirm whether key metrics remain within Solution Scope targets and surface any long-term trends.
• Ensure outstanding blockers are progressing to resolution and that operator feedback is tracked into the enhancement backlog.
• Prioritize enhancement requests and publish a delivery timeline for the next quarter.
• Schedule operator refresher training sessions where logging time or taxonomy use is slipping.
• Re-confirm agreed success criteria and owners
• Confirm deployment health and data pipelines are operational for live use.
• Document incumbent wind-down status and next steps to prevent dual-system usage.
• Agree immediate remediation actions for any live blockers with clear completion dates.
• Archive historical spreadsheet tracking and set read-only access to prevent further edits.
• Resolve any MES endpoint or ingestion errors and confirm successful downstream data flows.
• Schedule a 30-minute operator refresher on defect logging workflows and taxonomy use.
• Present first outcome data against targets
• Establish whether the primary metrics are trending toward Solution Scope targets and document deviations.
• Agree a prioritized list of corrective actions and a clear timeline to the acceptance gate.
• Adjust defect taxonomy granularity to improve operator consistency and reduce misclassification.
• Deployment and data pipeline validation
• Open issues and blocker burn-down
• Present outcome data against each criterion
• Diagnose root causes for any metric gaps
• Operator feedback and training needs
• Document pass/fail per criterion and capture the acceptance decision
• Validate known root-cause correlations
• Early adoption and usage signals
• Enhancement and feedback backlog review
• Agree remediation plan for any failed criteria
• Agree corrective actions and timeline to acceptance gate
• Incumbent system wind-down checkpoint
• Open issues and immediate remediation actions
• Close loop and define realization tracking cadence