Known limits

The boundary matters as much as the claim.

DBaD v3 defines the current boundary of enforceable trust constraints.

These are not hidden weaknesses. They are explicit places where enforcement transitions into observation, review, or future research.

Public path: /known-limits. Legacy path /boundary-conditions remains live for backward compatibility.

What DBaD solves Trust flow Challenge a limit
No hidden certainty No semantic identity inference Scope remains visible Research boundaries open

Read this before citing DBaD

Validated does not mean true DBaD can validate structure without proving real-world completeness or correctness.
Resource identity is deterministic Same-resource checks require machine-readable identity, not prose similarity.
Limits are review targets Known gaps should be tested and cited directly, not smoothed into claims.

Last updated: 2026-05-30 UTC

Public known limits and boundary conditions

DBaD Explained What DBaD solves Trust flow White paper v3 Papers DecencyMeter demo Methodology

Start here

Use these links to compare enforceable scope with open limits.

Cross-trace lineage review Inspect the current resource-lineage and parent-lineage hardening boundary. Compare examples See where stored traces validate and where caveats remain visible. Send to reviewers Use the public brief for adversarial review of exactly these boundaries.

1. Cross-Chain Coordination

DBaD constrains trust within visible dependency chains. Coordinated behavior across independent chains remains partially observable and is a current research focus.

2. Resource Identity / Orphan Reset

Same-resource orphan checks now apply when a machine-readable resource_id, resource_ref, or lineage_anchor exists. DBaD still does not infer hidden continuity from prose, actor names, titles, scenario similarity, or semantic similarity.

3. Recovery Deadlock / Governance Loop

Enforcement rules may block legitimate recovery actions during failure states. DBaD currently escalates these conditions rather than bypassing them.

4. Propagation Timing

State transitions occur within runtime windows. High concurrency may introduce race conditions between evaluation and commit phases.

DBaD is designed to make these limits visible, not hide them. Future versions will refine these boundaries without compromising minimal enforcement principles.

Next steps: read DBaD Explained, review what DBaD solves, the trust flow diagram, the white paper v3, or inspect the research demo to see the current public baseline in practice.