This article walks through the full workflow from submitting a correction request to receiving a revised report. It covers how evidence is reviewed, what the three possible field outcomes mean, and why some fields cannot be populated regardless of how much research is applied. It also explains what a revised report can and cannot be used for, including hard limits around legal title and physical matching numbers. Understanding both the process and its limits will help you submit a complete correction request and interpret your results with realistic expectations.
ClassicDecoder reconstructs classic car build sheets by combining supported VIN decoding with available vehicle specifications, historical records, auction or listing evidence, manual research, and reviewed customer corrections where relevant. Because the process depends on what records survive and what can be verified for a specific vehicle, the result is a reconstructed report rather than an original factory-issued document, and some fields may remain qualified or unavailable. For a broader explanation of the reconstruction process beyond ClassicDecoder’s own workflow, see How Classic Car Build Sheets Are Reconstructed.
What a Correction and a Revision Actually Mean
The two terms sound interchangeable, but they refer to two separate stages of the same process.
Think of it this way: you correct a field, and you receive a revised report. These are two stages of the same process, not two names for the same thing. The mechanism section below explains what happens between those two stages.
One important point before moving on: not every correction produces a fully populated revised report with all fields resolved. A correction may result in a field being confirmed with better data, qualified with partial evidence, or marked as unresolved because no verifiable historical record exists. That outcome is addressed in detail in the next section.
How the Correction and Review Process Works
ClassicDecoder’s automated systems generate the initial build sheet by decoding your VIN and cross-referencing multiple historical sources. The correction workflow acts on that output when something in the result is missing, incomplete, or wrong.
The process moves through five stages. Before reaching out to support, check whether your situation matches one of these common correction triggers:
A field is blank or shows “unavailable” but you have documentation suggesting the data exists- A field contains an option, code, or specification that does not match your vehicle’s known configuration
- A field reflects an automated decoding error (a misread digit, a transposed code, or an incorrect cross-reference)
- A field uses a description that appears inconsistent with other confirmed fields in the same report
- A field was populated by a prior run and subsequent regeneration introduced a discrepancy
If any of these apply, you are ready to submit a correction request.
Step 1 - Submitting a Correction Request
Contact ClassicDecoder support and include the following in your request:
- Your report identifier or VIN reference
- The specific field in question (name it clearly)
- A description of what the field currently shows and what you believe is incorrect or missing
- Any documentation you have that relates to the field (invoices, window stickers, registry entries, or other records)
ClassicDecoder support is available 24 hours a day, 7 days a week, including holidays. Submitting a complete request with all four components above helps the support team move directly to evidence review without a back-and-forth to gather basic information. Submission starts the process. It does not guarantee a corrected field, because the outcome depends on what evidence the review uncovers.
Start With the Vehicle VIN
Research the vehicle first, then contact support with the report identifier, the field in question, and any supporting documentation.
Step 2 - How Your Evidence Is Reviewed
When the support team receives your correction request, they review any documentation you submitted against available independent historical records. These two evidence types do not carry equal weight.
Step 3 - Regeneration, Manual Research, and Assisted Completion
Regeneration and manual research are two different things. Regeneration is an automated system retry. When a field is flagged for correction, the system may attempt to pull fresh data from its source databases. This process is automated and does not involve a person researching the field. Manual research, by contrast, involves the support team actively investigating historical references, production records, registry data, and other available sources to find evidence that the automated system could not surface on its own.
Step 4 - How Outcome Decisions Are Made
After evidence review and research, the support team assigns one of three outcome states to each field under review.
| Outcome | Definition | Impact on Revised Report | Reason |
|---|---|---|---|
Corrected | The field has been updated based on independently verifiable evidence | The revised report reflects the updated field value | Sufficient independent evidence was found to support a specific data point |
Qualified | The field has been partially updated or annotated with a confidence qualifier | The revised report reflects partial or inferred data with appropriate notation | Evidence exists but is incomplete, indirect, or drawn from a single source without independent corroboration |
Unresolved | The field remains unpopulated or unchanged | The revised report reflects the absence of verifiable data for this field | No independent evidence exists in available records to support a specific data point |
A few points are essential to understand alongside this table.
First, “Corrected” reflects the best available evidence for that field. It does not mean the field is guaranteed to match the original factory configuration with 100% certainty. Historical records for classic vehicles are not always complete, and even verified corrections represent the strongest available evidence, not factory-certified accuracy.
Second, “Unresolved” is a valid, honest status. It means the historical evidence needed to populate or verify the field does not currently exist in available records. This is not a failure of the review process. ClassicDecoder will not fabricate data to fill a gap, and marking a field as unresolved is the accurate outcome when no independent evidence exists.
Third, if a case remains persistently unresolved after review, report credits and refund coordination through support are available as a process path. This is addressed further in the FAQ.
Step 5 - Receiving Your Revised Report
Once field decisions are made, ClassicDecoder regenerates the report to incorporate those changes. The output delivered to you is called a revised report. It reflects all field-level decisions applied during the correction review, including fields that were corrected, qualified, or left unresolved.
Turnaround and fees under the current workflow: For assisted completion cases, ClassicDecoder targets delivery within 24 to 48 hours under the current workflow. This is a service target, not a contractual deadline. Complex cases involving multiple fields or limited archival availability may require additional time. There is no additional fee for requesting a correction or receiving assisted completion under the current workflow. Both the turnaround target and the no-additional-fee structure reflect current policy and should be understood as such, not as unconditional lifetime guarantees.
What a Revised Report Can and Cannot Tell You
A revised report reflects the best available historical evidence for a specific vehicle based on surviving records and documented research. It has clear capabilities and equally clear limits. The two sections below explain both.
When Fields Stay Unresolved - and Why That Is an Honest Answer
When ClassicDecoder cannot find independently verifiable evidence for a field after review and research, that field is marked as unresolved. This is not an indication that the support team did not try. It is an honest acknowledgment of the limits of surviving historical records.
Two brief scenarios illustrate the difference between a correctable error and a permanently unresolvable gap.
Example 1 (correctable): An automated parsing error misread a VIN digit, causing the build sheet to display an incorrect engine code. When the support team cross-referenced the VIN against an independent production record, the correct code was confirmed and the field was updated. This is a correction: the data existed, the error was technical, and independent evidence resolved it.
Example 2 (permanently unresolvable): A specific dealer-order option was recorded on a paper form that was never digitized and has since been destroyed. No registry, manufacturer database, or third-party archive contains a reference to that option for this VIN. No amount of additional research can recover information from a source that no longer exists in any surviving form. This is an unresolved field, and it will remain one.
ClassicDecoder marks these fields as unresolved rather than filling them with assumed or inferred values. An unresolved status is an accurate representation of the historical evidence situation, not a service shortfall.
What a Revised Report Does Not Verify
A revised ClassicDecoder build sheet reflects available historical data reconstructed from surviving records. That is the scope of what it is and what it does.
How Report Changes Are Labeled and What the Current UI Shows
ClassicDecoder is developing field-level transparency features that will allow users to see which fields were changed, when they were updated, and what source type each data point reflects. These features, including field-level revision timestamps and source labels, are planned transparency capabilities currently in development. They are not yet consistently available in the current interface for all users.
If you need to understand exactly what changed in your revised report and why, the current path is to contact support directly. The support team can explain which fields were updated, what evidence supported each decision, and how each outcome was classified. This communication channel is the current operational workaround until in-report labeling is consistently available.