# Audit scope outline: what a content model audit covers and what it hands you This is the table of contents of a finished content model audit, where every section is a deliverable, not a meeting. Tick each deliverable you want in scope, whether you are briefing a supplier, checking a proposal against it, or structuring an audit you run yourself. The count at the side updates as you go, and the export is the scope you hand over. ## Before the audit starts - **Access needed.** An administrator login to the content system. No access to the codebase or hosting is required to begin; anything that turns out to need it is recorded as an open question. - **People needed.** The person who publishes most, and whoever holds the technical contact role, even if they have no history with the system. - **Scope statement.** One paragraph naming the system, the sites or channels it feeds, and the publishing activity the audit should cover. This stops the audit drifting into a platform review. ## How to read the outline The six sections below run in the order the audit runs them: the inventory and taxonomy come from the administration interface, the usage analysis and workflow observations come from the published content and the person who publishes, and the recommendations and the repair or rebuild position are built on the four sections before them. Ticking everything describes the full audit. Leaving a section unticked is a scoping decision, and it is worth writing down why. ## Audit scope ### 1. Inventory of content types and templates Every type and template the system offers, against how many published items actually use it and when it was last used. - [ ] Content type register Every content type, with its fields, the number of published items using it and the date of the most recent one. - [ ] Template register Every template or page layout available to editors, with how many items use it and when it was last selected. - [ ] Dead and duplicate entries Types and templates with no recent use, and pairs that serve the same purpose, marked for a decision rather than decided here. ### 2. Taxonomy map Every tag and category with its usage count, and the merge and retire decisions that leave editors one list to work from. - [ ] Term inventory Every tag, category and other classification term, with its usage count and its parent where a hierarchy exists. - [ ] Overlap and conflict Terms that mean the same thing, terms superseded but never closed, and places where two generations of classification coexist. - [ ] Proposed target taxonomy The surviving terms, the merges, the retirements, and the rule for adding new terms, written so an editor can apply it without asking. ### 3. Usage analysis What the published content shows about which parts of the model are real and which are theoretical. - [ ] What actually gets published The small number of content shapes that account for the large majority of recent items, as opposed to the full list the system allows. - [ ] Field usage Fields that are always filled, always skipped, or always copied from a previous item. - [ ] Volume and age How much content is live, how much is stale, and how much is orphaned from any current navigation or listing. ### 4. Editor workflow observations Sit with the person who publishes most and watch one article go out. Every field they skip, every value they copy and every step they do outside the system is a note about the model. - [ ] Publishing path as performed A step by step record of how a real article goes out today, including every step done outside the system. - [ ] Workarounds in use Each workaround, what it compensates for, and whether the cause is a missing feature, a missing permission or a missing decision. - [ ] Broken versus unfamiliar A clear split between things that do not work and things that work but nobody was shown, because the two need very different fixes. ### 5. Prioritised recommendations What can change now without development, what to build next and in what order, and what the audit could not settle. - [ ] Immediate Changes an editor or administrator can make now with no development, usually in the taxonomy and in which templates are visible. - [ ] Short term The reusable template set to build, in order, with the taxonomy decisions each one depends on. - [ ] Open questions Anything the audit could not settle without code or hosting access, with who can answer it. ### 6. Repair or rebuild position The answer in one sentence with the evidence behind it, so the document works as a brief for whoever does the work. - [ ] The position Repair, rebuild, or repair now and revisit, stated in one sentence. - [ ] The evidence The structural distance between the current and target model, the viability of the platform, the in house capability to own the result, and the cost of current workarounds, each with the finding that supports it. - [ ] What either path needs The decisions, access and people required before the next phase can be scoped, so the document works as a brief for whoever does the work. Bring the ticked scope, your one paragraph scope statement and the open questions to the audit conversation with whoever will run it, including your current supplier. Every ticked item is something you expect back in the document, and the document is yours whatever you decide afterwards.