Public review path

Try to break the logic before anyone trusts it too much.

DBaD is a public draft governance system. We want people to test whether its logic holds up under adversarial reasoning.

Challenge the logic, the trace model, the validation assumptions, the examples, the trust inheritance model, and the boundary conditions.

Find logic gaps · Preserve safe testing boundaries · Clear report path

What to do first

Inspect a proof case Start with the runtime demo or examples instead of guessing what DBaD claims.

Challenge the meaning Look for traces that validate but still create false trust or false confidence.

Report the gap cleanly Use the structured finding path so logic, UX, docs, and research issues stay distinguishable.

Start Here

Choose a safe testing path before you open the report form.

Review the runtime proof Use the audited v2.2 trace as the default starting case for logic review. Compare examples Check whether examples, traces, and trust language create the wrong impression. Challenge scoring separately Inspect the downstream advisory layer without confusing it with DBaD trace logic.

Boundary first

The invitation is intentionally narrow: adversarial reasoning about the system, not exploitation of the infrastructure.

Find a trace that validates but should not inspire trust, or a scenario where trust inheritance creates false confidence.

Find missing signals, omitted context, or cases where escalation, verification, or validation gives the wrong impression.

Do not attempt to hack, scan, fuzz, overload, or abuse the website, server, API, database, filesystem, infrastructure, or users.

We are asking for logic review, not security exploitation, credential abuse, or malicious payload testing.

Best starting example for reviewers: DBaD v2.2 Runtime Demo.

You may also challenge the DecencyMeter scoring layer separately from DBaD trace logic.

Focus on weights, assumptions, and interpretation, not the trace structure.

Open the live advisory surface at /decencymeter/demo, then use the reporting path below if the scoring model overreaches, underweights, or misleads.

The report path should be easier than overexplaining the issue in email.

Please report:

What page or trace you reviewed.
What assumption failed.
Why the trace or logic could mislead someone.
Whether it is a logic issue, documentation issue, UX issue, or future research issue.
A suggested improvement if you have one.

Use the site’s existing report path or the Report issue link in the footer.

The goal is not to prove DBaD perfect.

The goal is to make its limits visible before anyone relies on it too much.