Test limit change records should preserve old and new rules, reason, validation evidence, authority, effectivity, deployment, rollback, and affected-lot disposition before runtime limits change.
A PCBA test-limit change record must show more than the new number. It should preserve the old and new values, requirement basis, reason, affected products and stations, validation, approval, effectivity, rollback, and affected-lot disposition. Without that chain, a useful engineering update can become an unexplained shift in production acceptance.
This guide defines the change record. It does not recommend a value for any live product. Engineers must derive actual limits from controlled requirements, methods, and evidence.
Open Test Limit Change Records Before Editing Runtime Rules
Give the proposal an ID and status. Record requester, date, product, revision, variant, test stage, parameter, station, program, fixture, and current baseline. State whether production remains allowed, runs under containment, or stops while the proposal is reviewed.
Describe the trigger with evidence. Triggers can include a requirement change, method correction, measurement uncertainty review, fixture or instrument change, software defect, customer instruction, repeated false fail, suspected false pass, or an investigation. Avoid “improve yield” without the data and risk behind it.
Preserve the runtime state before modifying it. Capture the loaded program, limit table, value, units, comparison rule, station, and timestamp. That evidence establishes the affected-lot boundary if the investigation later finds a problem.
Record old and new values without losing context
List the parameter, old lower and upper limits, new lower and upper limits, units, inclusive or exclusive boundaries, nominal value, rounding, and error-state handling. If one side does not apply, mark it explicitly. A blank field can be mistaken for zero or no control.
Record changes to stimulus, test point, calculation, timing, averaging, filter, or display precision beside the numeric limits. A value can remain unchanged while the method changes its meaning. Treat those method changes as part of the same decision.
When software calculates the limit, record formula, constants, input source, code or configuration version, and representative output. Do not paste only the displayed result.
Link the reason to an authorized source
Identify the requirement, drawing, specification, engineering analysis, customer instruction, or approved investigation that supports the change. Add revision, section, owner, and approval state. Development data can support a proposal but should not silently become a production requirement.
Explain the risk in both directions. A wider band may reduce false failures while increasing false-pass exposure. A tighter band may improve detection while rejecting conforming units. State the consequence and the person authorized to accept it.
If the change responds to a design update, connect it to PCBA engineering change control . The test record should not become the only evidence that the product requirement changed.
Change field
Required content
Evidence
Block when
Trigger
Observed issue, request, or requirement change
Investigation, specification, or approved instruction
Reason is only a target yield
Old baseline
Values, units, method, program, station scope
Runtime capture and release record
Previous decision cannot be reconstructed
New baseline
Values, rule, method, configuration
Controlled candidate record
Boundary or error handling is ambiguous
Impact
Products, variants, stations, lots, records
Traceability query
Affected scope is unknown
Validation
Cases, samples, expected and observed results
Approved validation report
Key risk or boundary is untested
Approval
Names, roles, decision, date
Workflow or signed record
Authority does not cover the change
Effectivity
First build, lot, serial range, station, time
Deployment record
Old and new baselines overlap
Assess Every Affected Product, Station, and Lot
Identify products and variants that share the parameter, program, limit table, fixture, instrument, or test library. A common file can spread one change beyond the requesting product. Record explicit inclusions and exclusions.
Find stations that can load the baseline, including spares, maintenance stations, offline programmers, and backups. A central repository list may omit cached or disconnected copies. Require point-of-use readback.
Define the historical exposure. Use deployment logs, test timestamps, work orders, serial or lot records, station history, and last known correct readback. When evidence cannot narrow the window, document a conservative boundary.
Validate boundary, error, and repeatability cases
Test limit change records should show boundary, error, repeatability, uncertainty, false-pass, and false-fail checks against the proposed rule.
Test representative values below, at, and above each changed boundary. Confirm inclusive or exclusive comparison, rounding, unit conversion, displayed value, stored value, and report output. Include missing, invalid, overflow, communication-error, and aborted states.
Run known-pass and known-fail references or suitable simulations. Add repeatability, station comparison, fixture contact, environmental, and variant cases according to risk. Record sample identity and limitations.
Compare results with the requirement and independent reference where appropriate. Investigate every unexpected pass, fail, or report mismatch. A screenshot of a green result cannot replace the validation table.
Control approval and separation of authority
Name the requirement owner, test-method owner, software owner, quality reviewer, and release authority. The same person can hold more than one role only when governance permits it. An operator or administrator should not approve a product decision because they can edit the station.
Record approve, reject, return for evidence, or conditional approval. Conditional decisions need quantity, stations, operations, containment, inspection, expiration, and final closure evidence. They should not appear as unrestricted release.
The quality assurance framework defines the wider responsibilities, while the change record names the authority for the old limit, new limit, evidence, effectivity, and rollback. Do not claim certification or capability without source evidence.
Set Effectivity Without Mixed Test Rules
Define first work order, build, lot, serial range, station, or timestamp. Include time zone. Identify work in progress and results created under the candidate, old, or wrong baseline.
Release the program and limit table together when their compatibility matters. List checksums or versions, fixture, product configuration, and rollback package. At each station, read back the loaded values and run controlled cases.
Prevent old and new baselines from testing the same scope unless an approved evaluation requires it. Mark excluded stations and remove obsolete local copies. Link deployment to PCBA test execution context without treating public service information as product evidence.
Impact area
Containment
Owner
Closure evidence
Station configuration
Block wrong or unknown version
Station owner
Runtime readback and boundary test
Work in progress
Segregate by tested baseline
Operations
Identified lot and authorized next action
Completed results
Preserve and flag affected records
Quality
Review, retest, or disposition
Shared test library
Freeze propagation until scope review
Software owner
Product-by-product compatibility decision
Customer commitment
Record scope, timing, and risk
Commercial owner
Approved communication or quotation update
Rollback
Keep compatible previous package
Release authority
Restoration validation and affected-unit review
Define rollback before release
Define rollback in the test limit change records before release, including station version, lot scope, result disposition, and authority.
Preserve the previous approved package and document its compatible product revisions, fixtures, programs, and stations. A rollback should not apply an old limit to a new design or method.
State rollback triggers such as unexpected station disagreement, boundary-case failure, reporting defect, rising false pass concern, or deployment mismatch. Name who can stop rollout and authorize restoration.
After rollback, identify units tested under the candidate and determine retest, review, or disposition. Do not erase the candidate results. They explain the incident and affected scope.
Close Affected-Lot Review in the Test Limit Change Records
Record every affected lot or serial range, original result, baseline, current status, review evidence, retest where authorized, and disposition. A corrected station does not close the product review automatically.
Retain raw measurements, attempts, overrides, error states, program and limit identities, approvals, deployment logs, and rollback. Ensure authorized reviewers can retrieve them for the required period.
Close the change only when the approved baseline runs at every intended point, affected results have dispositions, and rollback evidence remains usable. State any residual limitation.
Separate an emergency containment from the final change
An urgent station problem may require a temporary stop, known-safe rollback, or bounded engineering evaluation. Record the emergency action, authority, product and station scope, start time, and expiration. Do not call a temporary value the new baseline.
Keep units tested during the emergency in an identified state. Preserve original results and configuration. Define whether they need normal-mode retest, engineering review, or another disposition after the system recovers.
Open the formal change record even when the immediate action succeeds. The final record should investigate cause, establish requirement basis, validate the candidate, assess affected lots, and obtain normal approval.
Remove emergency permissions and temporary files after closure. Verify that stations cannot reload them through cached profiles, backups, or technician folders.
Build an evidence package for review
Index the trigger, old baseline, proposed baseline, source requirement, method, data analysis, validation protocol, results, risk assessment, approvals, deployment, rollback, and affected-lot plan. Give each artifact a revision and owner.
Use summaries for decision-makers while retaining raw data. The summary should state sample source, excluded records, station and fixture, program, conditions, and limitations. Avoid charts without units, time sequence, or product revision.
Record negative and inconclusive results. A failed validation case can reveal an invalid proposal or incomplete method. Do not remove it from the package after a corrected rerun; link both attempts and explain the change.
Require an independent readback. Another engineer should reproduce the proposed values, boundary behaviour, affected scope, and rollout plan from the package alone.
Control reports, interfaces, and data migration
Verify that station screens, result files, dashboards, and customer reports use the same units, comparison operators, and value source. One interface can round or translate differently from the runtime decision.
When migrating limits to a new system, compare every parameter, product mapping, variant, lower and upper field, and error state. Run controlled values through old and new systems. Retain the migration tool and exception report.
Protect completed records from silent regeneration. A report created later should not display current limits beside historical measurements unless it labels the difference. Store execution-time limits or an immutable reference.
Validate time zones and clocks. Approval, deployment, and test timestamps need a reliable sequence to define affected lots. Record offsets and investigate station clocks that drift.
Review commercial effects without weakening the gate
A change can alter test time, fixtures, validation effort, retest, scrap exposure, and delivery. These items can affect PCBA production cost drivers . Record them for commercial review.
Keep price and schedule decisions separate from requirement authority. A commercial owner can accept cost or timing, but cannot approve a product limit unless explicitly authorized. Likewise, engineering approval does not automatically amend the quotation.
If work proceeds conditionally, state quantity, operations, test rule, extra inspection, and customer communication. Do not hide a technical exception inside a delivery note.
Close commercial actions when the purchase record, quotation, and release scope match the approved change. Keep unresolved effects visible even if technical deployment finishes.
Verify Deployment at the Point of Use
At each station, read back product, variant, program, limit table, checksum, fixture, and effective work order. A successful repository upload does not prove runtime use.
Run a known-pass, known-fail, boundary, and invalid-state case after deployment. Record expected and observed decisions. Repeat where station hardware or local configuration differs.
Check result output. Confirm that raw value, unit, executed limits, comparison, error state, version, station, and time appear in the retained record. A correct decision with an incomplete report still weakens traceability.
Sign off each intended station or document an approved exclusion. Keep spare and maintenance equipment in the inventory so it cannot re-enter service with an obsolete baseline.
Audit the change after several builds
Review failure distribution, borderline results, retests, overrides, station disagreement, and error rates. Compare them with the validation expectation. Treat a shift as an investigation signal, not automatic proof that the new limit is wrong.
Sample completed results and trace back to requirement, change record, deployment, fixture, instrument, program, and product configuration. Resolve missing links before closing effectiveness review.
Confirm affected-lot dispositions. Units under the old, candidate, wrong, or rolled-back baseline should have identified status. A station fix cannot substitute for that review.
Maintain Test Limit Change Records as Product History
Index every change by parameter, old and new values, reason, owner, approval, and effectivity. Keep links to full evidence. The log helps future engineers see whether a proposal repeats an earlier rejected idea.
Mark superseded records without deleting them. Preserve which builds used each baseline. If a requirement later returns to an earlier value, issue a new change rather than reopening an old release.
Review recurring causes. Repeated unit errors may call for interface validation; repeated emergency edits may call for stronger access control. Improve the process from evidence without making unsupported public quality claims.
Define ownership for shared test libraries
A shared function or parameter table can affect many products. Record the library version, dependent programs, product owners, validation scope, and release sequence. Do not assume that one product approval covers every caller.
When the change remains product-specific, confirm that configuration selects it correctly and cannot fall back to a default. Test intended and unintended variants. Preserve the selection evidence.
Notify every dependent owner before deployment. Record approval, rejection, exclusion, or later migration. A silent library update can create mixed baselines even when the code repository looks orderly.
After rollout, search for programs that still reference the superseded library. Resolve each result and repeat the search after backups or offline stations reconnect.
Review security and access when limits move between systems. Restrict export, edit, approve, and deploy roles. Record account changes and avoid shared credentials that prevent attribution.
Test restore procedures with a controlled copy. A backup can reintroduce an obsolete program or limit table. Document compatible restoration sets, verification steps, and release authority before any restored station returns to production.
For cross-site deployment, define the governing time zone, language, decimal separator, and unit notation. Verify that local interfaces cannot change a comparison operator or numeric scale.
Before closure, ask an independent reviewer to trace one result through the complete change chain. Repair any missing artifact or ambiguous effectivity, unresolved ownership, incorrect units, or incomplete receiver acknowledgement before final controlled release. Retain the reviewer name, date, findings, and closure evidence with the permanent controlled product test history for every affected build, station, and final review.
Frequently asked questions
Does every limit correction need a new test program?
Not necessarily. The record should identify whether code, configuration, or only a controlled data table changes and prove which source runs at the station.
Can a test engineer approve a wider limit?
Only when the responsibility matrix grants authority for the requirement and risk. Method expertise alone may not authorize product acceptance.
Should units tested under the old limit always be retested?
No universal answer applies. Engineering and quality should assess the change direction, exposure, traceability, and consequence, then document disposition.
When is a change record closed?
After validation, approval, deployment readback, affected-lot disposition, and retention checks meet the stated release conditions. Record who accepted any residual risk and where that approval can be retrieved.
Reference basis and next action
NIST SP 800-128 supports baseline and change records. NIST SP 800-171 Rev. 3 supports controlled access and audit information. They do not establish product limits.
For a change review, send the old and new rules, requirement source, method, affected scope, validation, approval roles, deployment plan, rollback, and lot status through the GNS contact form .
