DAM governance
Purpose: Keep the asset library findable, rights-clean and performant as it grows from hundreds to hundreds of thousands of assets.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Content ops / DAM owners | Primary |
| All engineers | Enforcement mechanics |
The four disciplines
| Discipline | Rule | Enforcement |
|---|---|---|
| Structure | Folder taxonomy by domain/brand (/content/dam/phi/plans/heroes), not by uploader or date | Folder ACLs; naming convention linting (a scheduled report, not manual policing) |
| Metadata | Mandatory schema per folder: title, alt text, rights, expiry | Metadata schemas + required-field enforcement on upload |
| Rights | Every asset carries licence/usage rights; expiring rights get expiry dates | Expiry field drives scheduled deactivation + report |
| Lifecycle | Draft → approved → published → archived; only approved assets referenceable in components | DAM folder structure + asset status; component pathfield roots |
The expiry problem (the one that reaches legal)
Stock photography licensed for 2 years, still on the PHI homepage in year 3. Controls: expiry metadata on ingest, scheduled job surfacing assets expiring in 60/30/7 days to the DAM owner, and automatic unpublish on expiry (with the referencing-pages report attached so content ops can fix pages proactively).
Performance/scale governance
- Renditions policy: which renditions generate on ingest (each adds processing + storage ×N assets); web-appropriate sizes, not just defaults (DAM & assets).
- Bulk ingests are ops events: schedule off-peak, watch workflow queues, don't let a 10k-asset drop stall daily authoring (monitoring).
- Duplicate control: hash-based duplicate reports; the same hero image uploaded 14 times is cache and storage waste plus governance debt.
- Version/rendition growth feeds repo housekeeping (archiving).