Welcome to FirmwareFault. Before you post, before you comment, before you upvote or flag – understand this single principle that governs everything here:

Data beats emotion. Always.

This is not a support forum. It is not a place to vent about a bad update or a sluggish screen. It is an evidence lab – a structured archive of measurable, reproducible, and verifiable cockpit performance data. Your frustration is valid. But without data, it is just noise. And noise helps no one.

We enforce a simple, non‑negotiable standard. This post explains how it works – our flagging conventions, the quality bar we expect, and the one rule that underpins every thread.

The One Rule – If You Claim It, Show It

This is the only rule that applies to every post, every comment, every reply.

If you make a claim about performance, behaviour, or a regression, you must attach evidence.

That evidence can be:

• A screenshot of the OS version and the problem.

• A video (slow‑motion preferred) showing the behaviour.

• A log file (ADB, CAN, OBD‑II) – anonymised if needed.

• Measured numbers – frame rates, latency in milliseconds, temperatures, battery percentages.

• A clear, step‑by‑step reproduction guide that anyone can follow.

What is not evidence:

• “I feel it is slower.”

• “Everyone knows this update is bad.”

• “My friend had the same issue.”

• “It is obviously a design flaw.”

If you cannot back your claim with something tangible, your post will be flagged and moved to the Talk / Off‑Topic lounge – or removed entirely.

Why this rule exists: A forum full of anecdotes is worthless. A forum full of structured, evidence‑backed reports is a reference library that buyers, engineers, and owners can trust.

What We Mean by "Evidence" – A Practical Guide

We do not expect everyone to have a thermal camera or an oscilloscope. But we do expect you to provide something that moves your post from opinion to observation.

Minimum Acceptable Evidence

• A clear photo of the screen showing the issue (e.g., error message, lag animation, version number).

• A description of the exact steps you took – numbered, if possible.

• The OS version and chip model – found in Settings > About.

Good Evidence

• A slow‑motion video (120fps or 240fps) showing the behaviour with a timestamp or frame counter.

• A comparison – before and after an OTA, or against another vehicle.

• A log excerpt – even a few lines from ADB or a CAN log can be illuminating.

Excellent Evidence

• Reproducible test methodology – another owner can follow your steps and get the same result.

• Measured numbers – frame rates, latency in milliseconds, battery consumption figures, temperatures.

• Multiple data points – e.g., 10 runs under the same conditions.

If you are not sure whether your evidence is sufficient, post it anyway. The community will help you improve it. But if you post nothing but emotion, expect your thread to be flagged.

Flagging Conventions – How the Community Maintains Quality

We rely on community flagging – not pre‑moderation – to maintain quality. Every member can flag a post for the following reasons:

Flagging is anonymous, but abuse of the flagging system (e.g., flagging a well‑evidenced post out of disagreement) will result in warnings and potential restrictions.

The Quality Bar – What We Expect from a Good Post

A high‑quality post on FirmwareFault meets the following criteria:

1. Complete metadata – chip model, OS version, vehicle details are present.

2. Clear scenario – the situation is described with enough context to understand when and how the issue occurs.

3. Reproducible steps – a numbered list that anyone can follow.

4. Evidence – at least one form of objective documentation (screenshot, video, log, measurement).

5. Measurable outcome – if possible, a number (e.g., "latency increased from 78ms to 95ms") rather than a vague description ("it feels slower").

Posts that meet this bar are marked [VERIFIED] – a badge that tells readers this is a reliable data point.

Posts that do not meet the bar but show good faith effort are marked [NEEDS WORK] – and the community helps the author improve it.

The Role of Moderators – Enforcers of the Standard

Moderators are not content censors. They are standards enforcers. Their job is to:

• Ensure that every post has sufficient evidence.

• Move unstructured posts to the appropriate format.

• Merge duplicate threads to centralise data.

• Remove posts that violate the "if you claim it, show it" rule after a warning period.

Moderators do not:

• Censor opinions – as long as they are backed by data.

• Take sides in brand debates – they only care about evidence quality.

• Remove criticism of a brand – unless it is baseless.

If a moderator flags your post, do not take it personally. They are not attacking you – they are defending the integrity of the archive.

What Happens if You Do Not Follow the Rule

We are not trying to silence anyone. We are trying to build a useful resource. If your post is flagged, take it as an opportunity to improve it – not as a personal attack.

The Community Philosophy – We Are All Researchers

Every post on FirmwareFault is a research contribution. You are not a "user" – you are a co‑investigator. The person who reads your post tomorrow is not just a fellow owner – they are a buyer making a decision, an engineer looking for a regression, or a journalist fact‑checking a claim.

That is the standard we hold ourselves to. That is why we demand evidence. That is why we flag unstructured posts. That is why we do not tolerate baseless claims.

Because a complaint without data is just noise. A complaint with data is a signal.

The Final Rule – In One Sentence

If you claim it, show it.

Not "try to show it." Not "I will show it later." Show it when you post. A photo, a video, a log, a number – something that another person can see, verify, and trust.

If you cannot show it, consider whether your post belongs in Talk / Off‑Topic. And if you are not sure, post it anyway – the community will help you turn it into evidence.