Methodology & Data Stewardship

This page supports the current DBaD public draft baseline with methodology, lifecycle, and data-stewardship detail. The main public story now lives on the explainer, white paper, and known-limits pages.

JSON summary for clients: /api/v1/methodology/summary

On this page

1. Current runtime status
2. Guardrails before math
3. How scoring works
4. Blocking constraints vs advisory concerns
5. Action guidance on trace detail pages
6. How DBaD handles conflicting dimensions
7. Contextual doctrines
8. The lifecycle of an action under DBaD
9. Example decision trace
10. Conditional ethical states
11. Ethical ledger
12. Cascading ethical risk
13. Preventing governance gridlock
14. Verification and clearance
15. Evidence tiers
16. Calibration and revision signals
17. Versioning and change control
18. Governance profile for the model
19. Adversarial review and open challenge
20. Implemented v2.2 integrity layers
21. Privacy guarantees
22. Publication rules
23. Red-teaming roadmap
24. Takedown/data purge
25. Product surface notes

Current runtime status

DBaD now has a narrow public runtime path: evaluate → stored trace → inspect → validate → verify → transition.

• Traces are stored and versioned.
• Examples are backed by stored canonical traces rather than illustration-only cards.
• Trace detail pages expose action guidance, validation results, and mutation history for the current runtime slice.
• Logic-review findings can now be queued for operator review through the public reporting flow on /break-dbad/report.

Guardrails before math

• DBaD does not treat ethics as a single smooth optimization surface. Some failures should stop evaluation early.
• Invalid consent, extreme foreseeable harm, openly malicious intent, and opaque high-impact behavior are candidate veto conditions.
• Weighted scoring is a supporting layer for ethically live actions that remain after those guardrails are checked.

How scoring works

• Survey and quick-test prompts are mapped to the model domains and normalized before weighted aggregation.
• Public-facing score bands are meant to be interpretable summaries, not clinical or legal classifications, and not the main identity of DBaD.
• Optional demographic/context fields exist to improve aggregate analysis, not to turn the product into an identity dossier.
• When weights, wording, or scoring semantics change, the public surface should expose that change instead of quietly overwriting history.

The current public system is trace-first. Scores support the trace; they do not replace validation, version history, or later operator review.

Blocking constraints vs advisory concerns

The current trace output distinguishes between constraints that actively block an operator action and concerns that remain visible without blocking the next step.

• Blocking constraints explain why a verification or transition cannot proceed under the current stored state.
• Advisory concerns remain visible for audit even when the current action remains structurally available; availability is not authorization.
• This separation is intentional. A triggered condition is not automatically the same thing as a current block.

Action guidance on trace detail pages

Trace detail pages now expose a simple operator guidance layer derived from current stored trace fields.

• Stored operator action evidence shows what the current operator surface can append; it is not authorization for trust-positive use.
• Blocked actions show what is currently prevented.
• Why actions are blocked only lists direct blockers.
• Additional concerns keep non-blocking flags visible for audit and review.

How DBaD handles conflicting dimensions

Real-world cases do not arrive neatly sorted. A system may reduce harm while undermining consent, or protect life-safety while temporarily reducing transparency. DBaD keeps those conflicts visible instead of flattening them into a naive average.

1. Guardrails first. Hard constraints catch severe failures or force escalation before weighted math can dominate the decision; the result is structural evidence, not authorization.
2. Weighted scoring second. If the action remains ethically live, the five dimensions are scored and combined.
3. Contextual doctrines third. Doctrine-level interpretation is applied when a gray-zone case needs more than arithmetic.
4. Control-layer output last. The reviewer sees a recommendation such as Allow, Modify, Escalate, or Block, while the system records a formal state such as allow, allow_conditional, modify, escalate, or block.

This remains supporting reference logic. The current public identity of DBaD is the trace, validation, review, and challenge path.

Contextual doctrines

• Life-Safety Priority Doctrine: imminent risk to physical life can justify temporary tradeoffs, but only when the action remains proportional, logged, and reviewable.
• Least-Invasive Means Doctrine: when an action would otherwise land in Modify, the review protocol should prefer the option that achieves the goal with less coercion and less damage to autonomy.
• Restoration of Transparency Doctrine: if transparency is reduced for legitimate harm-prevention reasons, it must later be restored or the action becomes a policy violation.

The lifecycle of an action under DBaD

DBaD is not only a gatekeeper. It is a lifecycle model for trust, obligations, and decision continuity over time.

DBaD governs decisions across time, not just at the moment they are made.

1. Evaluate: guardrails and weighted scoring determine the initial recommendation and the first system state.
2. Execute: the action either stays blocked, moves forward, or proceeds under conditions such as logging, scope limits, or time-boxed confidentiality.
3. Monitor: the system tracks open obligations, deadlines, and unresolved ethical debt after execution begins.
4. Restore: required follow-up actions such as restored transparency or human sign-off must be fulfilled and recorded as evidence; that evidence is still not authorization by itself.
5. Audit: the final state may remain compliant, move to remediated_violation, or become a retroactive violation if obligations fail.

Example decision trace

To be audit-ready, the review protocol should expose more than a score. A real system needs a structured decision trace.

Action: Security Patch Secrecy

Scores:
Harm: 0.88
Consent: 0.72
Intent: 0.86
Proportionality: 0.82
Transparency: 0.50

Guardrails evidence: structural check recorded, not authorization
Doctrine applied: Restoration of Transparency

Recommendation: Allow
System state: allow_conditional
Domain context: cybersecurity_incident_response
Dependency scope: patch_release_chain
Contamination scope: local_default
Clearance mode: tier1_plus_tier2
Verification evidence: tier1_fact_plus_tier2_quality
Probationary state: restricted_transparency_window

Obligations:
- Maintain audit logging
- Restore transparency after the patch release window

Failure condition:
- Retroactive violation if transparency is not restored as promised

Calibration:
- divergence_flag: low
- revision_signal: none
  

DBaD should produce structured, auditable decision traces rather than opaque allow/block outputs.

Conditional ethical states

Some actions are not simply blocked. They remain structurally available only under explicit conditions, timelines, and audit expectations; that availability is operator evidence, not trust-positive authorization.

Probation is not a loophole or a quiet restoration of trust. It is a temporary, profile-defined operating state with reduced autonomy, a visible TTL, and automatic escalation when the deadline expires or required evidence is not supplied.

• Conditional allow_conditional: the action may proceed only within a narrow scope and under logged constraints.
• Probationary probationary_state: the system may continue only under reduced autonomy, elevated audit, explicit obligations, and a profile-defined TTL instead of being shut down immediately.
• Modify modify: the action is ethically live, but it must change before approval.
• Escalate escalate: the system refuses automatic approval and requires human review before execution.
• Violation violation / Remediated remediated_violation: audit can mark the earlier action as non-compliant, while still preserving later remediation in the ledger.
• Contaminated contaminated_local / contaminated_global: downstream actions may inherit invalidity from an upstream failure and require renewed review.

UI distinction planning matters here: the public model should make it obvious whether a state is clean, probationary, actively violating, remediated, or contaminated. Probationary states should always show their deadline, governing profile, open obligations, and escalation path.

Re-entry after an override is not an implicit rollback. When a higher-precedence state clears, the lower local state should either resume with preserved TTL, resume with paused TTL, re-enter through evaluation, or expire and reclassify. It should not silently restart with a fresh compliance window.

Ethical ledger

A visible system should maintain an ethical ledger: a durable record of actions, obligations, doctrine use, remediation, and violations. Restoring a value such as transparency can change the current state, but it should not erase the historical trace.

Cascading ethical risk

Actions can create downstream dependency problems. Unresolved obligations, repeated exceptions, or earlier violations may contaminate later decisions and trigger renewed review. In that sense, ethical risk can cascade through a system rather than remaining local to one event.

DBaD applies an isolation principle here: contamination remains local by default unless the active governance profile says broader escalation is justified. That is why the system tracks dependency_scope and contamination_scope rather than assuming every failure should become global.

Systemic health signals are pattern-based, not single-event shortcuts. Repeated unresolved obligations, recurring contamination on the same dependency family, or chronic remediation dependence can indicate broader governance drift; one isolated local failure should not be treated as proof of systemic collapse.

Recursive invalidation also needs operational bounds. Planning distinguishes enforcement finality from ledger finality so old or pruned chains can become explicitly unverifiable instead of quietly appearing clean or triggering unlimited recheck cascades. Push invalidation and pull recheck should be bounded and retryable, not infinite.

Preventing governance gridlock

DBaD is intended to prevent avoidable governance paralysis. A real review protocol needs a middle ground between laissez-faire approval and total shutdown.

• Local first: keep contamination and review scope as narrow as the evidence allows, with local contamination as the default starting point.
• Escalate only when justified: broader contamination or shutdown should require profile-defined thresholds, shared dependency evidence, or repeated unresolved failures, not panic.
• Probationary operation: when justified, a compromised action may continue under reduced autonomy, elevated audit, and a clear TTL.
• Accountable continuity: constrained continuation should preserve obligations, trace links, and review triggers so the system avoids brittle shutdown without pretending the state is clean.
• Profile-aware debt weighting: unresolved debt should be interpreted relative to the active governance profile, not as one-size-fits-all risk.

Verification and clearance

Conditional actions and ethical debt should not clear themselves by assertion. DBaD is intended to require verifiable evidence before obligations can close and states can change.

• Machine verification: logs, structured evidence, and system records can prove that a required action actually happened.
• Human verification: compliance review, audit sign-off, and high-stakes operator approval can close obligations that automation should not clear alone.
• Profile-based rules: different domains can require different clearance thresholds, time windows, and reviewer roles.

High-risk remediation may require more than one clearance lane: technical evidence, policy review, and formal approval can all be required before trust-positive continuation resumes.

Ethical debt is not cleared by intent, promise, or a single unchecked signer. It must be fulfilled, independently evidenced, and recorded with the remediation authority that cleared it; the record itself is not authorization.

Clearance authority is itself governable. If a signer or authority is later revoked, the ledger should distinguish administrative revocation from integrity revocation and state whether prior clearances require recheck, sampling, or downstream reclassification.

Verifier independence is a clearance constraint. A reviewer, signer, or reset verifier should be rejected when that same identity appears in the action's actor, reviewer, verifier, attestation, dependency, or prior clearance scope; the default response is to keep debt unresolved and preserve a constrained state. Repeated reciprocal approvals are treated as a governance-risk signal, not as automatic clearance.

Actor continuity is also a clearance boundary. If control shifts to a different actor without an explicit handoff, delegation path, or fork justification, DBaD should reject ordinary continuation status and preserve a review-gated or fork-required state until provenance is repaired.

Trust trajectory can also block inheritance. A material jump in risk, repeated stagnant recovery, or unstable lineage path should preserve a constrained state and require context re-validation before ordinary trust continuation resumes.

Evidence tiers

Verification does not always mean the same thing. Some obligations can be cleared with machine-verifiable facts; others require interpretive or human-reviewed evidence.

• Tier 1: Evidence of Fact. Event logs, timestamps, disclosures, and machine-verifiable records confirm that something happened.
• Tier 2: Evidence of Quality. Human review or semantic evaluation confirms whether the action met transparency, intent, fairness, or proportionality requirements.

Transparency-, intent-, legitimacy-, and proportionality-related debt often require Tier 2 review. A log can prove that an event happened, but not always that the event was sufficient, honest, fair, or ethically adequate.

Emergency doctrine

DBaD treats emergency pressure as not authorization and not permission to weaken immutable guardrails generally.

If a break-glass path exists, it should be high-friction, Tier 2 or multi-party only, fully logged, classified as a critical architectural deviation, budgeted per governance profile, and followed by mandatory review. Budget exceedance should trigger systemic audit or restriction.

Compatibility and downgrade safety

Schema-version mismatch should not silently fail open into a weaker governance surface.

Planning should define minimum supported schema version, explicit downgrade behavior, fail-open protection, and version parity across participating review surfaces.

Calibration and revision signals

DBaD still treats disagreement between human judgment and review-protocol output as useful evidence, but that work now sits behind the runtime rather than defining the public story. Not every disagreement is bias, and not every disagreement is framework failure. Recurring divergence can still signal missing doctrine, poor profile tuning, or the need for stronger explanation.

• divergence_flag: low means ordinary monitoring, moderate means operational caution and explanation review, and high means formal calibration review should be considered.
• survey_disagreement_rate: public disagreement level for a scenario family or review-protocol output.
• calibration_review_recommended: whether recurring disagreement should trigger formal review.
• matched_scenario_family: the family label used to compare this case against similar scenarios over time.

This remains research and maintenance context, not the main operator-facing identity of the current public runtime. Divergence is a caution signal, not proof of public bias or proof that the framework is wrong.

A divergence signal becomes revision work only through governed thresholds: quorum, review window, named authority, active draft, approval, and versioning. Public disagreement alone is not an automatic rule change.

Versioning and change control

• Control-layer versions are visible in the site shell so readers can tell which revision they are looking at.
• Survey versions are stored separately so old data stays attributable to the instrument that generated it.
• Stored DBaD traces now carry a trace_version that increments on successful verification, transition, outcome, and escalation-closure mutations.
• Public papers, open-data samples, and methodology endpoints should remain cache-aware and revision-safe.

Governance profile for the model

DBaD itself also needs governance. A lifecycle governance model should be explicit about how its own weights, doctrines, thresholds, and public-draft baselines change over time.

Revision signals are not automatic rule changes. They open a governed review path that must name authority, evidence requirements, review process, approval, documentation, and versioning before any framework change becomes part of the public baseline.

• Authority: define who can revise weights, doctrines, and profile thresholds.
• Evidence: define what research, scenario evidence, and divergence evidence are required before revision.
• Process: define how revisions are reviewed, challenged, approved, and documented.
• Versioning: define how governance changes are versioned so old outputs remain attributable to the rules that produced them.

Adversarial review and open challenge

The current public system is no longer asking only to be read. It is asking to be challenged.

• Current state anchors the live baseline before older AI peer review findings summarize convergent limitations surfaced by multiple independent model reviews.
• Try to Break DBaD invites adversarial logic review of the trace model, validation behavior, trust inheritance assumptions, and boundary conditions.
• The logic-review reporting flow now queues structured findings for operator review while stating they are not authorization for infrastructure testing.

Implemented v2.2 integrity layers

Peer review surfaced a wider integrity-layer roadmap. That deterministic field stack is now implemented in the live runtime: outcome_status, escalation_closure, declared_blind_spots, expected_outcome, state_transition_evidence, and completeness_attestation.

• state_transition_evidence
• evidence_hash
• declared_blind_spots
• completeness_attestation
• expected_outcome
• outcome_status
• escalation_closure

These layers record references, scope limits, pre-commitments, outcomes, escalation responses, and completeness claims. They do not prove truth, completeness, or correctness.

Privacy guarantees

• The quick test does not require names or email addresses.
• Operational anti-abuse controls use minimized signals and hashes rather than publishing raw network data.
• Public outputs are aggregate-first, and wall publication requires moderation plus anonymization.

Publication rules

• Published wall excerpts are edited for anonymity and published only when they add value to the public record; publication is not DBaD authorization.
• Open data samples are designed for integration and evaluation, not for reconstructing an individual respondent.
• The ethics portal carries the control-layer model, papers, and methodology; Decency Meter carries the quicker public-facing pulse surfaces.
• Public releases should happen in stages: aggregate summaries first, then more formal anonymized releases as methodology and publication quality improve.

Red-teaming roadmap

The public challenge path now covers the first practical layer of adversarial review. Broader red-teaming remains a future expansion path rather than the current operating model.

1. Internal red-team
2. Invited research partners
3. Limited external challenge program
4. Broader access later, with versioning, logging, rate limits, and disclosure controls

Request a takedown or data purge

If you believe a published excerpt or stored session should be removed, email research@vettedpatriots.org with the session ID, link, or approximate submission time. When a removal request is confirmed, the record can be removed and downstream aggregates rerun.

Product surface notes

1. The quick test must stay fast. Decency Meter should feel like a pulse-check, not an application form.
2. The deeper research flow can ask for more context. That is what the full survey is for.
3. Aggregation should be reproducible. Store the versioned ingredients needed to explain how a published number was produced.

For current public entry points, start with why DBaD exists, inspect current state and proof-backed examples, review the peer-review findings, and use Try to Break DBaD before diving deeper into methodology history.