Generator Test Report Red Flags: A Buyer Triage Guide

A polished PASS PDF may still be unfit for the intended decision. Use the Test-Report Red-Flag Triage Matrix to return a correctable identity, revision, or evidence gap, require an independent check or retest when reissuing cannot repair the chain, and stop reliance while a material gap remains; an anomaly is a question, not proof of fraud or product failure. This guide checks report provenance and decision scope, while the generator FAT scope guide defines the agreed test boundary; neither document diagnoses a generator, decides conformity, or proves BEAR capability.

Report issuer, purpose, and decision role

Start before the first graph. Record who issued the report and which site did the work. Also record who wrote and sent it. Note when those roles differ. A supplier record, outside lab report, witness note, customer FAT report, and family report do not have the same scope merely because each says “test report.”

Define the intended business use in one sentence. Is the report for a technical review, milestone payment, FAT closeout, shipment decision, sample comparison, or supplier control? Name the buyer-side decision owner. Then cite the contract, purchase order, test request, or approved scope that gives the report that role.

Then preserve what arrived:

• original file and filename.
• file hash and received date.
• message, portal, or email context, without putting private mail in public records.
• stated report or test ID, revision, issue status, page count, and attachment list.
• issuer and contact shown in the document.
• any earlier version already held.

Save a questionable file before asking the supplier to replace it. A corrected report may be valid, but the old file and change trail show what changed and why. Mark a replaced file as “superseded.” Two files with the same report number but different content create a new red flag.

The boundary matters. A lab logo, QR code, stamp, or accreditation note may offer a lead. None proves that the test used the right object, method, tool, or acceptance rule. A qualified owner must verify accreditation, certification, legal status, or possible misconduct through the proper official route.

Exact tested object

Read identity before results. Compare the report with the order, approved build, test request, and serial-selection record. The project may require these fields:

• buyer, project, PO, line, supplier order, work order, and test-request references.
• generator-set name, rating, and duty basis as ordered.
• set, engine, alternator, controller, and other controlled serial IDs.
• voltage, frequency, phase, fuel, enclosure, output, controls, software, and option revisions when they matter.
• unit, sample, prototype, family, or population status.
• selection method, test site, and test date.
• photographs, nameplates, labels, worksheets, filenames, and raw records that should point to the same object.

A family-level report may support only the use agreed for that family. It does not prove that the final order unit or another build was tested. If a link is missing, record IDENTITY NOT DEMONSTRATED. Request the controlling record and name the blocked decision.

Visual similarity cannot repair an identity gap. A photo may show a generator without proving its serial, build, date, test run, or report link. The image needs a nearby controlled ID to support those links.

Evidence chain behind each conclusion

Work backward from each material conclusion. The report should point to a result row. That row should point to a calculation or direct observation. The next link is the source record, named channel or observer, approved method and rule, and the same test object.

Use a stable row key to join the evidence. Include the report or test ID, test-object ID, measured trait, run or time, instrument channel, and unit. Also link the raw-file row, calculation, report table or graph, rule, result, and deviation record.

Look for breaks such as:

• a graph with no raw table or native export.
• a summary that omits failed, stopped, or repeated segments.
• screenshots with no export ID, time basis, or unit ID.
• hidden spreadsheet formulas or values pasted without source cells.
• a calculation whose inputs, units, rounding, or conversion rule cannot be rebuilt.
• raw values and report tables that disagree.
• a conclusion that cites no supporting rows.
• files whose metadata or timestamps conflict with the stated chronology.

Do not “correct” a copied value yourself and accept the report. Record the affected field and save both values. Ask the issuer to explain the gap between the source and report. Require a controlled reissue if the report changes.

Instrument and status links to measured fields

An attached calibration certificate does not validate every value in the report. Map each result that affects acceptance to the instrument or data channel used.

Red flags include an unnamed tool or one certificate tied to unrelated data channels. An ID mismatch, unclear status, or range and unit mismatch also needs review. The same is true if the tool changed during the run. Keep generator-display values separate from reference-tool values. The phrase “calibrated equipment used” does not replace this map.

A calibration or status record alone does not prove the method, setup, data path, copied value, or result. This review does not audit the lab or judge its skill. It checks whether each reported value has the evidence path needed for the buyer's agreed use.

For values written or copied by hand, request the original sheet, author, date and time, tool ID, unit, copy check, and change log. If the source cannot link to the table, judge the result by the effect of that gap. Do not judge it by how likely the number seems.

Criteria, revisions, and acceptance authority

For each material PASS, FAIL, or ACCEPTED, find the rule and show that it was fixed before the test. Record its document number, revision, clause or row, unit, build, and place in the document order. “ISO compliant,” “manufacturer standard,” and “as required” are incomplete without the exact scope and revision.

Red flags include:

• a rule that first appears in the issued report.
• a method or rule dated after the test, with no approved review of that change.
• a family limit applied to another build with no agreed basis.
• a rule changed after the result was seen.
• a failed, untested, or not-applicable row with no rule or approved reason.
• report tables and conclusions that use different units or rules.
• an acceptance signature from a role whose authority is undefined.

Keep the roles separate. A measured result is an observation. An evaluator compares it with a rule. A witness records attendance or what was seen. A technical reviewer may approve a technical finding. A deviation owner may accept a change within a given mandate. A business release owner decides if the evidence permits the named order step. One signature covers all roles only if the contract says so.

The generator FAT scope guide explains how to lock criteria, witness points, evidence, and release effects before testing. When that pre-test control is absent, the report reviewer should expose the gap—not manufacture a criterion from a familiar standard or nearby model.

Timeline and cross-file comparison checks

Build one timeline across scope approval, the test request, tool status, test runs, stops, repairs, retests, report issue, review, changes, witness records, and signatures. A date alone says little. Its order and link to the other events matter.

Review a report issued before its source files. Also review rules or methods dated after the event, test and retest times that clash, a repair with no named retest, or a witness date that does not match attendance. A changed conclusion with no new evidence or decision record also needs an explanation.

Compare repeated fields across pages, attachments, and—where contractually available—other reports. Questions include:

• Does another customer, order, model, serial, site, or filename remain in a header, footer, photograph, property, or attachment?
• Are identical reading sequences, timestamps, photographs, or graph shapes attributed to different units or dates?
• Do old serials or filenames appear inside a new report?
• Are pages drawn from different revisions without an amendment index?
• Do fonts, layouts, image quality, or numbering change abruptly around material fields?
• Are rounded values repeated in a pattern that the raw evidence cannot explain?
• Did decimal separators, units, columns, or channel labels swap during transcription?

A template may repeat its layout and text. A font may change during editing or export. Matching values may also have a valid cause. Each point calls for a check; none proves copying or misconduct. Escalate only after you name the gap, comparison source, evidence request, and effect on the decision.

Test-Report Red-Flag Triage Matrix

Create one row per anomaly; do not bury several unrelated gaps in “report incomplete.” A useful matrix contains:

Avoid a weighted score. A polished cover and many complete rows cannot offset an open serial mismatch. Nor can they offset a missing raw-data link needed for the decision.

Write neutral notes. Prefer “serial in table 4 differs from the approved build sheet; request the unit-ID record and corrected revision trail” over “fake report.” Prefer “calibration status not linked to channel” over “uncalibrated test.” The first wording creates a task that can be closed. The second claims more than the review can prove.

Closure evidence must answer the original gap. A supplier note may explain the context, but it cannot replace a missing controlled record. A reissued PDF should name the revision, old report, changed pages or fields, reason, author, reviewer, and saved evidence set. Reopen the row if the test object, source file, rule, method, calculation, or report revision changes in a material way.

Non-compensating reliance gate

The final gate decides what this report may support—not whether the generator is good, compliant, or safe. Use the narrowest defensible outcome.

Use the outcomes precisely:

Use the BEAR generator catalogue to anchor the report to a current model record, then require the report to return the same build, rating, test-object, method, and revision fields before comparison.

• CLEAR FOR THE AGREED LIMITED USE: the required chain is complete enough for the named decision, with limitations recorded.
• RETURN FOR CLARIFICATION / REISSUE: a defined explanation or controlled correction can close the anomaly without inventing new test evidence.
• INDEPENDENT VERIFICATION REQUIRED: the decision needs a qualified external or buyer-controlled check of a material identity, calculation, file, status, or claim.
• RETEST OR NEW EVIDENCE REQUIRED: missing, invalid, changed, or untraceable evidence cannot be repaired by rewriting the summary.
• STOP / DO NOT RELY: a material blocker prevents use of the report for the named decision until the authorized owner records adequate closure.

Keep the limits after closure. A report for one sample, date, build, method, and purpose does not prove stable production, market conformity, site results, or another order's result.

Bounded evidence return and recorded decision

Send a row-based return, not a request to “improve the report.” State the report revision, unit and build, exact page or file, seen conflict, comparison source, and reason it matters. Add the evidence needed, owner, due date, next action, and blocked decision. Any reissue should keep the old ID and change trail.

The return pack should answer each open matrix row. It should link the exact object and build, cited method and rule revisions, raw evidence, tool and channel map, status records, and change or retest trail. It also needs a controlled reissue or decision signed by the role with that authority. List each missing item as an open row. Do not hide it in a new cover letter.

Avoid these review failures:

• accepting format, logos, stamps, or a certificate as proof that a result is valid.
• assuming every gap is fraud.
• comparing different builds, methods, units, or scopes as if they were the same.
• accepting a polished new report after the old file and source trail vanish.
• treating witness attendance as technical or business approval.
• ignoring replaced files or mixing pages from several revisions.
• losing the original file, hash, message context, and attachment list.
• using the report to infer performance beyond the pre-agreed test and identified object.

The final decision record should name the report revision, allowed use, unit and build, matrix rows, open and closed gaps, closure evidence, reviewers, roles, limits, release effect, and date. Send load-state or trend issues back to the agreed FAT scope or another qualified technical owner. Use the pre-shipment inspection checklist for wider order issues. Neither review replaces the other.

For a BEAR-specific inquiry, send Miya the order/configuration identity, report ID and revision, intended decision, affected fields, evidence requested, and open triage rows. BEAR report availability, testing arrangements, instrument/status records, underlying evidence, reissue or retest options, and authority for the exact order remain to be confirmed.