Diagnostic Disclaimer
OBSERVE → VERIFY → EXPLAIN. OBDVeloce organises diagnostic evidence so you can review what was observed, its context and its limits. It does not guarantee a diagnosis, roadworthiness, vehicle safety or a correct repair.
- Evidence first, conclusions second
- Explicit rules, not a model
- Not a replacement for inspection
Coming soon for Windows. This page explains the product’s diagnostic limits, not a right to software access or legal advice.
It organises evidence and shows its working.
Engine Fault Scan and Guided Diagnostic are separate capabilities. SmartReport uses accepted evidence from completed diagnostic runs; a fault scan does not automatically become a SmartReport.
Engine Fault Scan
Evidence ledReview available standard stored, pending and permanent fault codes, plus trusted enhanced coverage for the supported Engine ECU only. A code is evidence to investigate, not a diagnosis. An empty fault-scan result is not proof of a healthy vehicle.
Guided Diagnostic
Collect supported measurements under guided operating conditions. Interpretation is limited by the configuration, available signals, capture quality and conditions of the run.
SmartReport + PDF
Review accepted evidence from completed diagnostic runs in a structured report, with local PDF export. Explicit rules interpret that evidence; an arbitrary saved session is not automatically eligible for this report.
Records the limitations of each capture
A report states what it does not establish, in the report itself. A limitation that only exists in documentation elsewhere is a limitation a reader will miss.
Documents evidence that was not available
Missing or insufficient evidence limits a finding. An absent signal must not be filled with an invented measurement or treated as proof that a component has failed.
The boundary, stated plainly.
V1 reads diagnostic evidence. It does not perform the operations below.
It does not diagnose every vehicle fault
The software reads the signals a supported configuration returns for the selected group. A fault that produces no recognised signal in that scope will not appear, and its absence from a report is not evidence that the vehicle is sound.
It does not replace a technician
A report supports investigation. Inspection and appropriate checks are still needed to establish a fault and decide what work is necessary.
It does not guarantee a repair outcome
Nothing here promises that acting on a report will resolve a problem. The software does not verify a repair, and a subsequent capture describes the new evidence rather than confirming the old conclusion.
It does not predict component life
No remaining-life estimate, failure forecast or service-interval prediction is produced. A captured value describes the moment it was captured, not what the component will do next.
It does not perform ECU coding or programming
The normal workflow reads. It does not code, programme, align proxies, write adaptations, control actuators or flash firmware.
It does not tune or remap
V1 is read-only. It does not alter engine calibration or provide tuning, remapping or firmware-flashing operations.
It does not clear fault codes
V1 does not clear stored fault codes or reset counters. Preserve fault-code evidence for further checks.
Model scope is not configuration approval
V1 is limited to Alfa Romeo Giulia/Stelvio 2.2 JTD/Multijet. The documented 2020 Stelvio / Bosch EDC17C69 reference does not validate every year, ECU software or adapter within that scope.
OBDVeloce helps you organise diagnostic evidence. It does not replace professional mechanical inspection or guarantee a repair decision.
From recognised evidence to a human decision.
This describes interpretation of accepted evidence within a completed diagnostic run. It does not join Engine Fault Scan and Guided Diagnostic into an automatic sequence.
Recognised evidence
The starting set is what the vehicle actually returned and the software recognised: signal values, their range over the capture, the duration, the selected group and the operating context. Anything requested but not returned is recorded as missing rather than omitted.
Rule evaluation
Explicit rules are applied to that evidence. They are written rules with stated conditions, not a model, not a learned weighting and not a probability. A rule that has insufficient evidence to evaluate does not guess; it reports that it could not be evaluated.
Transparent interpretation
Each finding names the evidence that produced it, so the reasoning can be followed and disagreed with. A conclusion you cannot trace is a conclusion you cannot check, which on a diagnostic report is worse than no conclusion at all.
Recorded limitations
What the report does not establish is written into the report: the scope it covered, the evidence that was missing, and the conclusions that were therefore withheld. This travels with the findings rather than sitting in documentation the reader may never open.
Professional judgement
A person must assess the findings alongside symptoms, physical inspection and other relevant checks before deciding on repairs. The software does not make that decision.
Missing evidence narrows a conclusion. It never invents one.
When required evidence is absent, the interpretation becomes smaller rather than less certain-sounding. A finding is stated with its limitation, or withheld entirely and reported as insufficient data. What does not happen is a value being estimated to complete the picture.
Educational illustrations on this site are separate from actual SmartReport/PDF output and recorded software screenshots.
What constrains an interpretation.
These are not failures. They are the conditions under which the evidence was collected, and each one changes what a report can honestly conclude.
An unconfirmed configuration
Compatibility is configuration-specific: the vehicle, ECU family and software, protocol and adapter all take part. A configuration that has not been reviewed may return fewer recognised signals, different values, or none at all.
Every later limitation follows from this one. Where the configuration is unreviewed, no interpretation should be treated as characteristic of that vehicle.
Signals not returned
A requested signal may be unavailable on a configuration, or unsupported in the current scope. It is recorded as missing.
Findings that depended on it are narrowed or withheld.
An interrupted capture
An interrupted capture may leave incomplete evidence. Saving a session does not mean its evidence has been accepted for SmartReport.
Review run completion and evidence acceptance before relying on a report.
Connection quality
An unstable serial link produces fewer samples and more gaps, without necessarily failing outright.
A thin dataset supports a thinner conclusion, which the report states.
Operating conditions
Each group has a recommended condition and duration. Idle-only data cannot demonstrate behaviour that appears under load.
A reading is characteristic of the condition it was captured in, and of nothing else.
An incomplete dataset
Too few recognised samples leaves insufficient basis for deterministic interpretation of the selected group.
Insufficient data is reported, and another focused capture may be recommended.
None of these limitations is hidden from the report that carries them. A reader should be able to see what constrained a finding without having to come to this page to learn that constraints exist.
Where your responsibility begins.
The software can tell you what a capture contained. It cannot maintain, operate or inspect the vehicle, and those remain with the person who owns it.
Vehicle maintenance
Servicing, wear items and the general mechanical condition of the vehicle are yours to keep up. A diagnostic capture describes evidence at a moment; it is not a maintenance record and does not substitute for one.
Safe operation during a capture
Do not operate the laptop while driving. Keep cables clear of pedals and moving or hot parts, provide ventilation when the engine runs, and stop if safe conditions cannot be maintained. Only attempt guided conditions when it is safe to do so.
Physical inspection
A report is evidence to bring to an inspection, not a replacement for one. Where a finding suggests a fault, confirming it physically is the next step and it happens away from this software.
A suitable adapter, correctly connected
The connection is yours to establish and to keep stable. An adapter that cannot hold a connection produces poor evidence, and poor evidence limits every conclusion drawn from it.
Workshop and manufacturer procedure
Where a manufacturer or workshop procedure applies to a repair, that procedure governs. Nothing in a report overrides it, and nothing here should be read as authorising a deviation from it.
The software is responsible for describing the evidence honestly, including what it did not find. Deciding what to do about a vehicle remains with you and the professionals you involve.
Questions about this boundary.
What does this disclaimer explain?
It explains how far diagnostic evidence can be used and what still needs checking. It is not legal advice and does not grant software access, certify a vehicle or approve a repair.
How far can I rely on a report?
As far as the evidence it names, and no further. A report tells you what was captured, what the rules concluded from it, and what it does not establish. Within that scope it is reproducible and checkable. Outside it — other systems, other conditions, evidence that was never collected — it says nothing, and its silence is not reassurance.
Why will it not simply tell me what is wrong?
Because in most cases the captured evidence does not settle it, and a tool that answers anyway is producing confidence rather than diagnosis. Recognised signals from one group, over one capture, in one operating condition, will often narrow a question considerably without closing it. Presenting that narrowing as a verdict would make the software feel more useful and be less so.
What happens when evidence is missing?
The conclusion gets smaller, not vaguer. A finding that depended on the missing signal is stated with its limitation or withheld, the gap is recorded in the report, and another focused capture may be recommended. No value is estimated to fill the space, and a repeatedly missing signal is not treated as evidence of a failed component.
Does OBDVeloce clear fault codes or change anything on the vehicle?
No. V1 reads diagnostic information; it does not clear faults, reset counters, code or programme control units, write adaptations, operate actuators, force regeneration or flash firmware. Diagnostic requests and responses are part of reading, not a promise of passive monitoring.
Who is responsible for a repair decision?
You are, together with whoever inspects and works on the vehicle. The software's responsibility is to describe the evidence accurately, including its gaps, and to avoid stating more than the evidence supports. It does not authorise, recommend or verify a repair, and a report should be treated as one input to that decision rather than the decision itself.
How compatibility is decided, what a report contains section by section, and how sessions and reports are stored are each covered on their own pages rather than repeated here.
Understand the scope before you rely on it.
This page describes the boundary. These three show what sits inside it: which configurations are reviewed, what a report actually contains, and where to ask when something does not fit.