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 reliance_declaration_mode is not complete.

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 a valid reset-boundary trace is declared.

For reset-boundary testing, validate an approved reset and a child of that reset. Expected result: both pass with trust_continuity_confidence=restored_with_reset_boundary; the child also exposes lineage_reset_boundary_inherited=true.

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 valid-looking 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 returns allowed=true; 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, or cached receipts 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 allowed=true. 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. Expected result: no root ok, served_hardening_round=round47_irreversible_status_evidence_code_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-, no bare approval-shaped string values, no base64-reversible evidence-code payloads, 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 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:, checked-rule rows must render pass - not authorization or 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