Can broken trust escape by starting a new trace?

Reviewer Test Construction

Create or submit a trace object that is otherwise clean but includes:

{
  "lineage_parent_trace_id": "trc_20260428181140_42396240"
}

Expected validation result:

• cross_trace_lineage_integrity: false
• unresolved_parent_lineage_failure
• parent_validation_summaries includes the parent trace failure
• trust_lineage_blocked: true and trust_lineage_block_source: declared_parent are present in metadata
• lineage_validation_mode: live, validated_at_utc, and lineage_traversal_depth are present in metadata

For multi-hop lineage testing, construct a grandchild trace whose parent points to a child of the broken canonical trace. Expected result: the grandchild still fails and flattened ancestor summaries include the broken root, not just the immediate parent snapshot.

For same-resource orphan reset testing, construct a fresh root trace with the same resource_id as a broken prior trace and no parent field. Expected result: resource_lineage_integrity: false and same_resource_orphan_lineage_failure.

For missing-resource identity testing, construct a trust-positive root trace with no parent field and no resource_id, resource_ref, or lineage_anchor. Expected result: resource_lineage_integrity: false and missing_resource_identity_for_lineage_check.

For coverage exposure testing, construct a trust-positive trace that lists a broken trace in completeness_attestation.included_trace_refs but does not declare lineage and is not non-governing. Expected result: coverage_trace_exposure: false and unbound_prior_trace_exposure.

For analysis-mimic testing, construct a trace that declares trace_purpose=analysis_only but records trust-positive continuation markers such as mark_reviewed or a boundary trust-state handoff. Expected result: governing_intent_coverage_alignment: false and governing_intent_mismatch_coverage_exposure.

For reliance testing, construct a trust-positive trace with relies_on_trace_refs pointing to a non-governing analysis trace. Expected result: trace_reliance_integrity: false and reliance_on_non_governing_trace. A prose-only phrase such as "covered by analysis trace X" should surface unverified_prose_reference and prose_reliance_not_machine_verified as advisory metadata, not as semantic lineage inference. Mixed, transitive, or partial structured reliance sets should fail if any governing dependency relies on non-governing or unresolved traces, or if the submitted structured reliance declaration is incomplete. Served metadata value-binds reliance_declaration_mode as NOT_AUTH::not_authorization_status_evidence_for_..., not as a raw complete display token.

For resource-continuity churn testing, construct a trust-positive root with a new resource_id and resource_lineage_anchor.prior_resource_ids pointing to a broken prior resource. Expected result: resource_lineage_integrity: false and unresolved_prior_resource_lineage_failure unless verifier-bound reset-boundary evidence is declared.

For reset-boundary testing, validate a verifier-bound reset and a child of that reset. Expected result: both record reset-boundary continuity with trust_continuity_confidence=NOT_AUTH::not_authorization_status_evidence_for_...; the child also exposes lineage_reset_boundary_inherited=NOT_AUTH::not_authorization_boolean_evidence_for_....

For reset-verifier authority testing, construct a reset with an independent-looking verifier ID that is not in the reset-verifier registry. Expected result: zero_trust_reset_verifier_not_registered and zero_trust_reset_state=rejected_verifier_authority.

For reset-evidence availability testing, construct a reset with a well-formed evidence hash but an evidence ref that is not available through the deterministic evidence registry. Expected result: zero_trust_reset_evidence_unavailable and zero_trust_reset_state=rejected_evidence_unavailable.

For certified consumption testing, first obtain a passing trust_continuation_token from /api/v1/dbad/trust-continuation/check, including reliance_snapshot_hash when the trace exposes depends_on_reliance_trace_refs, then verify it through /api/v1/dbad/trust-continuation/token/verify. Expected result: valid token verification returns HTTP 200, no root ok, empty failure states, and allowed=NOT_AUTH::not_authorization_boolean_evidence_for_structural-evidence-code-v2-...; tampered, expired, dependency-stale, or reliance-epoch-stale token returns 409.

For historical attestation testing, use the optional historical_verification_attestation returned by successful token verification only as audit evidence. Expected result: /api/v1/dbad/historical-verification-attestation/verify verifies the signature but returns accepted_as_authorization=false, and /api/v1/dbad/trust-continuation/check rejects attempts to present the attestation as permission with historical_verification_attestation_not_authorization.

For client-consumption testing, do not treat copied trace JSON, copied validation JSON, screenshots, cached receipts, or evidence-bound response booleans as authorization. Expected compliant path: fetch current validation, call /api/v1/dbad/trust-continuation/check with the receipt and lineage snapshot fields, verify the returned short-lived token, and reject trust-positive action unless token verification returns HTTP 200 with empty failure states and bound evidence fields. The public API docs include copy-pasteable client snippets for this path.

For API-envelope testing, DBaD non-authorization endpoints must omit root ok. Expected current root fields include api_transport_status=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., api_delivery_outcome=NOT_AUTH::not_authorization_outcome_evidence_for_structural-evidence-code-v2-..., ok_removed_for_authorization_safety=NOT_AUTH::not_authorization_boolean_evidence_for_structural-evidence-code-v2-..., ok_meaning=transport_only_not_authorization, ok_authoritative_for_trust_positive_use=false, api_envelope_authorization_class=NOT_AUTH::not_authorization_class_evidence_for_structural-evidence-code-v2-..., and unsafe_if_ok_used_for_authorization=NOT_AUTH::not_authorization_boolean_evidence_for_structural-evidence-code-v2-....

For status-field invariant testing, fetch /api/v1/dbad/status-field-compliance-snapshot?cache_bust=<timestamp> or run python3 app/scripts/audit_dbad_status_field_compliance.py --base-url https://ethics.decencymeter.com. Run python3 app/scripts/dbad_redteam_runner.py --base-url https://ethics.decencymeter.com --timeout 20 for the composite post-Round 54 red-team pass. Expected result: no root ok, served_hardening_round=round53_trust_response_evidence_binding_v1, status values beginning with NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-, typed status-keyed boolean/class evidence beginning with NOT_AUTH::not_authorization_boolean_evidence_for_structural-evidence-code-v2- or NOT_AUTH::not_authorization_class_evidence_for_structural-evidence-code-v2-, outcome fields such as verification_posture.latest_outcome beginning with NOT_AUTH::not_authorization_outcome_evidence_for_structural-evidence-code-v2-, public positive validation booleans such as current_validation.is_valid and snapshot sample_status_fields.is_valid value-bound instead of bare true, verification_history[].outcome value-bound with local authority/human-readable companions, representation_class and representation_compliant retaining typed non-authorization values with local companions, trace detail visible metadata rendering representation_compliant evidence with the display-safe NOT AUTHORIZATION - boolean evidence: structural-evidence-code-v2-... - not permission value instead of raw true, DBaD trace mutation write/error responses omitting root ok and binding mutation_result as non-authorization status evidence, trust-continuation check/verify responses omitting root ok and binding positive allowed response booleans as non-authorization evidence, explicit trust-response companions such as allowed_evidence, trust_continuation_token_issued_evidence, token_valid_evidence, and historical_verification_attestation_available_evidence, no bare approval-shaped string values, no base64-reversible evidence-code payloads, no prompt-injection prefix-stripping collapse in the deterministic LLM fuzzer, no shared-dictionary pollution of the public ethics calculator after DBaD response binding, payload-echo suppression in verifiers, mutation rejection for bare status or representation fields, and DBaD API cache headers Cache-Control: no-store, max-age=0, must-revalidate, Surrogate-Control: no-store, Pragma: no-cache, Expires: 0, and X-DBaD-Cache-Status: fresh.

For composite proof-bundle testing, fetch /api/v1/dbad/composite-proof-bundle?cache_bust=<timestamp>. Expected result: HTTP 200, no root ok, DBaD no-store headers, artifact_type=dbad_composite_proof_bundle, artifact_header=NOT AUTHORIZATION - COMPOSITE PROOF BUNDLE - LIVE SAMPLE EVIDENCE ONLY, proof_bundle_signature beginning with dbad_cpb_v1., and samples for status_snapshot, trace_api, trust_continuation_check, and trust_continuation_token_verify. Public samples must include response headers and bodies but must not leak live dbad_tct_v1. trust-continuation tokens or raw historical-attestation payloads. Then post the copied bundle or full envelope to /api/v1/dbad/composite-proof-bundle/verify; expected result is HTTP 200, no root ok, proof_bundle_signature_valid=NOT_AUTH::not_authorization_boolean_evidence_for_structural-evidence-code-v2-..., and accepted_as_authorization=false. If any signed bundle field is altered, expected result is HTTP 422 with proof_bundle_signature_mismatch and accepted_as_authorization=false.

Round 55 response digestion added dedicated proof-bundle and token hardening to the local red-team runner. fuzz_dbad_composite_proof_bundle_scope.py checks signature-scope coverage, unsigned-shadow-field rejection, verifier failure echo suppression, delayed replay as evidence only, and token redaction. fuzz_dbad_trust_token_integrity.py checks fresh token issuance, valid verification, immediate replay as evidence-only behavior, wrong intended use, tampered token, wrong trace context, wrong receipt, and historical-attestation-as-permission rejection. Use these checks before staging the next peer prompt.

The same runner now appends compact internal history to /home/dbad/logs/dbad_redteam_history.jsonl, classifies any failures by leakage class, and prints an explicitly internal regression posture score. The score is not authorization and not public proof of safety; it exists only to help operators spot regressions between hardening passes.

Authorization Non-Recoverability report package: /home/dbad/docs/DBaD_Authorization_Non_Recoverability_Report_2026-05-31.md captures the working thesis, threat model, enforcement layers, adversarial harness table, limitations, reviewer Q&A, and cautious publication positioning. It does not claim a formal proof.

API/OpenAPI drift guard: audit_api_v1_openapi_coverage.py now compares live Flask /api/v1 routes against both the base OpenAPI literal and enriched paths.setdefault(...) additions. The current strict baseline is missing_paths=0, missing_operations=0, path_coverage=100.00%, and operation_coverage=100.00%, including DBaD proof/validation/trust-continuation endpoints and public ethics routes. This is contract coverage, not authorization.

DBaD OpenAPI contract-depth guard: audit_api_v1_dbad_openapi_contract.py --url https://decencymeter.com/api/v1/openapi.json now fetches the DecencyMeter-hosted OpenAPI document with cache busting and verifies DBaD critical operations have dedicated non-authorization schemas/examples, x-dbad-non-authorization-contract markers, DBaD no-store response headers, request/response schema references, and evidence/not-authorization wording. audit_dbad_openapi_host_canonical.py verifies that DecencyMeter and ethics hosts serve the canonical DBaD/DecencyMeter OpenAPI contract, that the Church host remains compatibility-only with Church labeling, and that the OpenAPI JSON responses emit Cache-Control: no-store, max-age=0, must-revalidate, Surrogate-Control: no-store, Pragma: no-cache, Expires: 0, and X-DBaD-Cache-Status: fresh. The composite red-team runner includes both OpenAPI guards, and the status-field audit now verifies successful checked_rules.* values are typed non-authorization boolean evidence instead of bare true, stored state fields such as state.effective_state are typed non-authorization status evidence instead of raw allow, structured-reliance fields such as reliance_declaration_mode / reliance_declaration_complete are evidence-bound instead of raw complete or bare true, and invariant/reset fields such as status_field_invariant_verified, prose_reliance_not_machine_verified, and zero_trust_reset_state are evidence-bound instead of bare true or raw approved. The standard public contract runner now also executes audit_public_api_docs_discovery_schema.py and the OpenAPI host audit, so pre-peer public contract checks fail if API-doc discovery drops the DecencyMeter/ethics OpenAPI URLs, drifts back to the Church host as canonical, loses OpenAPI freshness headers, serves ethics or DecencyMeter discovery JSON without X-DBaD-Cache-Status: fresh, or reintroduces a bare root success boolean into DBaD/DecencyMeter discovery payloads.

Public contract health gate: run_ethics_public_contract_audit.py now also executes audit_public_api_docs_live_routes.py, targeted audit_html_health.py for the main DBaD proof pages, and audit_template_accessibility.py. The standard artifact exposes api_docs_live_routes_audit_exit_code, html_health_audit_exit_code, and template_accessibility_audit_exit_code; any failure blocks a pre-peer pass.

The runner also covers evidence-code correlation and client-projection drift. audit_dbad_evidence_code_correlation.py records repeat/mixed-kind structural evidence-code exposure as advisory data and fails on public decode hints or approval-shaped meaning near codes. fuzz_dbad_cross_client_projection.py checks lossy trace API JSON, rendered trace-detail HTML, linked public trace pages, and older explanatory/demo pages for approval-shaped terms without the non-authorization boundary. Current covered public pages include /examples, /v2-2-demo, /decencymeter/demo, /faq, /glossary, /methodology, /whitepaper, /explained, /why-dbad-exists, and /trust-flow.

For screenshot/crop testing, trace detail authority and validation blocks should include the subtle repeated marker DBaD EVIDENCE ONLY - NOT AUTHORIZATION through the page CSS. The marker is a visual supplement only; the machine-readable non-authorization fields remain the authoritative contract.

For archival-projection testing, copied archive artifacts must begin with aaa_not_authorization_headline=NOT AUTHORIZATION - ARCHIVAL PROJECTION - NOT SAFE CITATION and retain headline_authority_block=NOT AUTHORIZATION - ARCHIVAL PROJECTION - NOT SAFE CITATION as a duplicate human-readable field. The first sentinel must remain first even when sorted by a JSON serializer.

For alternative-serialization testing, archival projections must also carry labeled status values such as validation_outcome_class_labeled=NOT AUTHORIZATION - structural validation evidence: structural-evidence-code-v2-... - not permission so a YAML/XML/log projection that strips sort-padding keys still has a boundary-bearing display value.

For validation-summary crop testing, the visible Trace Validation sentence must begin with NOT AUTHORIZATION - Validation result:, successful checked-rule rows must render NOT AUTHORIZATION - pass - structural validation evidence only, failed checked-rule rows must render fail - not authorization, and status metadata rows such as current_validation_status, validation_status_class, and validation_outcome_class must render values that begin with NOT AUTHORIZATION. The visible fingerprint projection must use human_readable_bundle_fingerprint_safe_display, not a raw long human_readable_bundle_fingerprint row. A cropped validation checklist, metadata excerpt, or fingerprint-display excerpt must not be able to quote passed, pass, or structural_pass without same-line non-authorization language.

For API field-selection testing, exposed raw status fields must be value-bound and explicitly marked machine-only/non-display-safe: expected metadata includes current_validation_status=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., validation_status_class=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., validation_outcome_class=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., current_validation_status_token=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., validation_status_class_token=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., validation_outcome_class_token=NOT_AUTH::not_authorization_status_evidence_for_structural-evidence-code-v2-..., token-specific companions such as current_validation_status_token_authority_binding=not_authorization_token_bound, current_validation_status_token_display_safe=false, and current_validation_status_token_machine_only=true, group flags token_fields_display_safe=false, token_fields_machine_only=true, displaying_token_fields_is_non_compliant=true, raw_status_fields_display_safe=false, raw_status_fields_machine_only=true, current_validation_status_machine_only=true, validation_status_class_machine_only=true, validation_outcome_class_machine_only=true, displaying_raw_status_fields_is_non_compliant=true, and preferred_display_fields pointing to the *_human_readable values plus human_readable_bundle_fingerprint_safe_display. The raw bundle fingerprint must also expose human_readable_bundle_fingerprint_display_safe=false and human_readable_bundle_fingerprint_machine_only=true. Public human-facing examples should use values such as validation_outcome_class_human_readable=NOT AUTHORIZATION - structural validation evidence: structural-evidence-code-v2-... - not permission, not a bare pass-shaped status or token.

For public-surface consistency testing, DBaD ethics logic/API/code changes must keep /updates, /current-state, /api/docs/ethics, and this /dbad-ethics-817 proof page synchronized before a new peer-review prompt is considered ready.

Public Verification Fixtures

These stored fixture traces are synthetic review artifacts. They exist so reviewers can validate the cross-trace rules from public GET pages and the validation API without relying on prose claims.

Validation command pattern: curl -X POST https://ethics.decencymeter.com/api/v1/dbad/validate -H "Content-Type: application/json" -d '{"trace_id":"trc_fixture_827_declared_child"}'

Review Prompt