Where Human Approval Belongs in Automated Knowledge Cleanup
Learn where to place review checkpoints in automated document cleanup workflows, how to retain protected source records while publishing curated views, and what audit evidence a review process should capture.
Automated cleanup can flag duplicates, stale statements and broken links, but a candidate is not permission to change accepted knowledge. Place human review where an action changes business meaning, removes relied-on evidence or expands access. Routine discovery and carefully tested draft formatting can run under policy.
This is a recommended governance design, not a claim that every knowledge product ships these controls or that every organization needs identical approval rules.
Choose the review boundary by consequence
| Action | Recommended boundary | What to verify |
|---|---|---|
| Detect and stage candidates | Automate within authorized scope | Read permissions, sensitive candidate reports, false positives; do not mutate accepted knowledge. |
| Format an unapproved draft | Automate under tested policy | Meaning and permissions remain unchanged. Metadata tags can affect routing or access and are not automatically low risk. |
| Merge claims or revise accepted procedures | Domain owner reviews the exact proposal | Authoritative evidence, exceptions, effective dates and downstream impact. |
| Archive or supersede active knowledge | Owner reviews affected workflows | Replacement coverage, retrieval changes and recovery plan; reversible does not mean harmless. |
| Permanently delete records | Designated authority follows applicable policy | Retention, holds, privacy obligations, scope and irreversible consequences. |
| Expand access | Authorized access owner reviews | Recipients, purpose and least privilege, including derived content and citations. |
Approval reduces risk; it does not guarantee correctness or security. Combine it with tests, bounded permissions and accountable owners. The NIST AI RMF 1.0 addresses oversight roles in GOVERN 3.2 and contextual oversight in MAP 3.5. It is voluntary guidance, not a rule requiring manual approval for every cleanup operation.
Separate sources, proposals and accepted knowledge
Keep source identity and revision distinct from a curated answer or summary. Untracked overwrites can destroy useful lineage. Preserve or dispose of source records according to applicable access, retention and deletion policies; provenance does not mean keeping every record forever.
Semantic similarity compares representations of meaning. It does not establish authority, equivalence or permission to delete. Similar policies may apply to different products or jurisdictions. A newer draft may be less authoritative than an older approved policy. Conflicts require an owner to examine scope, effective dates and supporting evidence.
The W3C PROV-O model provides concepts for entities, activities, attribution and derivation. These can inform lineage design without implying that an implementation is certified or complete.
Approve an exact, evidence-backed proposal
A review packet should identify the immutable proposal version or diff hash, affected record IDs, base revisions, proposed changes and downstream dependencies. Attach authoritative source IDs, revisions and relevant passages. Similarity scores and age thresholds explain why a candidate was flagged; they are not sufficient evidence that a proposed change is correct.
Record the designated reviewer, authorization scope, policy version, decision and decision time. Bind approval to that exact proposal. Changes to the diff, scope or evidence require the appropriate new review; an old approval must not silently authorize a broader operation.
Check again when executing
Approval and execution may occur hours apart. At execution, validate current executor permissions, approval validity and reviewer authority as required by policy. Revoked access must not survive through a cached approval. Check applicable retention or hold constraints for the specific action.
Revalidate the bound evidence revisions, policy and dependency conditions as well as the target base revision. If any material condition has changed, stop for fresh review. Enforce the expected revision preconditions as part of the write, using an atomic conditional update or equivalent concurrency control. A separate read-then-write check leaves a race in which another change can intervene. If the precondition fails, stop the affected operation, record the conflict and generate a fresh proposal for review.
Separate proposer, reviewer and executor responsibilities where the risk warrants it. A proposer can identify candidates without receiving permission to commit them. Human reviewers can use a review interface; an automation service can execute only the approved scope.
Plan for partial batches and protected audit records
Use an atomic transaction when supported and suitable. Otherwise record each item's outcome. If a five-item batch fails on item four, do not assume the first three were rolled back. Stop dependent work, reconcile actual state, and retry only eligible operations with idempotency controls. Compensating changes require authorization and are possible only where the action supports them; permanent deletion has no general undo guarantee.
Log proposal and decision IDs, reviewer identity, policy version, timestamps, revision preconditions, permission-check outcomes and execution results. Do not store raw approval tokens, credentials or unnecessary sensitive payloads. Protect audit records with their own access and retention rules.
Revision history, including Git where used, can show changes and recorded authorship. That authorship alone does not prove an authenticated approval, and content history does not capture every rejected proposal or authorization decision. History, audit evidence and tested backups serve different purposes.
A hypothetical review queue
Suppose a cleanup tool finds one refund policy stating 30 days and a newer draft stating 14 days. Neither similarity nor recency establishes which rule is effective. A domain owner reviews authoritative evidence, scope and exceptions before approving a proposed replacement. If the base policy changes while awaiting execution, its old approval cannot authorize overwriting the new revision.
For workload planning only, assume 40 proposals per day and 3 minutes of review per proposal: 40 × 3 = 120 minutes, or 2 hours daily, before escalations, rework and meetings. These are illustrative inputs, not industry benchmarks or AKB performance results.
| Measure | Definition and use |
|---|---|
| Queue age | Median, p95 and oldest pending proposal age; report sample size and time window. |
| Rejection / modification rate | Rejected or modified proposals divided by reviewed proposals in a defined cohort; report pending items separately. |
| Escaped defects | Applied changes with confirmed defects divided by applied changes examined within a defined follow-up window; not a direct measure of reviewer accuracy. |
| Handling time | Review and escalation time by action type, alongside backlog and rework. |
Blocking an unauthorized request is expected control behavior. Before enabling writes, test expired approvals, revoked authority, changed base revisions, partial failures and retrieval of withdrawn content. Assign an owner to investigate failures and verify index, cache and derived-content updates.
Where AKB fits
AKB's public repository describes a read/write knowledge store with documents, tables, files, explicit relations and hybrid retrieval. People can work through the Web UI or APIs, while agents can use MCP. As checked on September 28, 2026, the public README describes PostgreSQL-native revisions as the default and explicit Bare Git support for legacy deployments. Verify the installed version and configuration rather than assuming every deployment uses Git or the current default.
Core storage is distinct from external curation and approval orchestration. The review packets, execution gates and audit controls described here are deployment requirements to evaluate and implement; they are not claims of a built-in AKB approval engine or autonomous gardener.
Frequently asked questions
Does every cleanup action need human approval?
No. Authorized candidate detection and tested low-risk draft formatting can run under policy. Place review gates according to meaning, authority, access, reversibility and downstream impact.
Can similarity or the newest timestamp resolve a conflict?
No. They can prioritize review, but authority, applicability and effective dates determine whether claims can be consolidated.
What happens if content changes after approval?
The execution precondition must reject the stale write. Review a new proposal against current evidence rather than reusing the old approval.
Is revision history enough for an approval audit?
No. Keep authenticated decisions, authorization outcomes and execution evidence separately, with protected access and appropriate retention.
Does AKB automatically provide this entire workflow?
The public Core store is a foundation for external workflows. Verify the actual deployment's review, authorization, execution and recovery behavior before relying on it.
Learn more
Learn more about Dnotitia and evaluate the knowledge infrastructure against your review and operating requirements.