Auditing

An audit is not a search problem. The auditor's difficulty is rarely finding a document — it is knowing what the population was, whether the record moved while they were reading it, and being able to show afterwards what they examined.

KF is built so that those three questions have answers.

The audit view

/audit?id= composes into one page the things an auditor would otherwise have to know KF well enough to go and assemble by hand.

Provenance. Which database this is, how many items, edges and revisions it holds, when it was last written, and the revision of the configuration. Record these in the audit plan. Any edit to the requirement library during the audit period is itself a finding, and this is what makes that checkable.

The register, reconciled. Requirements, rows, headings, and what is rolled up beneath — with the arithmetic checked and shown as a badge. See the compliance register.

Recent changes, and the note that adding &since=YYYY-MM-DD turns it into a drift report against the opening meeting.

Findings already on the record, counted by grade: major, minor, observation.

A stable read

The database is live. Somebody may be writing to it while the audit is running, which means the same question asked twice can honestly give two different answers.

Every read can be pinned to a moment — as_of on the API and the MCP endpoint, and a date in the web interface. Pin to the opening meeting and two identical questions hours apart agree. When a page is showing history rather than the present, it says so in a banner that cannot be dismissed, because an auditor who does not notice they are reading last month's record is worse off than one who cannot read it at all.

Showing what you examined

KF keeps an append-only journal of who read what, when, by which route, with which arguments, and how much came back.

Two decisions about that journal are worth knowing:

It is written beside the database, not as a table inside it. The MCP surface is read-only by design, and a read tool that quietly writes a row into the organisation's own store would break that promise.

It records coverage, not content — enough to reconstruct what was examined, and deliberately not the payloads. Logging the answers would create a second copy of the auditee's records in a place with weaker protection than the original.

GET /api/audit-trail returns it.

Every export carries its provenance

An auditor's file has to make sense months later, to someone who was not there. Every export — the register as CSV or Excel, any listing as CSV, the FMEA either way — carries a header naming the database, the build, the filter that produced it and the time it was taken.

The guide ships with the product

An external auditor arrives with read access and no knowledge of KF. Sending them a PDF by email is the wrong shape: the guide has to be where they already are.

So it is served from inside the running instance, at /info/audit, beside the evidence — along with an engagement checklist at /info/audit-checklist covering access, provenance, criteria, confidentiality and the method commitments to settle before the opening meeting.

Revisions

Every revision of every item is kept, with the author, the time, and what the author said changed. Any revision can be read on its own, and diff shows one against the one before it — which is what makes the version message checkable rather than merely present.