Pre-A Gate: Data-Derived Spec & Evaluation Baseline Alignment

Pre-A Gate: Evaluation Baseline Alignment

Data-Derived Spec: Decision on evaluation baseline, not on performance

January 12, 2026 | Technical Department

Current Development Context

Pre-A Development Phase: Initial functional verification.

Customer Specification Status: Not yet received/finalized.

Data Availability: Detailed DOE (Design of Experiments) data collected.

Gate Requirement: We need an objective baseline to proceed, despite missing customer input.

The Standard Process (Known Spec)

In a standard workflow, the target is fixed before evaluation begins.

Customer Requirement Available

Fixed Performance Target Set

Result Evaluated as Pass/Fail

The Pre-A Challenge: No Targets

Without a FIXED target, we cannot use 'Pass/Fail' criteria.<br><br>We must rely on identifying FEASIBLE REGIONS.<br><br>The goal shifts from 'Meeting Spec' -> 'Defining Capability'.

Concept: The Data-Derived Spec

Data replaces spec input — temporarily

We use DOE data to establish the 'field of play', not to score a goal.

Evaluation is based on consistency with observed trends, not arbitrary numbers.

This allows development to proceed through the Gate without stalling for customers.

From DOE Data to Spec Boundaries

INPUT: DOE Data

• Valid Test Conditions<br>• Observed Performance Bands<br>• Dominant Trends & Physical Limits

OUTPUT: Data-Derived Spec

• Evaluation Boundaries (Min/Max)<br>• Decision Criteria<br>• Kill / Go Reference Lines

Scope of the Data-Derived Spec

What is included vs. What is excluded

✔ Valid Condition Ranges (Temp, Voltage)<br>✔ Performance Boundaries (Safe Zones)<br>✔ Anomaly Detection Criteria

✖ Fixed Performance Targets<br>✖ Customer Satisfaction Index<br>✖ Final Mass Production Guarantees

Visualizing the Spec: Band vs. Line

Instead of a single target line, we define an 'Accepted Band' derived from the DOE variance.

From Customer Spec to Data-Derived Spec (Pre-A Gate)

Decision on evaluation baseline, not on performance

Customer Spec Available

If customer spec is available:<br>• Customer requirement defines spec<br>• Development targets are fixed<br>• Data is evaluated against spec

Our Case: No Customer Spec

• No fixed performance target<br>• DOE data available (Pre-A)<br>• Observed trends & feasible ranges

Data replaces spec input — temporarily

DOE Data ➔ Data-Derived Spec:<br>• Evaluation boundaries<br>• Decision criteria<br>• Kill / Go reference

Today’s Gate Discussion

❓ Do we agree to use:<br>These data-defined bands<br>As the temporary evaluation spec?

✔ Agree ➔ Proceed with aligned basis<br>✖ Disagree ➔ Redefine boundaries

This discussion is about agreeing on the evaluation baseline — not about meeting a customer requirement.

Action Items & Next Steps

Formal Agreement: Baseline spec adoption for Pre-A Gate.

Documentation: Update evaluation report to reference 'Data-Derived Spec'.

Next Phase: Re-evaluate baseline upon receipt of official Customer Spec.