Glossary

DBaD #

Short name for the Don't-Be-a-Dick governance protocol and public draft baseline.

Plain-English: DBaD is the system used here to govern how trust moves across decisions over time.

Why it matters: It turns ethical review into something structured enough to inspect, test, and revise.

Where you see it: Across the white paper, public explainer, trust-flow diagram, and evaluator.

Trust Inheritance #

Whether previously earned trust is permitted to carry forward into a later action or trace step. Any displayed result is trust-inheritance evidence, not authorization.

Plain-English: It asks whether a later action gets to borrow credibility from what came before.

Why it matters: Many failures happen when old trust keeps moving farther than it should.

Where you see it: In the evaluator trust panel, trace preview, trust-flow page, and runtime-enforcement notes.

Actor Continuity #

The requirement that a continuing trace should not silently shift to a different actor without declared transition, delegation, or fork handling.

Plain-English: A chain should not look continuous if control quietly changed hands.

Why it matters: Silent handoff lets unsafe trust propagation look like ordinary continuation.

Where you see it: In the evaluator constraint flags, sample trace walkthrough, and white paper flaw summaries.

Verification Independence #

The requirement that verification or clearance should not come from structurally entangled or self-referential reviewers.

Plain-English: A verifier should not effectively be approving its own side.

Why it matters: Without independence, clearance becomes a way to launder trust instead of test it.

Where you see it: In the evaluator constraint flags, runtime-enforcement material, and red-team findings.

Trust Trajectory #

The pattern of how risk and trust posture change across a lineage rather than at one isolated moment.

Plain-English: It checks whether the chain is drifting into worse behavior over time.

Why it matters: A harmful step can look acceptable if earlier cleaner steps are permitted to hide the drift; DBaD treats that as evidence to inspect, not permission.

Where you see it: In the evaluator constraint flags, trust-flow story, and runtime-enforcement notes.

Structured Decision Trace #

A recorded path of action, state, obligations, verification, and later review rather than a single opaque verdict.

Plain-English: It is the trace that shows how a result was reached and what still governs it.

Why it matters: DBaD is designed to preserve lineage and reasoning instead of hiding them behind one score.

Where you see it: In the evaluator trace preview, white paper, and trust-flow page.

Effective State #

The governing state that actually controls the current result after immediate and broader constraints are considered.

Plain-English: It is the state that ultimately governs what happens now.

Why it matters: The final governing result may be stricter than the immediate action review alone.

Where you see it: In the evaluator state model panel and trace preview.

Proof-backed examples #

Public examples that are linked to stored canonical traces rather than presented only as illustration.

Plain-English: The example points to a real stored trace you can inspect and validate.

Why it matters: It closes the gap between explanation and public proof.

Where you see it: On the examples page and trace detail pages.

Deterministic validation #

The current rule-based trace validation path that checks structural consistency without heuristics.

Plain-English: The system checks whether the trace follows the current explicit rules.

Why it matters: Validation is visible and repeatable, but it does not prove truth.

Where you see it: In the validation endpoint, trace detail UI, and API docs.

Action guidance #

A lightweight operator-facing summary of stored action availability, blocked actions, and recommended next steps. It is operator evidence, not trust-positive authorization.

Plain-English: It explains what the stored operator surface can do now and why, while the current validation/token contract still governs trust-positive use.

Why it matters: It reduces operator confusion without adding a full workflow engine.

Where you see it: On trace detail pages.

Blocking constraint #

A current condition that directly prevents an operator action from proceeding.

Plain-English: This is a reason the system says no right now.

Why it matters: It is distinct from a visible concern that does not currently block action.

Where you see it: In action guidance and trace-detail validation context.

Advisory concern #

A visible flagged condition that remains in the trace without directly blocking the current action.

Plain-English: The system wants you to see it even if it is not a hard stop.

Why it matters: DBaD separates review visibility from active blocking.

Where you see it: In trace detail action guidance and methodology notes.

Peer review findings #

The public summary of what multiple independent AI systems found when asked to challenge DBaD.

Plain-English: This is the visible record of convergent outside criticism.

Why it matters: It makes limits and weaknesses harder to hide.

Where you see it: On the peer-review page and in the synthesis docs.

Try to Break DBaD #

The public adversarial logic-review challenge page for testing DBaD’s trace model and governance assumptions.

Plain-English: It invites people to challenge the logic without inviting infrastructure attacks.

Why it matters: It turns scrutiny into part of the public system.

Where you see it: On the break-dbad challenge page.

Logic-review report #

A structured operator-review draft describing a logic, documentation, validation, UX, or governance issue in DBaD.

Plain-English: It is the formal way to queue a logic problem for review.

Why it matters: It keeps adversarial review inside a defined public path.

Where you see it: On /break-dbad/report.

v2.2 integrity stack #

The deterministic integrity-layer fields added after peer review: outcome, escalation response, scope limits, expectation, transition evidence, and completeness claim.

Implemented runtime layer · records claims, responses, and references without proving truth, completeness, or correctness.

Plain-English: These are the extra trace fields that make later claims and limits more visible.

Why it matters: They make the trace more auditable without turning DBaD into a truth engine.

Where you see it: In roadmap, methodology, whitepaper, trace detail pages, and the trace API.

State transition evidence #

A live v2.2 runtime field for binding non-initial state changes to deterministic evidence references.

Implemented runtime field · reference only · not proof that the transition was substantively correct.

Why it matters: It would strengthen the boundary between claimed change and evidenced change.

Evidence hash #

A live optional subfield on transition evidence for stable hashing of a declared evidence artifact or canonical string.

Implemented runtime subfield · hash format only · not proof that the artifact is true or trusted.

Why it matters: It makes evidence references harder to mutate silently.

Declared blind spots #

A live v2.2 runtime field for declaring what a decision does not cover or protect against.

Implemented runtime field · advisory only · does not prove all omissions were disclosed.

Why it matters: It makes scope gaps visible instead of leaving them implicit.

Completeness attestation #

A live v2.2 runtime field for declaring what a trace claims to cover relative to its own stated boundary.

Implemented runtime field · claim only · does not prove completeness or solve cross-trace completeness.

Why it matters: It helps separate a completeness claim from a merely coherent trace.

Expected outcome #

A live v2.2 runtime field for storing a falsifiable pre-commitment about the expected later result.

Implemented runtime field · fixed once recorded · not evaluated by DBaD as right or wrong.

Why it matters: It lets later outcomes be compared against earlier expectation without semantic inference.

Outcome status #

A live v2.2 runtime field for recording what was later observed after a decision in a simple deterministic way.

Implemented runtime field · manually updated · not a correctness or safety claim.

Plain-English: It records what happened later without asking DBaD to decide whether the result was good or true.

Why it matters: It adds post-decision linkage without turning DBaD into an outcome scorer.

Where you see it: On trace detail pages, trace cards, example trace snapshots, and the trace API.

Escalation closure #

A live v2.2 runtime field for recording how an escalated trace was resolved before trust-positive continuation resumes.

Implemented runtime field · manually updated · not proof that the closure was substantively correct.

Plain-English: It records what response was taken after escalation without claiming that the response was wise or sufficient.

Why it matters: It makes the response to failure visible, not just the escalation itself.

Where you see it: On trace detail pages, trace cards, and the trace API.

Local State #

The immediate action-level evaluation before broader chain, verification, or systemic constraints take over.

Plain-English: It shows what the action looks like on its own.

Why it matters: It helps separate the action’s direct evaluation from later governing overrides.

Where you see it: In the evaluator state model panel and trace preview.

Systemic State #

The broader governing context produced by dependency, contamination, review, or probationary conditions.

Plain-English: It shows what the wider chain context is doing to the result.

Why it matters: Trust problems often come from chain context, not just the immediate step.

Where you see it: In the evaluator state model panel and trace preview.

Boundary Conditions #

Documented limits where DBaD moves from deterministic enforcement into observation and research.

Plain-English: These are the problems DBaD does not claim to have fully solved yet.

Why it matters: The project is stronger when limits are explicit instead of hidden.

Where you see it: On the boundary-conditions page, in the white paper, and throughout public framing.

Zero-Trust Birth #

The rule that a fresh or lineage-free chain does not inherit trust by default.

Plain-English: A new chain starts without borrowed credibility.

Why it matters: It makes chain resets and orphan starts harder to use as trust-laundering shortcuts.

Where you see it: In what-DBaD-solves, the trust-flow explanation, and v2.1 research notes.

Guardrails #

Hard-stop checks (for example consent and catastrophic harm) before weighted scoring.

Plain-English: These are the checks that stop obviously unsafe actions before scoring tries to smooth them over.

Why it matters: Some failures should block or constrain a result even if other dimensions look strong.

Where you see it: In the evaluator process output, dimension review, and methodology material.

E(A) #

Ethical score for action A using weighted inputs.

Legacy scoring-model concept · not central to the current trust-propagation model.

Plain-English: This is the weighted score for one action in the older scoring layer of DBaD.

Why it matters: It remains part of the model, but now supports a broader trust-over-time governance process.

Where you see it: In methodology references and the public evaluator’s scoring section.

H/C/I/P/T #

Harm, Consent, Intent, Proportionality, Transparency.

Plain-English: These are the five supporting ethical dimensions used to review one action.

Why it matters: They make tradeoffs legible instead of hiding them behind vague judgment.

Where you see it: In the evaluator sliders, homepage supporting dimensions, and methodology pages.

Questionable band #

Score range where revision and further review are recommended before action.

Legacy scoring-model concept · supporting term rather than a core trust-propagation concept.

Plain-English: This is the range where the action is still ethically live but not ready for ordinary approval.

Why it matters: It creates room for revision, escalation, and human review before trust moves forward.

Where you see it: In evaluator decision output and older methodology/scoring references.

Stale data #

Cached payload that should be revalidated with ETag before relying on it.

Supporting implementation term · not central to the current trust-propagation model.

Plain-English: It means cached information may no longer be safe to trust without checking again.

Why it matters: DBaD depends on visible, current state rather than hidden or outdated assumptions.

Where you see it: In API and implementation reference material rather than the main public learning path.