Privacy, retention, audit, and protected upload contract

Bounded candidate reference — 2026-10-20: 0.2.0-rc.1 is committed locally through 84f415b3098af5653577b2c65eea31fca21df79c, unpublished and not production-approved; stable PHP >=8.5.11 <8.6.0 is required. This is documentation, not adoption: this knowledge base retains its installed 0.1.0-rc.1 dependency and PHP 8.2.11 local profile. Dated PHP 8.2 evidence is historical; earlier dirty-source reports retain their original test provenance, not retroactive clean-commit proof. Candidate examples are illustrative: API signatures were reviewed, but candidate code was not executed by this editorial update. See current checkpoint, open criteria and adoption boundary.

Clean Framework supplies classification and execution mechanics without deciding an application's lawful purpose, record schedule, data ownership, or legal-hold policy.

Classifications

DataClassification provides stable values for public, internal, confidential, personal, authentication-secret, provider-credential, financial/support-evidence, and immutable audit/security metadata. Applications attach these values to their schemas, DTOs, storage metadata, and retention rules; the framework does not infer classification from a field name.

Retention execution

Applications implement RetentionRepository::candidates() and applyWithAudit(). Candidate results carry identifiers and classification but never the record payload. The service supports purge, anonymize, and detach, with a batch ceiling of 1,000.

• Dry-run is the default and performs no mutation.
• Held candidates are reported and never changed.
• Live execution requires an approval reference and a verified backup or checkpoint reference supplied by the application/deployment workflow.
• applyWithAudit() must write the mutation and AuditEvent in one database transaction, or write the mutation and transactional audit outbox entry in one transaction.
• Schedules, lawful basis, restoration behavior, and backup retention remain application/deployment policy.

Append-only audit

AuditEvent rejects nested, oversized, or sensitive-key metadata. The local FileAuditSink appends one newline-JSON record under an exclusive lock and offers bounded read-only search. Multi-node/database applications bind a durable sink and control export through application authorization and audit. No sink exposes update/delete operations for historical records.

Protected upload flow

The intended order is:

• PHP accepts a bounded upload outside the public directory.
• FileinfoUploadInspector derives an allowlisted MIME type and extension from bytes, never client metadata.
• An application MalwareScanner fails closed or returns a clean result.
• InspectedUploadService publishes to opaque PrivateStorage.
• Metadata and ownership are committed by the application.
• Reads pass through ProtectedFileService and exact object policy.

Filesystem permissions, scanner availability/failure posture, database metadata transactions, and deployment-specific quarantine remain integration requirements. Never use the public asset cache for protected media.

Editorial provenance

Source: docs/PRIVACY_AND_RETENTION.md. Source SHA-256: 0715e0618c28dd69556821e35c2a93bd0d39e7a9bbb1d7f4b43a3fe87966640e.

Framework candidate reference; editorial checkpoint 2026-10-20. See candidate status and adoption boundary.