A finding without a URL is a sentence, not a task
Most audit output is stored as prose. Prose does not deduplicate, does not sort, and cannot tell you whether the same problem came back.
Vishal Chiniwar Co-founder and CTO 28 July 2026
What an audit actually produces
Open any audit deliverable and the unit is a paragraph. Several pages have missing alt text. The heading structure is inconsistent across templates. Some internal links point at redirects. Pricing information appears in multiple places and is not consistent.
Every one of those statements is true and none of them is actionable without further work. Which pages. Which templates. Which links. Somebody now has to reconstruct the specifics that the auditor already had and did not record in a form that survived.
That reconstruction is where most audit value is lost. Not in the finding, which was correct, but in the gap between a person knowing something and a system holding it.
The auditor is usually not at fault here. They found the specific pages, they looked at the specific components, and they knew exactly which links pointed at redirects. Then they wrote a report, because a report is what was commissioned, and the report format required them to summarise. The specifics existed and the deliverable had nowhere to put them.
What prose cannot do
It is worth being precise about the failure, because the remedy follows from it directly.
Prose does not deduplicate. If the same problem is described in two audits by two people in different words, nothing connects them, so a recurring issue looks like two separate discoveries.
Prose does not sort. There is no way to rank forty paragraphs by anything except the order somebody wrote them, so priority becomes a judgement made in a meeting rather than a property of the data.
Prose does not assign. A sentence cannot be owned. A row can.
Prose does not close. There is no state on a paragraph, so six months later nobody can distinguish a finding that was fixed from one that was read and forgotten. That is the failure that costs the most, because it means the next audit rediscovers everything and the client pays twice for the same knowledge.
The second audit finding the same problems is not a sign the site is bad. It is a sign the first audit was not stored in a shape that could be closed.
The six fields
A finding becomes a task when it carries six things. Fewer than six and one of the failures above returns.
The table below is the record shape we work to. The right hand column is what specifically breaks when that field is missing, which is the argument for each one.
| Field | What it holds | Why it is needed | What breaks without it |
|---|---|---|---|
| URL or entity id | The specific page, by stable identifier | Locating the problem | Somebody re finds what the auditor already found |
| Component | Which component or template produced it | Deciding whether to fix one page or one component | Forty page level fixes instead of one component fix |
| Cause | Why it is there, not what it looks like | Preventing recurrence | The same finding returns next quarter |
| Fix | The specific change proposed | Making it assignable to somebody who was not in the audit | A discussion instead of a task |
| Owner | A named person, not a team | Anything happening at all | It sits in a document |
| Verification | How you will know it is fixed, and when it was checked | Closing it, and detecting regression | Fixed and forgotten are indistinguishable |
Cause is the field that pays
If only one field were added to a typical audit, it should be cause, and it is the one most often collapsed into the finding itself.
Missing alt text on forty images is a symptom. The cause is one of several very different things: the CMS does not require the field, so nobody fills it. Or the field exists and the upload flow does not surface it. Or an import brought images in without it. Or one editor was never told.
Those four causes have four different fixes, and only one of them is writing alt text for forty images. Fixing the symptom without recording the cause guarantees the finding returns, which is exactly what the second audit discovers.
The discipline is to write cause as a sentence about a mechanism rather than a restatement of the symptom. Not alt text is missing. The CMS image field does not require alt text and the upload flow does not prompt for it.
The other reason cause earns its place is that it determines who the finding belongs to. A cause that is a missing CMS constraint belongs to whoever owns the data model. A cause that is one editor not knowing a convention belongs to whoever owns onboarding. A cause that is an import belongs to nobody currently, which is itself worth discovering. Symptom level findings all land in the same queue regardless of who could actually prevent them recurring.
Component, and the difference between forty fixes and one
The component field does the same job at a different level, and it is what turns a long finding list into a short work list.
An audit that reports a focus problem on twelve pages is reporting one component problem twelve times, if those twelve pages use the same card. Recording which component produced the finding lets you collapse the list, and the collapse is usually dramatic. Long audits are frequently a small number of component problems distributed across many pages.
It also changes who does the work. Page level findings go to whoever edits pages. Component level findings go to whoever owns the design system, and they fix instances that do not exist yet.
This is the field that makes an audit cheaper to act on than to produce, which is not the normal relationship.
Verification is what makes it a loop
A finding without a verification step has no closed state, and a record with no closed state accumulates until people stop reading it.
Verification has two parts. How you will know it is fixed, written before the fix, which is usually the same check that found it. And when it was last confirmed, so a finding closed a year ago can be distinguished from one closed last week.
The second part is what turns the audit record into a regression detector. If a check that passed six months ago fails now, that is not a new finding. It is a recurrence, and a recurrence is a different and more interesting fact than a discovery, because it means the fix did not address the cause.
Recurrence is the single most valuable output of a system like this, and it is precisely the thing prose cannot express, because two paragraphs written six months apart by different people have no relationship.
There is a practical shape for the check that keeps this cheap. Write it as something a person or a script can run in under a minute, against a named URL. Alt text present on every image on this page. Focus returns to the trigger after this modal closes. This page states one price and it matches the pricing page. Checks written like that can be automated later without being rewritten, and checks written as this issue should be resolved cannot.
Severity is less useful than it looks
Most audit formats carry a severity field and it usually does less work than expected, so it is worth saying why we deprioritise it.
Severity is a judgement made by the auditor about somebody else's business. A broken link on a page nobody visits and a broken link in the middle of the main buying path are the same finding and wildly different problems, and the auditor frequently cannot tell which they are looking at.
What sorts better in practice is a combination of how many pages are affected, whether it sits on a page the business cares about, and whether the cause is a component or an instance. All three of those are properties you already have if the six fields are populated, and none of them requires the auditor to guess at commercial importance.
Keep severity if it helps a conversation. Do not sort by it.
Converting an audit you already have
Most teams reading this have a recent audit sitting in a folder rather than a blank slate, so the practical question is how to convert one rather than how to commission a better one.
It takes about an afternoon for a typical deliverable and the conversion itself surfaces things. Roughly a third of the findings in any audit I have converted turned out to be the same component problem stated several ways, and that collapse is visible only once you are forced to name the component per row.
Work through it in this order. Anything you cannot fill in is a finding about the audit rather than about the site, and it is worth telling whoever produced it.
Turning an audit document into records
- Split every paragraph into one row per affected page. Resist summarising.
- For each row, write the URL. If the finding does not name one, mark it unlocated and count how many of those you have.
- For each row, name the component or template. Collapse rows that share one.
- For each row, write a cause that is a mechanism, not a restatement of the symptom.
- Where the cause is unknown, write unknown rather than guessing. Count those too.
- Put one person's name on each row. Not a team.
- For each row, write the check that will confirm it is fixed, before anybody fixes it.
- Keep the original document. It is the communication artifact and the rows are the system.
Where teams get this wrong
Storing the audit as the deliverable. The document is a communication artifact. The record is the thing that has to survive, and a PDF is where findings go to be read once.
Aggregating across pages too early. Several pages have this is a summary, and the summary is what gets kept while the specifics are discarded. Keep instances, derive summaries.
Recording symptoms as causes. Missing alt text is not a cause. It is what you can see.
Assigning to a team. A team is a place where a task waits.
No verification date. Without it, the honest answer to whether something is fixed is that somebody thinks so.
Running a second audit rather than reopening the first. If the previous findings were not stored in a closeable shape, a second audit is the only option available, which is how the same knowledge gets bought twice.
What good looks like
An audit practice working well does not produce a bigger document. It usually produces a smaller one, because component level collapsing shortens the list dramatically.
Concretely: every finding names a URL or an entity and a component. Causes are mechanisms rather than restatements. Each finding has one person's name against it. Closed findings carry a date and the check that confirmed them. And the interesting part of the quarterly review is the recurrence list rather than the new findings, because recurrence tells you where the cause was misdiagnosed.
The clearest signal is what happens at the second audit. If it finds mostly new things, the first one was stored properly. If it finds mostly the same things, the record shape was the problem rather than the site.
Where this connects to what we are building
Creogen is a website operations platform in private development, and this record shape is close to its core data model rather than a feature of it.
The design consequence worth naming is that the URL field is an entity reference rather than a string, for the reason described in the architecture piece: URLs move, and a finding attached to a URL that no longer resolves is a finding you have lost. Attaching it to an entity means a slug change is an event on a thing you are still tracking.
The other one is that verification is not optional in the schema. A finding cannot be created without a stated check, because a finding you cannot close is a finding that will be rediscovered, and an optional field for something nobody enjoys writing is an empty field.
None of this requires our tooling. The six fields are six columns. A spreadsheet with those columns, populated honestly, is better than most audit deliverables I have seen, and it costs an afternoon to set up.
Related reading
Nobody wrote down what the change was supposed to do
Which is why nobody can say whether it worked. The measurement problem on most sites is not instrumentation. It is that no expectation was recorded before the change.Vishal Chiniwar30 June 2026An audit is a snapshot of a system nobody is holding in place
Accessibility fails at the point it stops being checked, which on most projects is the week after the report was delivered.Vishal Chiniwar7 August 2026Architecting a system that has to be right about someone else's website
Every hard problem in a website operations platform is the same problem: the system is reasoning about state it does not own and cannot lock.Vishal Chiniwar13 May 2026
Questions this raises
It is a judgement the auditor usually cannot make well, because they do not know which pages the business cares about. Affected page count, whether the page matters commercially, and whether the cause is a component all sort better and are already present if the six fields are filled in.
Record that you cannot, explicitly, rather than restating the symptom in the cause field. An unknown cause is a real state and it tells you the finding is likely to recur, which is more useful than a plausible sounding guess that closes the question.
Both, and the document should be generated from the system rather than being the system. A document communicates. A record closes, deduplicates and detects recurrence, and only one of those two things survives contact with the next quarter.
One row per affected page, then fill in URL, component, cause, fix, owner and verification. It takes an afternoon and about a third of the findings usually collapse into a small number of component problems once you are forced to name the component per row.
Keep it if it helps a conversation and do not sort by it. Severity is a judgement the auditor makes about somebody else's business, and they usually cannot tell whether a broken link sits on a page nobody visits or in the main buying path. Affected page count and whether the cause is a component sort better.
Something a person or a script can run in under a minute against a named URL. Alt text present on every image on this page. Focus returns to the trigger after this modal closes. Checks written that way can be automated later without being rewritten. This issue should be resolved cannot.
Look at what the next audit finds. Mostly new things means the first one was stored properly. Mostly the same things means the record shape was the problem rather than the site, and you have just bought the same knowledge twice.
An audit nobody can act on is a document, not a tool.
The useful unit is a URL, a problem and a fix. Bring your last audit and we will see how much of it is actionable.
Creogen ties every finding to a URL and a change. Reports that cannot be acted on were the thing we set out to kill.