KnowledgeHarvester writes directly to KNOWLEDGE/<domain>/ — bypasses _harvest-queue/ curation step described in README

[nbost130]

Summary

Tools/KnowledgeHarvester.ts writes harvest output directly into KNOWLEDGE/People/, KNOWLEDGE/Companies/, etc. — but KNOWLEDGE/README.md and the architecture summary describe a _harvest-queue/ curation gate that should sit between auto-harvest and committed knowledge:

"KNOWLEDGE/ is curated and structured. Entries follow a frontmatter contract... Harvesters elsewhere in MEMORY/ propose candidates that get promoted into here only after curation."
— MEMORY/KNOWLEDGE/README.md

The _harvest-queue/ pattern is also referenced in PAISystemArchitecture.md and the Memory pipeline section: Tools/SessionHarvester.ts --mine → KNOWLEDGE/_harvest-queue/.

But in practice, KnowledgeHarvester.ts skips the queue and promotes directly:

✅ Ideas/design-provider-abstraction-layer-for-swappable-services.md
✅ Companies/worktree-sprint-security-perf-decompose-quick-wins.md
✅ People/fix-n1-queries-and-add-code-splitting.md

The third entry is plainly miscategorized — "Fix N+1 queries" is an Ideas-class technical idea, not a Person. Without the queue, it lands in KNOWLEDGE/People/ where it pollutes the entity graph until the user manually moves it.

Repro

1. Run bun KnowledgeHarvester.ts harvest against any session corpus that includes mixed-domain content (technical work, person mentions, company references).
2. Inspect the output paths — they go straight into KNOWLEDGE/<domain>/ based on the harvester's classification heuristics.
3. Inspect classification quality — TYPE_KEYWORDS at line ~58-65 is a small fixed keyword list; misclassifications are common.
4. Result: low-quality candidates land in committed KNOWLEDGE/ with no human review step.

In my MemberOS harvest of 10 ISAs:

• 3/5 entries plausibly classified (Ideas/Companies)
• 2/5 entries questionable (1 misclassified as People, 1 marginally a Company)
• All landed in committed KNOWLEDGE/ directly

Why the gate matters

KNOWLEDGE/ is the system's curated long-term memory — what MemoryRetriever.ts reads, what KnowledgeGraph.ts navigates, what the Pulse /knowledge dashboard surfaces, what semantic search in MemoryRetriever keys against. Pollution here propagates downstream into every consumer of the graph. The _harvest-queue/ is the proposed-vs-canonical boundary; bypassing it makes the entire knowledge graph as good as the harvester's classification heuristics, which the existing keyword-list approach explicitly is not.

Suggested fix

Two-line change in the harvest write path:

// Currently:
const outputDir = path.join(KNOWLEDGE_DIR, candidate.domain);

// Proposed:
const outputDir = path.join(KNOWLEDGE_DIR, "_harvest-queue", candidate.domain);

Plus a small companion CLI verb to promote:

bun KnowledgeHarvester.ts promote <slug>             # move queue entry into KNOWLEDGE/<domain>/
bun KnowledgeHarvester.ts promote-all --domain Ideas # promote all Ideas candidates
bun KnowledgeHarvester.ts reject <slug>              # delete from queue
bun KnowledgeHarvester.ts review                     # interactive curation TUI

Promotion preserves the harvested_from: provenance frontmatter that already exists.

The README's curation language already implies this UX — implementation just hasn't caught up.

Migration concern

Users with existing KNOWLEDGE/<domain>/ populated by current direct-write behavior shouldn't lose anything on the change. Suggested compatibility: existing entries stay where they are; _harvest-queue/ only catches new candidates. No backfill needed.

Verified locally

Confirmed direct-write behavior on MemberOS harvest run. The _harvest-queue/ directory does not exist and is never created by current code path. The README's claim that harvest "propose[s] candidates that get promoted into here only after curation" does not match implementation.

Related

• Companion issue: KnowledgeHarvester is single-PAI-instance; per-project memory dirs invisible without PAI_DIR override (filed separately).

[ryan-baum]

Additional reproduction detail from a stock v5.0.0-derived install: I think this is slightly sharper than queue bypass alone. The queue path exists, but it behaves like destructive ingest rather than a curation gate.

Evidence in PAI/TOOLS/KnowledgeHarvester.ts:

• HARVEST_QUEUE_DIR is defined for KNOWLEDGE/_harvest-queue.
• scanHarvestQueue reads JSON files from that directory, converts them to candidates, then deletes the queue files with fs.unlinkSync.
• The normal harvest path appends those queue candidates into allCandidates.
• writeNote then writes candidates directly to KNOWLEDGE/<domain>/<slug>.md.

Net effect: if another tool writes proposed candidates to _harvest-queue expecting review semantics, a normal harvest silently promotes them and removes the queue artifact. So the queue is currently an ingest chute, not a review boundary.

Suggested refinement:

• enqueue or source scanners write proposed candidates to _harvest-queue.
• review lists candidates without mutation.
• promote <slug> moves one reviewed item into canonical KNOWLEDGE/<domain>/.
• reject <slug> archives or deletes one reviewed item.
• default harvest should not consume _harvest-queue unless an explicit flag such as --from-queue or --promote is present.

This also fits the later PAI direction I am using locally: Algorithm LEARN is the deliberate curated writer, while KnowledgeHarvester is better as validation, indexing, review, and promotion infrastructure rather than an unsupervised canonical writer.

One more adjacent input-quality finding: scanResearch currently walks Markdown files by length, so scaffolding such as README.md can be promoted as Research/readme.md. Adding scaffold filename/frontmatter filters before queueing or promoting would keep the Research domain cleaner.

This is additive to the issue above: the direct-write behavior is the main bug, and the extra subtlety is that the existing queue consumer makes _harvest-queue unsafe as a curation boundary until its verbs are separated.

[danielmiessler]

You're right — the harvest CLI still promotes directly instead of staging through the queue, and the keyword classifier is exactly as weak as you describe. The newer memory pipeline gates autonomic writes behind a propose/approve tier system, which is where this is headed; folding the harvester behind the same gate is the plan. Appreciate the miscategorization examples, they make the case well.