DBaD explained
Can a decision still be trusted after it's been approved?
Most systems judge decisions once. DBaD tracks whether trust should continue over time.
This isn't about whether something is "right." It's about how decisions evolve, spread, and break.
Why it matters
Start here
Use the path that matches how skeptical or technical you want to be.
Core Idea
DBaD is a governance protocol for trust over time.
It does not just evaluate one action. It tracks whether trust should continue as decisions evolve across dependency chains, actor handoffs, verification steps, and risk changes.
Key principle: Trust should not travel farther than it deserves.
It does not promise perfection. It makes failure visible.
DBaD distinguishes between constraints that block actions and conditions that remain visible for audit and review.
What DBaD Solves Now
- Verifier independence
- Actor continuity
- Trust trajectory constraints
- Propagation integrity
What DBaD Does Not Fully Solve Yet
- Cross-chain coordination attacks
- Parallel trust orchestration
- Identity laundering or sybil-style behavior
- Global intent reconstruction
DBaD separates what is enforceable now from what remains research.
DBaD Technical Overview
DBaD (Decisions by Auditable Design) is a protocol for governing trust inheritance across structured decision traces.
Traditional systems evaluate outputs statically. DBaD instead evaluates lineage integrity, actor continuity, verification independence, and risk trajectory over time.
A decision is not treated as a single event. It is treated as a trace composed of actions, dependencies, actors, and verification steps. Trust is not assigned once; it is propagated.
DBaD enforces a small number of deterministic constraints: trust cannot propagate across broken continuity, verification must be structurally independent, trust inheritance is gated by trajectory changes, and unresolved lineage reduces downstream trust.
Instead of saying, “this output is safe,” DBaD says: “this output may or may not inherit prior trust, based on how it got here.”
The current public runtime now includes proof-backed examples, deterministic validation, and a structured logic-review reporting path through /break-dbad/report.
Design constraints: avoid heuristic judgment as protocol truth, avoid identity assumptions that the system cannot prove, and avoid cross-system inference for now. DBaD operates on what is explicitly recorded and structurally provable.
Skeptical Reader FAQ
“Isn't this just another AI ethics framework?”
No. Most frameworks evaluate outputs. DBaD governs how trust moves over time.
“This seems over-engineered.”
Real systems already involve chains of decisions, multiple actors, approvals, and dependencies. DBaD makes that complexity explicit and enforceable instead of pretending it is not there.
“You did not solve cross-chain coordination.”
Correct. DBaD documents that as a boundary condition. It solves what can be enforced deterministically today and separates that from what remains research.
“This can be gamed.”
Yes. DBaD assumes adversarial behavior. Its goal is to constrain trust inheritance, expose structural weaknesses, and prevent silent propagation of borrowed trust.
“This relies on subjective judgment.”
All governance systems do. DBaD does not remove subjectivity; it forces judgment into a structured, auditable form.
“Why should anyone trust this?”
DBaD is presented as a tested public draft baseline with confirmed flaws and explicitly documented limits. That transparency is part of its design.