Proof-backed examples

See DBaD behavior in stored traces.

Pick one case, then inspect the stored trace, validation result, constraints, and action guidance behind it.

These examples are not endorsements. They are review surfaces that show how DBaD currently handles trust over time, boundary failures, and visible runtime limits.

Pick a trace case Open v2.2 runtime demo Browse recent traces
Stored traces Validation visible Outcome is not approval Limits remain explicit

How to read these

Start with the trace Look at the recorded state, evidence posture, and validation result before reading the narrative.
Separate outcome from validation Outcome reflects later observation. Validation checks deterministic trace structure.
Use examples as review surfaces They show what the current runtime can surface and what it still cannot prove.

Choose a case first

Jump to the trace behavior you want to inspect

Each tile moves to the matching detailed example below. Validation failure means the trace structure failed a deterministic check; it is not a broad moral score.

Undeclared Actor Handoff A valid-looking action is continued by a different actor without an explicit handoff or declared delegation. escalate validation fails Chain Reset / Orphan Visibility Work resumes on an existing resource through a fresh root trace with no valid origin anchor. allow_conditional validation passes Repeated Verifier Reuse The same verifier repeatedly clears risky work on the same target across one lineage. escalate validation fails Recovery Deadlock / Dampened Escalation Repeated blocked remediation attempts keep hitting the same enforcement result without changing state. escalate validation fails Clean Low-Risk Continuation A low-risk continuation stays within the same actor context, uses clean verification, and does not materially diverge from prior lineage. allow validation passes

Last updated: 2026-05-30 UTC

Canonical public examples for the DBaD research baseline

Try to break DBaD Peer review v2.2 demo DBaD Explained What DBaD solves Trust flow Research demo Recent traces

Start here

Choose the shortest path into the runtime evidence.

Full audited walkthrough Inspect one end-to-end trace with the v2.2 integrity stack visible. Bridge to interpretation See how downstream scoring must stay separate from DBaD validation. Read the limits Review what these examples cannot prove before citing them externally.

Undeclared Actor Handoff

Scenario summary: A valid-looking action is continued by a different actor without an explicit handoff or declared delegation.

Source: stored trace trc_20260427143012_a17f4c82 (snapshot)

Trace snapshot:
  • trace_id = trc_20260427143012_a17f4c82
  • trace_version = 3
  • effective_state = escalate
  • review_status = NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-97a89afec5b422d568a817ac
  • expected_outcome = not recorded
  • outcome_status = unknown
  • declared_blind_spots = 0
  • completeness_attestation = unknown

Trust inheritance: NOT AUTHORIZATION - blocked by current runtime validation.

Verification posture: Verification required.

Validation result:
  • is_valid = false
  • key violations = actor_continuity

Validate this trace →

Trace excerpt:
  • actor_sequence: actor_a -> actor_b
  • continuity_declared: false
  • latest_verification: needs_review
  • effective_state: escalate
Key constraints:
  • actor_continuity

What happened: Control moved to another actor, but the trace never recorded a valid handoff or declared delegation.

What DBaD shows: Continuity breaks stop prior trust from carrying forward, so the effective state escalates and ordinary continuation is blocked.

Action outcome:
  • Allowed actions = Verify
  • Blocked actions = Transition
  • Blocked actions = Trust-positive continuation
  • Next step = Resolve or remediate the blocking validation violation before treating this trace as trust-continuable.

Open trace → · Try the demo · View trust flow

Chain Reset / Orphan Visibility

Scenario summary: Work resumes on an existing resource through a fresh root trace with no valid origin anchor.

Source: stored trace trc_20260427143144_c82de901 (snapshot)

Trace snapshot:
  • trace_id = trc_20260427143144_c82de901
  • trace_version = 2
  • effective_state = allow_conditional
  • review_status = NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-97a89afec5b422d568a817ac
  • expected_outcome = not recorded
  • outcome_status = unknown
  • declared_blind_spots = 0
  • completeness_attestation = unknown

Trust inheritance: NOT AUTHORIZATION - structural validation evidence only; fresh trust-continuation check required.

Verification posture: Verification required.

Validation result:
  • is_valid = true
  • key violations = none

Validate this trace →

Trace excerpt:
  • resource_id: existing_target
  • origin_anchor: none
  • root_initialization: true
  • zero_trust_birth: active
Key constraints:
  • Trace JSON is point-in-time evidence only.

What happened: A new root trace started on an already-known resource, but it carried no valid parent or origin anchor.

What DBaD shows: The work is not treated as a trusted continuation. The reset remains visible, trust inheritance stays blocked, and verification is required before ordinary propagation resumes.

Action outcome:
  • Allowed actions = Verify
  • Blocked actions = Transition
  • Next step = Call /api/v1/dbad/trust-continuation/check before certified trust-positive use.

Open trace → · What DBaD solves · View trust flow

Repeated Verifier Reuse

Scenario summary: The same verifier repeatedly clears risky work on the same target across one lineage.

Source: stored trace trc_20260427143308_e4419b5a (snapshot)

Trace snapshot:
  • trace_id = trc_20260427143308_e4419b5a
  • trace_version = 4
  • effective_state = escalate
  • review_status = NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-8262f4425d336fcf20069e2a
  • expected_outcome = not recorded
  • outcome_status = unknown
  • declared_blind_spots = 0
  • completeness_attestation = unknown

Trust inheritance: NOT AUTHORIZATION - blocked by current runtime validation.

Verification posture: Independent verification required.

Validation result:
  • is_valid = false
  • key violations = verification_independence, propagation_integrity, missing_escalation_closure

Validate this trace →

Trace excerpt:
  • verifier_sequence: verifier_x -> verifier_x -> verifier_x
  • target_resource: target_17
  • reuse_in_lineage: repeated
  • effective_state: escalate
Key constraints:
  • verification_independence
  • propagation_integrity
  • missing_escalation_closure

What happened: Risky work kept getting cleared by the same verifier on the same target instead of rotating to an independent reviewer.

What DBaD shows: Verifier reuse becomes a visible independence failure. Trust does not continue normally, the effective state escalates, and the lineage requires a structurally separate verifier.

Action outcome:
  • Allowed actions = Verify
  • Blocked actions = Transition
  • Blocked actions = Trust-positive continuation
  • Next step = Resolve or remediate the blocking validation violation before treating this trace as trust-continuable.

Open trace → · Try the demo · What DBaD solves

Recovery Deadlock / Dampened Escalation

Scenario summary: Repeated blocked remediation attempts keep hitting the same enforcement result without changing state.

Source: stored trace trc_20260427143457_b203dd11 (snapshot)

Trace snapshot:
  • trace_id = trc_20260427143457_b203dd11
  • trace_version = 6
  • effective_state = escalate
  • review_status = NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-d5294d8e3a6de9da4d8afcf9
  • expected_outcome = not recorded
  • outcome_status = unknown
  • declared_blind_spots = 0
  • completeness_attestation = unknown

Trust inheritance: NOT AUTHORIZATION - blocked by current runtime validation.

Verification posture: Higher-scrutiny verification required.

Validation result:
  • is_valid = false
  • key violations = trust_trajectory

Validate this trace →

Trace excerpt:
  • correction_payload_hash: repeated
  • repeated_outcome: unchanged
  • state_change: none
  • escalation_events: dampened
Key constraints:
  • trust_trajectory

What happened: The same blocked correction kept being retried with no state change, creating the appearance of activity without actual recovery.

What DBaD shows: The trace stays visible as a deadlock case. Escalation remains active, repetition is dampened, and the system does not mistake repeated failure for fresh progress.

Action outcome:
  • Allowed actions = Verify
  • Blocked actions = Transition
  • Blocked actions = Trust-positive continuation
  • Next step = Resolve or remediate the blocking validation violation before treating this trace as trust-continuable.

Open trace → · View trust flow · Try the demo

Clean Low-Risk Continuation

Scenario summary: A low-risk continuation stays within the same actor context, uses clean verification, and does not materially diverge from prior lineage.

Source: stored trace trc_20260427143629_91ab773e (snapshot)

Trace snapshot:
  • trace_id = trc_20260427143629_91ab773e
  • trace_version = 2
  • effective_state = allow
  • review_status = NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-8262f4425d336fcf20069e2a
  • expected_outcome = not recorded
  • outcome_status = unknown
  • declared_blind_spots = 0
  • completeness_attestation = unknown

Trust inheritance: NOT AUTHORIZATION - structural validation evidence only; fresh trust-continuation check required.

Verification posture: Verification recorded: approved.

Validation result:
  • is_valid = true
  • key violations = none

Validate this trace →

Trace excerpt:
  • actor_sequence: preserved
  • verification_independence: clean
  • trajectory_drift: low
  • effective_state: allow
Key constraints:
  • Trace JSON is point-in-time evidence only.

What happened: The same actor continued low-risk work with clean verification and no meaningful drift from prior trusted context.

What DBaD shows: No blocking constraint fired. Trust inheritance stays allowed, the effective state remains allow, and the trace remains valid under the current deterministic rule set.

Action outcome:
  • Allowed actions = Verify
  • Allowed actions = Transition
  • Blocked actions = none
  • Next step = Call /api/v1/dbad/trust-continuation/check before certified trust-positive use.

Open trace → · Try the demo · What DBaD solves

Each example corresponds to a structured trace that can be validated using /api/v1/dbad/validate. Outcome reflects later observation, not validation result. For a compact public summary of what multiple AI reviewers challenged, see AI peer review findings. For the runtime-audited integrity-stack walkthrough, open the v2.2 demo trace. If you want to pressure-test the logic yourself, try to break DBaD.