Correctness policy

A simulator can cause serious harm when it shows a wrong result without an error. This policy explains how PWMSim responds.

What counts as a correctness incident

A correctness incident happens when PWMSim gives a confirmed wrong result for a supported feature and does not show an error. All three conditions must be true:

• The result is confirmed. The problem can be repeated from the reported netlist or share link with recorded software versions.
• The feature is supported. The limits page lists it, and the import report marks the features as exact or as an approved approximation.
• No error appeared. PWMSim silently returned a wrong value. A crash, rejected run, or clear failure message is a normal bug, not a correctness incident.

Documented approximations, clearly unsupported features, deferred tests, performance problems, and incorrect reference results do not count as correctness incidents. They may still be bugs.

How PWMSim responds

1. Confirm and publish the issue. Within 48 hours of confirmation, PWMSim creates and pins a public issue labeled correctness. It clearly lists the affected features, versions, and severity.
2. Fix the problem or change the supported limit within one release. The fix must include a test. If a fix is not ready, PWMSim marks the affected feature as unsupported until it is fixed. The public issue records this change.
3. Publish a short report. The report explains what was wrong, why existing tests missed it, and which new test now catches it. Each incident must permanently improve the test coverage.
4. Keep the evidence. The issue is unpinned after resolution, but it is not deleted.

Help check the results

If you find a wrong number, report it on the issue tracker with a netlist or share link that shows it. If the report is sensitive, use the private method described in the security policy.