Revisions – ML-Draft-019

Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.

1. # DP15 – Security and Provenance

2. Added

   *Structural security and inspectable provenance, so serious claims carry verifiable evidence*

3. Added

   <!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->

4. ## 1. Purpose of This Draft

5. 117 unchanged paragraphs

6. This layer ensures security claims are not merely present but **continuously checkable under real conditions**.

7. Added

   ## 6. Security Core

8. Added

   The security core is the minimum set of protections that must hold in any DP15-aligned deployment, independent of product surface, jurisdiction, or cryptographic preference. Mechanisms in Section 5 elaborate these guarantees; the core defines what cannot be traded away.

9. Added

   ### 6.1 Trust anchors and key integrity

10. Added

    Identities, signing keys, and attestation roots have documented ownership, custody model, rotation policy, and revocation state (DP1 linkage). Key status is resolvable at use time, not only at issuance.

11. Added

    Failure mode: **anchorless trust**, where signatures validate against keys no one is accountable for.

12. Added

    ### 6.2 Integrity-protected artifacts

13. Added

    Artifacts that carry consequence — releases, policies, decisions, credentials, high-stakes content — are hashed, signed, and versioned, and integrity is checked when they are consumed rather than assumed from origin.

14. Added

    Failure mode: **verification bypass**, where protection exists but is never evaluated.

15. Added

    ### 6.3 Least privilege and isolation

16. Added

    Services, agents, and integrations operate with scoped credentials, bounded network reach, and isolated execution, so that compromise of one component does not become compromise of the system (DP13 linkage).

17. Added

    Failure mode: **ambient authority**, where a single credential unlocks unrelated capabilities.

18. Added

    ### 6.4 Verifiable enforcement

19. Added

    Security claims are bound to enforcement points that can be observed and attested, so declared posture and runtime posture can be compared.

20. Added

    Failure mode: **declarative security**, where posture is described in documentation but not measurable in operation.

21. Added

    ### 6.5 Incident readiness

22. Added

    Detection, disclosure, rotation, notification, and rollback pathways are defined and rehearsed before they are needed, with predefined authority and communication duties.

23. Added

    Failure mode: **improvised response**, where the first real incident is also the first exercise.

24. Added

    ## 7. Provenance and Archive

25. Added

    Provenance is only useful if it survives time as well as transfer. DP15 therefore treats archival integrity as part of provenance rather than a separate records-management concern.

26. Added

    ### 7.1 Provenance envelopes in motion

27. Added

    Origin, transformations, handlers, and policy context travel with artifacts across export, embedding, and integration boundaries, with explicit signaling when fields are dropped (DP7 linkage).

28. Added

    Failure mode: **provenance stripping**, where artifacts arrive stripped of the context needed to assess them.

29. Added

    ### 7.2 Durable retention and addressing

30. Added

    Evidence supporting consequential claims remains retrievable for a declared retention window, with stable identifiers so citations do not decay into dead references.

31. Added

    Failure mode: **evidence rot**, where claims outlive the records that substantiate them.

32. Added

    ### 7.3 Archival integrity over time

33. Added

    Archives are protected against silent modification and against cryptographic obsolescence through checkpointing, timestamping, witnessing, or re-signing as algorithms age.

34. Added

    Failure mode: **temporal decay**, where old evidence can no longer be validated or distinguished from tampering.

35. Added

    ### 7.4 Revocation-aware history

36. Added

    Archives record not only what was published but what was later revoked, corrected, or superseded, so historical states are reconstructable without reasserting withdrawn claims.

37. Added

    Failure mode: **frozen falsehood**, where retracted material persists as apparently valid evidence.

38. Added

    ### 7.5 Access, privacy, and proportionality

39. Added

    Archival access is scoped so that auditability does not become surveillance: sensitive records support redaction, aggregation, or proof-of-existence disclosure rather than full exposure (DP4 linkage).

40. Added

    Failure mode: **archive as attack surface**, where preserved evidence creates new privacy harm.

41. Added

    ### 7.6 Reconstruction guarantees

42. Added

    Participants and auditors can reconstruct, for a given artifact or decision, what existed, who acted, under which policy, and what changed afterward.

43. Added

    Failure mode: **unreconstructable history**, where records exist but cannot answer accountability questions.

44. Rewritten

    ## 6.8. Governance, Accountability, and Agency Surfaces

45. DP15 requires that security and provenance are not only visible but **actionable within governance and participant agency systems (DP8, DP2)**.

46. 9 unchanged paragraphs

47. - **non-actionable verification** (signals exist but do not affect outcomes) - **accountability gaps** (no mechanism to enforce correction) - **verification fatigue** (users overwhelmed and stop checking signals)

48. Rewritten

    ## 7.9. Incentives and Power Analysis

49. Security and provenance exist within strong incentive gradients that often discourage their full implementation.

50. 9 unchanged paragraphs

51. - **security underinvestment** due to misaligned incentives - **credibility arbitrage** where actors benefit from unverifiable claims - **attacker asymmetry** where defense costs exceed attack costs

52. Rewritten

    ## 8.10. Community Signals Informing DP15

53. - fatigue with unverifiable claims - demand for signed exports and build transparency - concern about AI hallucination presented as fact - calls for meaningful postmortems after failures

54. Rewritten

    ## 9.11. Non-Goals and Explicit Boundaries

55. DP15 does not:

56. - require all content to be signed or verified - eliminate all risk - replace legal or forensic systems - mandate a specific cryptographic approach

57. Rewritten

    ## 10.12. Minimum Alignment (Non-Normative)

58. Minimum alignment defines the threshold at which security and provenance become **reliable verification infrastructure rather than optional features**.

59. A system claiming DP15 alignment MUST satisfy the following conditions:

60. Rewritten

    ### 10.112.1 Artifact Integrity

61. - Critical artifacts MUST be signed or otherwise integrity-protected - Systems MUST verify integrity at use time, not only at creation

62. Failure mode: **implicit trust of unverified artifacts**

63. Rewritten

    ### 10.212.2 Provenance Availability

64. - High-stakes artifacts MUST carry provenance metadata (origin, transformation, context) - Systems MUST signal when provenance is missing or degraded

65. Failure mode: **provenance absence or stripping**

66. Rewritten

    ### 10.312.3 Verification Pathways

67. - Participants MUST be able to verify claims without specialized expertise - Systems MUST provide both simple indicators and detailed inspection paths

68. Failure mode: **unusable verification systems**

69. Rewritten

    ### 10.412.4 Tamper-Evident Logging

70. - Critical events MUST be recorded in tamper-evident logs - Logs MUST support independent verification or witnessing

71. Failure mode: **log manipulation or selective disclosure**

72. Rewritten

    ### 10.512.5 Key and Identity Integrity

73. - Signing keys MUST have visible ownership, rotation, and revocation status - Systems MUST detect and signal compromised or invalid keys

74. Failure mode: **undetected key compromise**

75. Rewritten

    ### 10.612.6 Cross-System Preservation

76. - Integrity and provenance MUST persist across exports and integrations - Systems MUST signal degradation when preservation is not possible

77. Failure mode: **silent integrity loss across systems**

78. Rewritten

    ### 10.712.7 AI Output Traceability

79. - AI-generated outputs MUST be labeled and include relevant provenance when claims are made - Systems MUST distinguish attributable vs. non-attributable outputs

80. Failure mode: **AI attribution ambiguity**

81. Rewritten

    ### 10.812.8 Auditability and Contestability

82. - Participants MUST be able to inspect, compare, and challenge evidence - Systems MUST preserve records necessary for dispute resolution

83. Failure mode: **evidence opacity or loss**

84. Systems that omit verification, provenance, or auditability MUST NOT be considered aligned with DP15.

85. Rewritten

    ## 11.13. Open Questions and Future Work

86. - balancing privacy with auditability - scaling verification without overwhelming users - cross-border evidence standards - decentralized witnessing vs cost tradeoffs - quantum-resilient cryptography planning

87. Rewritten

    ## 12.14. Relationship to Other Desirable Properties

88. - DP1: attribution and appeals - DP4: integrity of data handling and exports - DP7: interoperability of signed artifacts - DP11–DP13: AI traceability and containment - DP14: transparency practices - DP16–DP17: roadmap and funding alignment for security

89. Rewritten

    ## 13.15. Foresight and Failure Design

90. DP15 assumes breach, key compromise, and manipulation attempts will occur.

91. Systems must predefine response pathways, including key rotation, participant notification, and audit procedures.

92. Rewritten

    ## 14.16. Path Toward ML-RFC

93. - standardize provenance formats for content and AI outputs - align with emerging supply-chain and identity standards - develop reference implementations for high-assurance zones

94. Rewritten

    ## 15.17. Closing Orientation

95. DP15 is where the meta-layer moves from claims to evidence.