Notion audits
The question: Can an AI-powered audit system in Notion track content quality improvements over time, not just at a point in time?
The answer: Yes, and the iterative approach revealed failure patterns that a single audit would never have found.
The experiment in two parts
Part 1: Building the audit infrastructure
The starting point was five audit skills built for an Ikigai app: UX, Code Quality, Content Accuracy, Accessibility, and Security. Each skill was a structured prompt that generated expert-persona findings. The problem: the findings existed only as chat artifacts.
The solution was a Notion database system, ten databases in total, five for audit sessions and five for individual findings, with proper schemas and relations between them. Building ten properly-structured Notion databases manually would have taken significant time and introduced schema inconsistencies.
Instead: Notion MCP was connected and Claude was given the schema design and asked to build it. The databases were created with correct property types, select options, number fields, and cross-database relations, in a fraction of the time.
The lesson wasn't "AI builds databases faster." It was: when the schema is well-defined, execution is delegatable: IA work is defining the schema. The building is a downstream task.
Part 2: Iterative auditing as a method
The second experiment was methodological. Rather than fixing findings immediately after each audit, the experiment ran all five audits first, accumulating a complete picture before making any changes.
The post "Iterative auditing as a progress tracking mechanism" is honest about the tension: accumulating findings before acting can become a form of analysis paralysis. But the complete picture revealed something a sequential fix-audit-fix approach would have missed: three of the five audit types surfaced the same underlying structural issue from different angles:
A UX finding about confusing navigation, a code quality finding about component coupling, and a content accuracy finding about inconsistent terminology were all symptoms of the same architectural decision made early in the build. Fixing them sequentially would have addressed each symptom. The iterative approach revealed the cause.
The content governance connection
The Notion audit system is a content governance tool built from first principles. It has:
- A schema (the ten-database structure with defined properties)
- A taxonomy (five audit types with consistent finding categories)
- A workflow (session → findings → linked fixes → re-audit)
- A measurement layer (progress tracked across iterations)
And it's built in Notion, a tool most teams already use, with AI handling the schema implementation work. That's what a content governance system for documentation actually looks like.
Related work
The content analytics Insights page in this portfolio applies the same iterative audit logic to documentation. Rather than fixing one content issue at a time, the insights page synthesizes all signals first and prioritizes the highest-leverage interventions. The rollback content gap, the simulation drop-off, and the Modernization Advisor under-documentation are connected. They're all symptoms of the same pipeline-comprehension problem.
The Notion audit experiment is where that synthesis-before-action discipline was developed.
Original posts: