Feedback Findings Review — Liam disposition + prereq routing

Feedback Findings Review — Liam disposition + prereq routing

Audit date: 13/05/2026 (S234 open) Inputs: 6 finding docs in 10-feedback-investigation-findings/ (01-06) + 00-synthesis.md (S233 directional) + 0.9-decision-graph.md (S233 13 status patches) + 0.9-collapse-candidates.md (S233 refresh).

Purpose: Captures Liam’s first-pass disposition on every finding + open question, routes each open item to one of the two Phase B prerequisites (Ontology pipeline / Cocoindex deep-dive), and surfaces cross-cutting themes that the prereqs must address.

Reading order: §1 (cross-cutting themes) → §2 (per-finding disposition tables) → §3 (prereq input matrix) → §4 (Liam’s original free-form notes, preserved verbatim for nuance).

---

§1 — Cross-cutting themes (must be addressed by prereqs)

These are themes that surfaced across multiple findings and that neither single finding fully owns. Each is routed to a prereq.

Theme A — Form-type generalisation (BIG)

A form has a type (bid, tender, RFP, PQQ, any form with questions+answers) and a format (.docx, .xlsx, .pdf, .html). A completed form typically has a response. A question+answer combined is a point-in-time citable fact. Some questions are form-type-specific; many transfer across.

Implied work:

• Q&A pairs becoming form-agnostic (Q1.13 implication).
• bid_question_matches → potentially question_matches with question_kind discriminator (OQ-Q113-C agreed in principle).
• form_templates + form_template_fields with form_type discriminator (replaces or extends bid_templates).
• template_requirements likely renamed/refactored.
• New form-extraction pipeline (see Theme B).

Routes to:

• Ontology prereq — defines form / form-type / form-format / question / answer / response as ontology entities + their relationships.
• Cocoindex prereq — defines whether cocoindex’s structured-extraction + entity_resolution capabilities cover this flow.

Theme B — Form extraction pipeline (NEW WORK)

Cover ALL document types (docx, xlsx, pdf, html) at extraction stage. Potential 6-step flow:

1. evaluate-form skill (one per format type) — evaluate form, propose markdown conversion approach. Anthropic doc skills (pdf/docx/xlsx) are baseline; KH-specific skills expand on these.
2. AI-assisted + human QA of conversion approach.
3. Markdown conversion via ‘Structured Outputs’ skill OR reusable cocoindex pipeline converter (base doc type + adaptations — reusable for new/similar form versions).
4. classify-form-data — verify approach from template-driven-completeness-spec.md. Focuses on data once form is markdown.
5. AI-assisted + human QA of classification approach.
6. Moves through cocoindex pipeline.

Evaluate existing assets:

• scripts/extract_tender_questions.py (current PDF Q-text extractor)
• scripts/analyse_template.py
• lib/quality/qa-detection.ts (Pattern A/B/C)
• New .claude/skills/ doc skills: docx, xlsx, pdf, markdown-converter
• Skill-seekers PDF scraper (already chosen — but compare vs cocoindex pdf-to-markdown)

Routes to:

• Cocoindex prereq — does cocoindex pdf-to-markdown + Structured Extraction + entity_resolution cover steps 1/3/4? Where does Structured Outputs sit?
• Ontology prereq — what does a form need to express in the knowledge graph after extraction (questions, mandatory/optional, evaluation criteria, evidence requirements)?

Theme C — Edit / re-classification state-machine

For the user-edit flow (UC1/UC4/UC6 + source-doc explorer in Finding 06):

• (i) Drafting more than one edit in a file → action depends on state (draft / for review / approved) + RBAC. Confirm what’s in place today.
• (ii) Re-classification trigger — ALL edit types? Single-word change? Key-date change? Allow user to decide via UI options?
• (iii) Concurrent-edit handling.

Routes to:

• Cocoindex prereq — does cocoindex re-extract on user-initiated edit-back (OQ-CX33-A)? What’s the freshness/cost trade-off?
• Ontology prereq — is edit_intent (cosmetic / data / structural) a typed concept that drives re-classification?

Theme D — Cocoindex ‘freshness’ integration

Cocoindex has a freshness concept (cited but not detailed in user feedback). Need to understand how this integrates with KH’s coverage / governance / change-reports model.

Routes to: Cocoindex prereq — operational sub-agent (2b) must surface what freshness means + how it integrates.

Theme E — Applications layer above workspaces

Original platform focus = bids. Now broader: “enabling humans and AI agents to complete tasks, using high-quality data.”

Different application shapes:

• bids — apply cited answers to form, state-management, feedback loop.
• sector-intelligence — RSS feeds informing business decisions.
• sales-proposals (next).
• competitor-research.
• training/onboarding.
• product-guides (Phew use case — is this an application or content feeding other apps? Both?)

Each application has different content needs. Not all are Q&A-based.

Routes to: Ontology prereq — define application as an ontology layer above workspaces. What does each app need from content/data perspective? How does this rebound on source_documents vs content_items decision?

Theme F — Mempalace MCP integration pattern

Q4.5: are we using mempalace MCP direct, or wrapping in KH MCP tooling? Decision needed before wire-up checklist.

Routes to: Out-of-scope for prereqs — Liam decision (operational MCP-action review pass per 0.9-synthesis.md §11.1).

Theme G — Doc skills evaluation (parallel to form pipeline)

New .claude/skills/ doc skills: docx, xlsx, pdf, markdown-converter. Plus existing cocoindex skill files. Plus codebase-aware ccc (cocoindex-code) + gitnexus.

Should be evaluated as part of the form extraction pipeline flow (Theme B).

Routes to: Cocoindex prereq sub-agent 2c (doc handling).

---

§2 — Per-finding disposition tables

Each table: item → Liam’s disposition → prereq routing → notes. Items are decisions, recommendations, or OQs from the corresponding finding doc.

2.1 — Finding 01 (source_documents + audit trail) — Wave 1B-1

Disposition status legend:

• DECIDED = ratified now, no further work needed
• DEFER-ONTOLOGY = answer depends on ontology pipeline outcome
• DEFER-COCOINDEX = answer depends on cocoindex deep-dive outcome
• DEFER-BOTH = depends on both
• TBD-OTHER = depends on something other than the two prereqs (e.g. operational MCP review, schema-restructure PR scope)

Item	Liam disposition	Routing	Notes
Recommendation 2 (slim source_documents — retire versioning cols, retain binary manifest) under Option α	DEFER-ONTOLOGY	Ontology	Per OQ-Q19-A. Ontology defines whether source_documents is needed as an entity or whether cocoindex source-key alone carries binary identity.
Recommendation 3 (diff UI fate)	DEFER-COCOINDEX	Cocoindex	Per OQ-Q19-B. Use ccc to confirm if app/api/source-documents/[id]/route.ts has downstream consumers outside diff UI.
Recommendation 4 (upload-route handles binary-only)	DEFER-COCOINDEX	Cocoindex	Per OQ-Q19-C. Does cocoindex binary-shape adapter handle upload? Verify against 0.9-spike-S2 localfs scope. Take account of files no longer uploaded to DB — localfs-only.
Recommendation re upload-route silent-fail at L444-447	DEFER-COCOINDEX	Cocoindex	Per OQ-Q19-D. TBD — dependent on Recommendation 4 outcome.
Backfill for 387 q_a_pair rows	DECIDED	—	OQ-Q19-E: no backfill required.
pipeline_runs retain-vs-retire	DEFER-COCOINDEX	Cocoindex	Per OQ-Q24-A. Determine after cocoindex op-ledger investigation.
audit_log table workspace_id RLS	TBD-OTHER	RLS pattern doc	OQ-Q24-B: schema will change but aligned to OQ-Q113-B dedicated pattern doc.
op_id propagation pattern	TBD-OTHER	—	OQ-Q24-C: likely trigger-driven, but Liam needs to understand implications. Working default: “app-stamped where rollback-op cohesion matters”.

2.2 — Finding 02 (Q&A write-back + citations + matches) — Wave 1B-2

Item	Liam disposition	Routing	Notes
§3.3 Recommendation: promote markdown sidecar emit to v1 (Q2.9 + Q3.2)	DECIDED	—	Agreed in principle. Gates remain: I3 (S9 spike status confirmation) — handled in §3 of this doc.
1000-Q&A-pairs scaling question	DEFER-COCOINDEX	Cocoindex	”Does one-file-per-pair .md approach still make sense at scale?” Cocoindex incremental processing + lineage will answer this.
Q1.11 citations rename + extend in place	DECIDED (with caveat)	—	Agreed with rename + extend in place. Rework approach depends on ontology (citations as ontology relations vs flat FK columns).
Q1.12 bid_question_matches → question_matches?	DEFER-ONTOLOGY	Ontology	Form-agnostic generalisation. Would content_item_id be on it if form-type is only matching Q&A pairs? Or per-form-type tables (bid_question_matches, rfp_question_matches)? Aligned to Theme A (form-type generalisation).
OQ-Q29-A S9 idempotency confirmation	DEFER-COCOINDEX	Cocoindex	Verify as part of cocoindex deep-dive — equal-hash idempotency behaviour.
OQ-Q32-A (predetermined-markdown shape variation by source)	DEFER-ONTOLOGY	Ontology	Likely doesn’t vary, but TBD ontology mapping.
OQ-Q111-A (future citers — competitor_research, sales_proposals, training)	DEFER-ONTOLOGY	Ontology	Any form-type activities. Less likely for competitor research, training. Ontology defines citer space.
OQ-Q112-A (per-method weighting embedding vs fulltext)	DEFER-COCOINDEX	Cocoindex	Investigate as part of cocoindex deep-dive — cocoindex scoring affordances.
OQ-Q112-B (single hybrid score vs separate columns)	TBD-OTHER	—	Check what’s in place already; use per-method columns if not.

2.3 — Finding 03 (Workspace types + project_id rename + templates + mempalace) — Wave 1B-5

Item	Liam disposition	Routing	Notes
Q1.13 Shape B retention (workspaces table + type discriminator + per-type satellites)	DEFER-ONTOLOGY	Ontology	Defer all workspace-type decisions to ontology — applications layer (Theme E) may rebound on this. Whether Shape B stays as currently shaped depends on what application layer reveals.
Q3.11 templates rename + form_templates with form_type	DEFER-ONTOLOGY	Ontology	Form_templates + form_template_fields with form_type + versions + metadata cols may make sense (aligns with OQ-Q113-C). Theme A again.
Q4.5 Mempalace wing → KH workspace_id	TBD-OTHER	MCP review	Need to determine: mempalace MCP direct OR wrap in KH MCP tooling. (Theme F.)
OQ-Q113-A (per-type satellite registry pattern)	TBD-OTHER	—	TBD. Liam to revisit post-ontology.
OQ-Q55-A (combined-PR for renames + schema-restructure)	DECIDED	—	Agreed combined. Use ccc to understand blast radius, then ts-morph + ast-grep.
OQ-Q311-A (form_templates pre-build)	DEFER-ONTOLOGY	Ontology	Gated on Wave 1B-3 (Q3.5 + Q3.10 + OQ11) — see Finding 04 section + Theme A/B.
OQ-Q45-A (mempalace wing-filter bug)	DECIDED (non-issue for KH)	—	Dev-workflow only — covered by production-readiness track.
OQ-Q113-B (RLS pattern for new tables)	DECIDED	—	Agreed dedicated pattern doc + Supabase have a “auto-enable RLS for new tables” DB trigger — Liam has example SQL if approach makes sense to implement.
OQ-Q113-C (bid_question_matches → question_matches with question_kind)	DECIDED (in principle)	—	Agreed approach. Final shape per Theme A.

2.4 — Finding 04 (Historical extraction + coverage) — Wave 1B-3

Item	Liam disposition	Routing	Notes
Q3.5 forward path for forms (Shape F: XLSX/PDF)	DEFER-BOTH	Both	Cover ALL document types (docx/xlsx/pdf/html). Use Theme B 6-step flow. Theme A generalisation applies.
template_requirements rename/refactor	DEFER-ONTOLOGY	Ontology	Likely renamed — Theme A.
Q3.10 coverage current scope	DEFER-BOTH	Both	Impacted by cocoindex (freshness — Theme D) + ontology (what does coverage cover when content isn’t Q&A?).
OQ-Q35-A (file-only v1 vs intermediate JSON cache)	DECIDED (v1 file-only)	—	File-only for v1 unless we adopt new extraction/conversion/classification flow for Phew content (which we likely should — see Theme B).
OQ-Q35-B (cataloguer skill output shape)	DEFER-BOTH	Both	TBD as part of extraction/conversion/classification flow (Theme B).
OQ-Q35-C (form requirement_type=‘checklist’ new enum)	DEFER-ONTOLOGY	Ontology	ENUM config to be reviewed/determined as part of ontology research.
OQ-Q310-A (Phase 4 bid-deadline scoring formula)	DECIDED	—	Agreed deferral to first live bid workspace.
OQ-Q310-B (low-match-score auto-gap vs draft-quality)	DECIDED (in principle)	—	Schema will change but agreed in principle: gap on low-match-score (question = coverage gap); additionally gap on draft-quality-below-threshold once drafting fires. Two signals. Final shape aligned to OQ-Q113-B.
OQ-Q310-C (audit table RLS)	DECIDED	—	Schema will change but aligned to OQ-Q113-B dedicated pattern doc.
OQ-Q11-A (form-question-extraction strategy)	DEFER-BOTH	Both	Part of Theme B form pipeline.

2.5 — Finding 05 (Bid response feedback loop) — Wave 1B-4

Item	Liam disposition	Routing	Notes
ALL Finding 05 decisions	DEFER-ONTOLOGY	Ontology	”Await outcomes from ontology, then re-evaluate and update.” This file will also be useful for determining form-type schema (Theme A).

2.6 — Finding 06 (Source-doc explorer CX.33) — Wave 1B-C

Item	Liam disposition	Routing	Notes
Per-MIME viewer composed from in-stack primitives	DEFER-COCOINDEX	Cocoindex	Need to review cocoindex capabilities/example projects to confirm.
DOCX flow rewrite	DEFER-COCOINDEX	Cocoindex	If markdown sidecar is v1, DOCX becomes: Markdown → Tiptap (existing ContentEditor) (was: DOCX → mammoth.convertToHtml + Turndown → mount in Tiptap; edit-back via Tiptap getMarkdown() → optional server-side DOCX regen).
PDF flow rewrite	DEFER-COCOINDEX	Cocoindex	PDF flow becomes: see cocoindex pdf-to-markdown example. (Was: PdfViewer / PdfReaderView read-only.)
XLSX flow	DEFER-COCOINDEX	Cocoindex	Check as part of cocoindex example review. And/or handle via structured form UI per 09 §1 Q3.5 (Theme B).
§5.5 cocoindex re-flow question	DEFER-COCOINDEX	Cocoindex	”Does cocoindex re-extract on user-initiated edit-back?” Proposed flow: binary (localfs) → convert all types to markdown (localfs sidecar) → UI edits update the localfs markdown sidecar. Theme C state-machine + RBAC.
File/folder directory explorer UI	DECIDED	—	Use magicui.design/docs/components/file-tree.
OQ-CX33-A (cocoindex re-extract on edit-back)	DEFER-COCOINDEX	Cocoindex	Theme C + Theme D.
OQ-CX33-B (DOCX write-back canonical)	DECIDED (per Finding 02 B1)	—	Aligned to sidecar reopen per Finding 02 (S233 synthesis B1).
OQ-CX33-C (workspace_id-scoped access)	DECIDED	—	Confirm with role-matrix walkthrough.
OQ-CX33-D (interim CTA on XLSX)	DECIDED	—	Agreed interim CTA.
OQ-CX33-E (Source_documents Option β fallback query)	DECIDED (per Finding 01 B2)	—	Aligned to Option α/β decision per Finding 01 (S233 synthesis B2).
OQ-CX33-F (docx-preview add-or-defer)	DECIDED	—	Product Owner to review quality after v1 implementation.
OQ-CX33-G (PDF read-only future)	DECIDED (likely non-issue)	—	May be non-issue if edit-view is from markdown sidecar in v1.

---

§3 — Prereq input matrix (clean tabular routing)

For the prereq sub-agents: this matrix lists every open item and which prereq closes it. Items marked DECIDED in §2 are omitted.

3.1 — Ontology pipeline prereq inputs

Open item	Source (Finding §)	What the ontology answer enables
Applications layer above workspaces	Theme E	Re-evaluates Q1.13 Shape B + per-type satellites
form / form-type / form-format / question / answer / response entity definitions	Theme A	Q&A pairs form-agnostic decision; bid_question_matches → question_matches discriminator
source_documents vs cocoindex source-key as binary identity carrier (Option α/β)	Finding 01 R2 + B2	Closes B2 in 00-synthesis
content_items vs q_a_pairs boundary when application isn’t Q&A-based	Theme E	Determines source_documents/content_items shape
product-guide as application vs content type	Theme E	Determines Phew use case shape
Citer space for citations (competitor_research, sales_proposals, training)	OQ-Q111-A	citations.citer_kind enum
template_requirements rename target	Finding 04 + Theme A	Schema-restructure PR scope
Form requirement_type checklist enum vs declaration/evidence merge	OQ-Q35-C	template/form schema
All Finding 05 schema implications (bid_workspaces, prior_bid context, outcome integrate)	Finding 05	Closes I1 in 00-synthesis
Per-type satellite registry pattern	OQ-Q113-A	workspace-types shape
edit_intent typed concept for re-classification triggers	Theme C	State-machine integration

3.2 — Cocoindex deep-dive prereq inputs

Open item	Source (Finding §)	What the cocoindex answer enables
Binary-shape adapter coverage (upload-route + downstream of source-documents API)	OQ-Q19-B/C/D + Finding 01 R3-R4	Closes Option α/β cascade
Markdown sidecar 1000-pair scaling	Finding 02	Sidecar v1 confirmation at scale
Equal-hash idempotency (S9 spike status)	OQ-Q29-A + I3 in 00-synthesis	Closes I3
Per-method scoring (embedding vs fulltext)	OQ-Q112-A	bid_question_matches.score shape
Form extraction pipeline coverage (steps 1/3/4 of Theme B)	Finding 04 + Theme B	XLSX/PDF/DOCX/HTML extraction path
PDF→Markdown example vs skill-seekers	Finding 06 + Theme G	PDF flow under markdown sidecar v1
Structured Extraction capability	Theme B step 3	Determines markdown conversion approach
Entity Resolution capability	Cocoindex examples	Determines entity dedup approach (Q&A pair dedup, content dedup)
Files Transform example	Cocoindex examples	Determines reusable converter pattern
Postgres Source example	Cocoindex examples	KH↔cocoindex source-side patterns
Meeting Notes Graph Neo4j example	Cocoindex examples	Graph-substrate pattern (CX.32 Knowledge Map surface scope)
CocoInsight (lineage + observability)	Theme D	Coverage + governance + change-reports integration
Persistent Pipeline (catalog, version tracking, continuous learning, metrics, scheduling, failure mgmt)	Theme D	pipeline_runs retain-vs-retire (OQ-Q24-A); coverage cadence
Freshness concept integration	Theme D	Coverage scope (Q3.10); change-reports model
Re-extract on edit-back behaviour	OQ-CX33-A + Theme C	UI state-machine + cost/perf trade-off

3.3 — Out-of-prereq-scope items (Liam-only or operational)

Open item	Source	Disposition
op_id propagation pattern (trigger vs app-stamped)	OQ-Q24-C	Liam to rule — working default per Finding 01
audit_log RLS pattern	OQ-Q24-B + OQ-Q113-B	Aligned to dedicated RLS pattern doc — Liam has Supabase trigger SQL
Mempalace direct vs wrapped in KH MCP	Theme F + Q4.5	MCP-action review pass (§11.1 0.9-synthesis)
Combined naming-cleanup PR scope	OQ-Q55-A	DECIDED combined

---

§4 — Liam’s original free-form notes (preserved verbatim)

The below is Liam’s initial review notes. Preserved to capture nuance not fully transferred to the tables above. Where §2 disposition tables cite this section, refer back here for context.

4.1 — 01-source_documents Findings Feedback

This will of course be largely determined by the outcomes of both the onthology and cocoindex investigations.

OQ Responses:

• OQ-Q19-A - Defer to onthology research outcomes.
• OQ-Q19-B - Does any downstream consumer of app/api/source-documents/[id]/route.ts exist outside the diff UI? - Use cocoindex-code to confirm
• OQ-Q19-C - Upload route - confirm if cocoindex binary-shape adapter handles it; but verify against 0.9-spike-S2 localfs scope. Does this take account of files no longer being uploaded to the DB, localfs-only?
• OQ-Q19-D - Fix the app/api/upload/route.ts silent-fail (line 444-447) — TBD - dependent on OQ-Q19-C.
• OQ-Q19-E - Backfill strategy for 387 q_a_pair rows - Already determined, no backfill required.
• OQ-Q24-A - pipeline_runs retire-vs-keep decision - dermine after upcoming cocoindex investigation work.
• OQ-Q24-B - audit_log table workspace_id RLS - Schema will change, but aligned to ‘OQ-Q113-B - RLS pattern for new tables - agreed on dedicated pattern doc’
• OQ-Q24-C - Op_id propagation - likely trigger-driven, but need to understand what this means and the implications - “app-stamped where rollback-op cohesion matters”

4.2 — 02-QA Write-back Findings Feedback

• “3.3 Recommendation (Q2.9 + Q3.2)” - Agreed on “promoting markdown sidecar to v1 baseline”.

• What if there were 1,000 Q&A pairs - does the one file per .md approach still make sense?

• “Q1.11 citations rename + extend in place” - Agreed with rename + extend in place, but the rework approach will depend on findings from onthology research.

• “Q1.12 — bid_question_matches cache” - would this become question_matches? And would content_item_id need to be on it, if a form-type is only looking for a Q&A pair match?

  • Or would bid_question_matches, rfp_question_matches, {other-form-types)_question_matches make sense?
    • Again, deferred to onthology decision.

• OQ Responses:

• OQ-Q29-A - Verify as part of upcoming cocoindex investigation findings.

• OQ-Q32-A - Likely doesn’t vary, but TBD onthology research findings.

• OQ-Q111-A - Any form-type activities, but less likely for competitor research, training materials etc.

• OQ-Q112-A - TBD - investigate options as part of upcoming cocoindex investigation findings.

• OQ-Q112-B - Check what we already have in place already, and use per-method-columns if not already in use.

4.3 — 03-Workspace Types Findings Feedback

• “3. Q1.13 — Workspace types as separate domains”

  • Defer decisions to onthology research outcomes.

• “5. Q3.11 — Templates / forms schema”

  • In principle, form_templates + form_template_fields with form_type + versions and other metadata columns might make sense (aligns with OQ-Q113-C decision - bid_question_matches → question_matches?)
    • Defer to onthology research outcomes.

• “6. For Q4.5 — Mempalace wing → KH workspace_id”

  • Need to determine whether we are using mempalace MCP direct, or utilising MCP pattern with KH MCP tooling.

• OQ Responses:

  • OQ-Q113-A - TBD
  • OQ-Q55-A - Agreed, combined. Use cocoindex-code to understand blast-radius then use ts-morph + ast-grep.
  • OQ-Q311-A - Gated on Wave 1B-3 (Q3.5 + Q3.10 + OQ11) - See section 04.
  • OQ-Q45-A - Non-issue for KH platform - dev-workflow only (dev-workflow is being covered separately by the production-readiness track).
  • OQ-Q113-B - RLS pattern for new tables - agreed on dedicated pattern doc + Supabase have an ‘automatically enable RLS for newly created tables’ database trigger - Liam has the example SQL available if this approach makes sense to implement here too.
  • OQ-Q113-C - Agreed on approach in principle bid_question_matches → question_matches with question_kind discriminator - See section 04.

4.4 — 04-Extractions and Coverage Findings Feedback

Form extraction:

• The below points will further be informed by the upcoming cocoindex and onthology research and investigation work.
  • “Q3.5 forward path for forms (Shape F: XLSX/PDF)” - We should look to cover ALL document types e.g., docx, xlsx, pdf, html, at the extraction stage, potentially including a cataloguing skill + form evaluation skill (and potentially a markdown conversion skill).

    • Note that template_requirements is likely to be renamed or refactored.

    • The concept of generalising forms is also being evaluated - a form being a type (Bid, RFP, PQQ etc.), which will have metadata and questions that require extraction, and can then be matched to Q&A pairs.

    • Potential Flow - evaluate-form skill -> HITL verification -> convert form to Markdown -> AI-assisted cataloguing skill -> HITL verification -> cocoindex processing

      • Step 1 - evaluate-form skill (one per format type?) - used to evaluate form, and propose approach for converting to markdown. Anthropic already provides skills for working with .pdf, .docx, .xlsx, which would be the baseline. Our skill could expand on these, to cover our specific-requirements.
      • Step 2 - AI-assisted + human QA of conversion approach
      • Step 3 - Either markdown conversion skill, using ‘Structured Outputs’, or create a reusable converter in the cocoindex pipeline (base doc type + adaptations - can then be re-used in future for new or similar version of form)
      • Step 4 - classify-form-data - verify what was proposed in template-driven-completeness-spec.md - focuses on data, once form is converted to markdown.
      • Step 5 - AI-assisted + human QA of classification approach
      • Step 6 - moves through cocoindex pipeline
  • Evaluate scripts/extract_tender_questions.py and scripts/analyse_template.py for useful patterns for form-type evaluation/conversion/extraction.

Coverage:

• Will also be impacted by cocoindex and onthology research and investigation work, including wider approach to handling form-types (templates).
  • cocoindex also has a concept of ‘freshness’, so we need to understand how this should be integrated to KH.

OQ Responses:

• OQ-Q35-A - file-only for v1, unless we decide to use new extraction/conversion/classification flow for Phew’s content (which we likely should).
• OQ-Q35-B - TBD, as part of extraction/conversion/classification flow.
• OQ-Q35-C - ENUM config to be reviewed and determined as part of onthology research.
• OQ-Q310-A - Agreed
• OQ-Q310-B - Schema will be adjusted, but agreed in principle with “gap on low-match-score (the question itself is a gap-of-coverage), then additionally gap on draft-quality-below-threshold once drafting fires. Two distinct signals.”
• OQ-Q310-C - Schema will change, but aligned to ‘OQ-Q113-B - RLS pattern for new tables - agreed on dedicated pattern doc’
• OQ-Q11-A - As above, part of “potential” form extraction/conversion/classification flow.

4.5 — 05-Bid Response Feedback Loop Findings Feedback

• Await outcomes from onthology and then re-evaluate and update.
  • This file will also be useful for determining form-type schema.

4.6 — 06-Source Doc Findings Feedback

We need to review cocoindex capabilities/example projects

• If we agree on markdown sidecar, would that change the below to:

  • 1. DOCX - From: DOCX → mammoth.convertToHtml + Turndown → mount in Tiptap; edit-back via Tiptap getMarkdown() → optional server-side DOCX regen (see §6). - To: Markdown → Tiptap (existing ContentEditor)
  • 2. PDF - From: PdfViewer / PdfReaderView (read-only — PDF round-trip is out of scope - To: See example at https://cocoindex.io/docs/examples/pdf-to-markdown/
  • 3. XLSX - check as part of cocoindex capabilities/example projects review (and/or handle via structured form UI per 09 §1 Q3.5)
  • For “5.5 The cocoindex re-flow question” open question item: “does cocoindex re-extract on a user-initiated edit-back? Gates on Wave 1B-2’s resolution of the WP3 ledger query pattern (see 0.9-edit-flow-investigation.md §6.1 + Q3 / Q4 carry-forward).” - would that then make the suggested flow:
    • binary (localfs) -> convert all file types to markdown (localfs sidecar) -> any edits made via UI update the localfs markdown sidecar
    • We need to think about state-machine - (i) drafting more than one edit in a file, then action taken based on whether it’s saved to {draft/for review/approved} - taking into account RBAC. Confirm what we already have in place here, (ii) Re-classification process - triggered on ALL edit types? e.g., one word change? what if it’s a key date? Allow user to decide, for example, presenting options in the UI? (iii) Plus “Concurrent-edit handling”.

• For file/folder directory explorer UI component, we should use: “https://magicui.design/docs/components/file-tree”

• OQ Responses:

  • OQ-CX33-A - As per N6, + see 06 user feedback section.
  • OQ-CX33-B - As per B1 (00-synthesis.md).
  • OQ-CX33-C - Confirm with role-matrix walkthrough.
  • OQ-CX33-D - Agreed on interim CTA.
  • OQ-CX33-E - As per B2 (00-synthesis.md).
  • OQ-CX33-F - Product Owner to review quality after v1 implementation.
  • OQ-CX33-G - May be non-issue if edit-view is from markdown sidecar in v1.

---

§5 — Post-prereq resolution rollup (S234 Phase 2)

Appended 13/05/2026 after Prereq 1 (Ontology Pipeline) + Prereq 2 (Cocoindex deep-dive) landed. For every open item in §2 + §3, this section records: RESOLVED / RESOLVED-DIRECTIONAL / STILL-OPEN + which prereq section closes it.

Legend:

• RESOLVED = closure direction final; can propagate to decision-graph + collapse-candidates.
• RESOLVED-DIRECTIONAL = closure direction recommended but contingent on a noted prerequisite (e.g. Docling fidelity spike, Liam ratification).
• STILL-OPEN = prereqs did not close; routes to spike, future session, or operational decision.

5.1 — Cross-cutting theme resolutions

Theme	Status	Closed by	Notes
A — Form-type generalisation	RE-RESOLVED-S235: procurement umbrella + form_type discriminator	Prereq 1 §4.5 (rewritten S235) + Prereq 2 §1.2 + WP-ONTO-R1 §3 + Q-OQR1-02 ratification	Two Layer-1 CVs (form_type + form_format) + Layer-5 form_templates + form_template_fields + form_template_requirements. templates renames to form_templates (NOT bid_templates). Generalised question_matches with question_kind discriminator (aligned with form_types). S235 rename per Q-OQR1-02: application_type='bid' → application_type='procurement' umbrella; form_type discriminators within: bid / rfp / pqq / itt / framework / dps / gcloud. BID_STATES → PROCUREMENT_WORKFLOW_STATES; lib/bid/bid-state-machine.ts → lib/procurement/procurement-workflow.ts; bid_workspaces → procurement_workspaces. Combined PR per Q-OQR1-16. bid_questions + bid_responses keep names (the question/response is to a procurement form regardless of form_type).
B — Form extraction pipeline (6-step)	RESOLVED-DIRECTIONAL	Prereq 2 §1.2 + Prereq 2c	Step 1 (evaluate-form): Anthropic doc skills (docx/xlsx/pdf). Step 3 (markdown convert): reusable cocoindex pipeline converter with format-specific @coco.fn per MIME — gates on Docling fidelity spike for Docling vs alternatives library choice. Step 4 (classify-form-data): cocoindex ExtractByLlm with typed Python output_type. Steps 2 + 5 (HITL): unchanged. Step 6 (cocoindex pipeline): cocoindex flow standard.
C — Edit / re-classification state-machine	RESOLVED-DIRECTIONAL	Prereq 1 §5 + Prereq 2 §1.2	Add edit_intent Layer-1 CV (cosmetic / data / structural) on content_history.edit_intent. Cocoindex re-extract naturally on source-binding change, gated by KH-side: edit_intent ∈ {data, structural} triggers re-classification; cosmetic skips. Concurrent-edit handling defers to operational design. RBAC: existing workspace-scoped checks apply.
D — Cocoindex ‘freshness’ integration	RESOLVED — separate substrates	Prereq 2 §1.1 + §1.2	Cocoindex’s freshness = ingest-latency metric (operational). KH’s content_items.freshness enum = governance freshness (fresh/aging/stale/expired). Both retained. No merge. Documented in WP4 02-data-flow.md.
E — Applications layer above workspaces	RE-RESOLVED-S235: Option (c) hybrid with provenance (was: RESOLVED-S234 Option (a) vocab-only)	Prereq 1 §4.2 (rewritten S235) + Prereq 1 §4.3 + WP-ONTO-R1 §2 + Q-OQR1-01/03/11/13 ratifications 14/05/2026	Add application_types instance table (NOT vocab-only) with rich config columns (label, route_path, default_color, default_icon, default_template_ids[], state_machine_name, state_machine_config) + provenance enum (core / client / recommended) mirroring taxonomy_domains.provenance precedent. 6 baseline core rows ship (Q-OQR1-03): procurement (replaces bid per Q-OQR1-02 rename), intelligence, sales_proposal, product_guide, competitor_research, training_onboarding. workspaces.application_type_id FK replaces workspaces.type text column. Per-application_type satellites (procurement_workspaces, future sales_proposal_workspaces, …) follow Finding 05 Option B pattern. product_guide is BOTH content (content_type=‘guide’) AND application (application_type=‘product_guide’) — orthogonal axes. Admin UI for client-managed types lands v1.1 per Q-OQR1-13 via existing settings-page pattern (taxonomy/tags/guides/layers/entities/governance sections precedent).
F — Mempalace MCP integration pattern	STILL-OPEN	—	Outside prereq scope. Operational decision: mempalace MCP direct vs wrapped in KH MCP tooling. Lands in WP4 06-mcp-tooling.md. Liam ruling required.
G — Doc skills evaluation	RESOLVED	Prereq 2c §2	Anthropic doc skills (docx/xlsx/pdf) win step 1 (evaluate-form) — clear winner. Markdown-converter (markitdown-backed) is fallback for step 3 if Docling fails fidelity spike. PDF/DOCX/XLSX form pipeline routes through Anthropic skills for evaluation, cocoindex for conversion + extraction.

5.2 — Per-finding disposition refresh

Only items that were non-DECIDED in §2 (i.e. DEFER-* or TBD-OTHER) are listed; DECIDED items stay decided.

5.2.1 — Finding 01 (source_documents + audit trail)

Item	§2 disposition	Post-prereq disposition	Closed by
Recommendation 2 (slim source_documents — Option α)	DEFER-ONTOLOGY	RESOLVED-DIRECTIONAL: Option α (slim-and-keep)	Prereq 1 §5 + Prereq 2 §1.2
Recommendation 3 (diff UI fate)	DEFER-COCOINDEX	RESOLVED — diff UI retires under Option α (source_document_diffs table absorbed by cocoindex ops-DB ledger; UI no longer needed)	Prereq 2 §1.2 retire-seed
Recommendation 4 (upload-route handles binary-only)	DEFER-COCOINDEX	RESOLVED — upload-route stays for HITL manual uploads under Option α; cocoindex localfs adapter handles automated ingest	Prereq 2 §1.1 + §2 OQ-Q19-B/C/D resolution
OQ-Q19-D upload-route silent-fail fix	DEFER-COCOINDEX	RESOLVED — fix proceeds under Option α (Finding 01 N5 unblocked)	Prereq 2 §1.3 N5
OQ-Q24-A pipeline_runs retain-vs-retire	DEFER-COCOINDEX	RESOLVED — RETAIN as KH-side rollup (cocoindex has no TS-facing per-flow-run ledger API)	Prereq 2 §1.2
OQ-Q24-B audit_log RLS pattern	TBD-OTHER (RLS pattern doc)	RESOLVED-S236 — Adopt Supabase rls_auto_enable() event trigger platform-wide (per supabase-db-action-items.md Item 2). Lands in dedicated RLS pattern doc + new migration paired with §3.17 grants helper. Closes OQ-Q24-B + OQ-Q113-B together. Superseded — see 00-synthesis-v2.md §3.16 + §5.1 + decision-graph §11.4.1 + this doc §6.4 for the audit-trail.	RESOLVED-S236
OQ-Q24-C op_id propagation pattern	TBD-OTHER	RESOLVED-S236 — Cocoindex + industry best practice; trigger-driven for platform-wide audit cohesion + cocoindex per-flow op_id for pipeline-side correlation. Lands in WP4 02-data-flow.md. Superseded — see 00-synthesis-v2.md §3 N7 + §5.1 + decision-graph §11.4.1 + this doc §6.4 for the audit-trail.	RESOLVED-S236
pipeline_failures table (planned in Finding 01 context)	(not in §2)	RESOLVED — DO NOT BUILD. Cocoindex retry/back-off/DLQ subsumes per Prereq 2 §1.2. KH’s recordPipelineRun() helper handles the rollup.	Prereq 2 §1.2
Q4.12 cost-tracking pattern (skill-seekers-style dashboards)	(not in §2)	RESOLVED — RETIRE. Cocoindex memoisation + per-stage metrics supersede per Prereq 2 §1.2.	Prereq 2 §1.2

5.2.2 — Finding 02 (Q&A write-back + citations + matches)

Item	§2 disposition	Post-prereq disposition	Closed by
§3.3 Recommendation: promote sidecar to v1	DECIDED (with caveat — gates on I3)	RESOLVED-DIRECTIONAL — sidecar v1 confirmed pending S9 spike completion (still STILL-OPEN per Prereq 2 §3.6)	Prereq 2 §2
1000-Q&A-pair scaling	DEFER-COCOINDEX	RESOLVED — files_transform + incremental processing handles arbitrary scale	Prereq 2 §2
Q1.11 citations rename + extend in place	DECIDED (with caveat — ontology rework)	RESOLVED — polymorphic citing_entity (bid_response / sales_proposal_response / competitor_research_finding / training_unit / mcp_search_response per Prereq 1 §5)	Prereq 1 §4.4
Q1.12 bid_question_matches → question_matches	DEFER-ONTOLOGY	RESOLVED — generalised question_matches with question_kind discriminator aligned with form_types vocab (bid/rfp/pqq/itt/framework/dps/gcloud per Q-OQR1-02 procurement umbrella)	Prereq 1 §4.4 (S235 rewrite)
q_a_pair ↔ workspace cardinality (S235 new row)	n/a (was open)	RE-RESOLVED-S235: corpus-level + scope_tag-driven (NO direct workspace FK; nullable source_workspace_id for provenance audit per Q-OQR1-07). Supersedes both 0.9-intended-architecture.md §4.3 N:1 sketch AND prior Prereq 1 §4.4 M:N junction recommendation. Empirical foundation: 0/395 prod q_a_pair rows workspace-assigned.	Prereq 1 §4.4 (S235 rewrite) + WP-ONTO-R1 §4 + Q-OQR1-06 ratification 14/05/2026
Workspace-private q_a_pairs (S235 new row)	n/a (was open)	RESOLVED-S235: defer to v1.1 per Q-OQR1-08. No private_to_workspace_id column in v1; single Phew tenant means privacy distinction not load-bearing.	Q-OQR1-08 ratification 14/05/2026
OQ-Q29-A S9 idempotency	DEFER-COCOINDEX	STILL-OPEN — spike pending	Prereq 2 §3.6
OQ-Q32-A (predetermined-markdown shape variation)	DEFER-ONTOLOGY	RESOLVED — does NOT vary (single canonical YAML-frontmatter shape per Prereq 1 §2.1 OQ10 carry-forward)	Prereq 1 §2.1
OQ-Q111-A future citers	DEFER-ONTOLOGY	RESOLVED — citing_entity enum extended per Prereq 1 §5 (bid_response, sales_proposal_response, competitor_research_finding, training_unit, mcp_search_response)	Prereq 1 §5
OQ-Q112-A per-method weighting	DEFER-COCOINDEX	STILL-OPEN — cocoindex doesn’t prescribe scoring; separate columns recommendation stays	Prereq 2 §2
OQ-Q112-B single hybrid vs separate columns	TBD-OTHER (check existing)	STILL-OPEN — same as OQ-Q112-A	Operational verification

5.2.3 — Finding 03 (Workspace types + project_id + templates + mempalace)

Item	§2 disposition	Post-prereq disposition	Closed by
Q1.13 Shape B retention	DEFER-ONTOLOGY (applications layer may rebound)	RE-RESOLVED-S235 — Shape B holds with application_type_id FK to application_types instance table (Option (c) hybrid + provenance per Q-OQR1-01). workspaces.type text column retires; 6 baseline core application_types ship (Q-OQR1-03: procurement/intelligence/sales_proposal/product_guide/competitor_research/training_onboarding).	Prereq 1 §4.2 (S235 rewrite) + WP-ONTO-R1 §2
Q3.11 templates rename	DEFER-ONTOLOGY (form_templates per Theme A)	RESOLVED — templates → form_templates (NOT bid_templates); template_fields → form_template_fields; template_requirements → form_template_requirements	Prereq 1 §4.5
Q4.5 Mempalace wing → KH workspace_id	TBD-OTHER (MCP review)	STILL-OPEN — Theme F per §5.1	MCP-action review pass
OQ-Q113-A per-type satellite registry	TBD-OTHER	RESOLVED — satellite per application_type vocabulary entry	Prereq 1 §5
OQ-Q311-A form_templates pre-build	DEFER-ONTOLOGY	RESOLVED — build form_templates as part of Theme A delivery (form_type + form_format as Layer-1 CVs); cataloguer skill build-trigger STILL-OPEN pending Docling spike	Prereq 1 §4.5 + Prereq 2 N2

5.2.4 — Finding 04 (Historical extraction + coverage)

Item	§2 disposition	Post-prereq disposition	Closed by
Q3.5 forward path for forms	DEFER-BOTH	RESOLVED-DIRECTIONAL — Theme B 6-step flow with Anthropic doc skills + cocoindex pipeline + ExtractByLlm	Prereq 1 §4.5 + Prereq 2 §1.2
template_requirements rename	DEFER-ONTOLOGY	RESOLVED — form_template_requirements (closes I2 in 00-synthesis with 3-table inventory)	Prereq 1 §4.5
Q3.10 coverage current scope	DEFER-BOTH	RESOLVED — extend, not rebuild; 4th gap source aligned with bid_response or bid_question_match (N4 cosmetic, Liam preference)	Prereq 1 + Prereq 2 (no substrate change required)
OQ-Q35-B cataloguer skill output shape	DEFER-BOTH	RESOLVED — generated scripts/catalogue-<slug>.ts seed-script-and-commit	Prereq 2 §2 Rec 5
OQ-Q35-C form requirement_type=checklist enum	DEFER-ONTOLOGY	RESOLVED — NO, fold into existing declaration / evidence. Checklist is a form_FORMAT not requirement_TYPE.	Prereq 1 §5
OQ-Q11-A form-question-extraction strategy	DEFER-BOTH	RESOLVED — cocoindex ExtractByLlm (subsumes per Prereq 2 §1.2 + Rec 1)	Prereq 2 Rec 1

5.2.5 — Finding 05 (Bid response feedback loop)

Item	§2 disposition	Post-prereq disposition	Closed by
ALL Finding 05 decisions	DEFER-ONTOLOGY	RESOLVED-DIRECTIONAL via I1 closure — bid_workspaces Option B (satellite) is the Shape B precedent. Per-application_type satellites follow same pattern (proposal_workspaces, etc.). Prior-bid ingest gets q_a_extractions.extractor_kind='prior_bid_response' + 4 typed columns. Outcome /integrate extended to lost+won.	Prereq 1 §4.2 + §5

5.2.6 — Finding 06 (Source-doc explorer CX.33)

Item	§2 disposition	Post-prereq disposition	Closed by
Per-MIME viewer composition	DEFER-COCOINDEX	RESOLVED-DIRECTIONAL — sidecar-v1 architecture (markdown → Tiptap ContentEditor). PDF flow + DOCX flow gates on Docling spike.	Prereq 2 §2
DOCX flow rewrite	DEFER-COCOINDEX	RESOLVED-DIRECTIONAL — Markdown → Tiptap (existing ContentEditor) per Liam direction; conversion library gates on Docling fidelity spike (mammoth+Turndown alternative if Docling fails on track-changes)	Prereq 2 §3.1
PDF flow rewrite	DEFER-COCOINDEX	RESOLVED-DIRECTIONAL — cocoindex pdf_to_markdown (Docling-backed) for sidecar conversion; existing PdfReaderView for read-only view. Gates on Docling spike.	Prereq 2 §3.1 + Liam direction
XLSX flow	DEFER-COCOINDEX	RESOLVED — cocoindex converter (pandas-backed via cocoindex pipeline) + structured form UI per Q3.5 Theme B	Prereq 2c §2 + Prereq 1 §4.5
§5.5 cocoindex re-flow question	DEFER-COCOINDEX	RESOLVED — cocoindex re-extracts naturally on source-binding change; KH-side gate via edit_intent per Theme C	Prereq 2 §1.2
Finding 06 “zero new deps for v1” claim	(not in §2; new)	REOPENED — if Docling adopted, the claim becomes obsolete. Spike + Liam license check required.	Prereq 2 §3.1

5.3 — Prereq input matrix closure (from §3)

5.3.1 — Ontology pipeline inputs (§3.1)

All 11 items in §3.1 closed by Prereq 1. Summary:

Open item (§3.1)	Status	Prereq 1 closure point
Applications layer above workspaces	RE-RESOLVED-S235: Option (c) hybrid + provenance (was: Option (a) vocab-only S234)	§4.2 (S235 rewrite)
form / form-type / form-format / question / answer / response entity definitions	RESOLVED — refined S235: procurement umbrella + form_type discriminator	§4.5 (S235 rewrite)
source_documents vs cocoindex source-key (Option α/β)	RESOLVED-DIRECTIONAL: α + S235 refinement: nullable source_documents.workspace_id per Q-OQR1-09	§5 + §5.7 (new S235)
content_items vs q_a_pairs boundary	RESOLVED — peer classes + S235 refinement: q_a_pairs corpus-level, scope_tag-driven per Q-OQR1-06	§3.5 + §4.4 (S235 rewrite)
product-guide as application vs content	RESOLVED — both + ships as core baseline application_type per Q-OQR1-03	§4.3
Citer space for citations	RESOLVED	§5
template_requirements rename target	RESOLVED — form_template_requirements	§4.5
Form requirement_type='checklist' enum	RESOLVED — NO	§5
Finding 05 schema implications	RESOLVED-DIRECTIONAL — Option B; bid_workspaces renamed procurement_workspaces S235	§5
Per-type satellite registry pattern	RESOLVED — per application_type vocab entry	§5
edit_intent typed concept	RESOLVED-DIRECTIONAL	§5
Provenance pattern adoption (S235 new row)	RESOLVED-S235: adopt across all hybrid vocabs per Q-OQR1-11	§5 (S235 row)
Procurement rename (S235 new row)	RESOLVED-S235: rename bid → procurement pre-launch in combined PR per Q-OQR1-02 + Q-OQR1-16	§4.5 + §6 Phase 1 (S235 rewrite)

5.3.2 — Cocoindex deep-dive inputs (§3.2)

Of 15 items in §3.2, 11 RESOLVED, 4 STILL-OPEN:

Open item (§3.2)	Status	Prereq 2 closure point
Binary-shape adapter coverage	RESOLVED	§1.1 + §2
Markdown sidecar 1000-pair scaling	RESOLVED	§2
Equal-hash idempotency (S9 spike)	STILL-OPEN	§3.6
Per-method scoring (embedding vs fulltext)	STILL-OPEN	§2
Form extraction pipeline (Theme B)	RESOLVED-DIRECTIONAL	§1.2
PDF→Markdown vs skill-seekers	STILL-OPEN (Docling spike) → in-flight S234 (Docling vs markitdown bake-off)	§3.1
Structured Extraction capability	RESOLVED	§1.1 + Rec 1
Entity Resolution capability	RESOLVED — selective adoption	Rec 3
Files Transform example	RESOLVED — adopt	§1.1
Postgres Source example	RESOLVED — already in plan	§1.1
Meeting Notes Graph Neo4j example	RESOLVED-DIRECTIONAL — person-dedup adopted; substrate defers to S7	§1.1
CocoInsight	RESOLVED — separate concern from audit_log	§1.2 + §3.3
Persistent Pipeline	RESOLVED — inherit; pipeline_failures DO NOT BUILD	§1.2
Freshness	RESOLVED — separate substrates	§1.2
Re-extract on edit-back	RESOLVED — natural	§1.2

5.3.3 — Out-of-prereq items (§3.3)

Item	Status	Notes
op_id propagation pattern	STILL-OPEN	Liam ruling — orthogonal to prereqs
audit_log RLS pattern	STILL-OPEN	RLS pattern doc pending — orthogonal to prereqs
Mempalace direct vs wrapped (Theme F)	STILL-OPEN	MCP-action review pass — orthogonal to prereqs
Combined naming-cleanup PR scope	DECIDED	Already in §3.3 — combined per OQ-Q55-A

5.4 — Still-open items + scheduling

NB (S234 end-of-session): This table was written pre-Docling-spike. §5.5 (Docling spike resolution) supersedes items marked “IN-FLIGHT S234” and adds three new partial-failure-surface items + Cloud Run sidecar architecture as a new HIGH-priority blocker. Treat §5.5 as authoritative for Docling-spike-gated items.

Items requiring further work after this session:

Item	Status	Closes via	Priority	Scheduled
Docling fidelity spike	STILL-OPEN — IN-FLIGHT S234	2d sub-agent in background	HIGH	This session if sub-agent completes
Docling license check	STILL-OPEN	Liam ratification	HIGH	After 2d sub-agent report
HTML consolidation (Docling vs pullmd)	STILL-OPEN	2d sub-agent + Liam ruling	MEDIUM	This session
S9 spike (cocoindex equal-hash idempotency)	STILL-OPEN	Empirical spike	HIGH	Defer to dedicated sub-session
op_id propagation pattern	STILL-OPEN	Liam ruling	MEDIUM	Operational; bound to WP4 02-data-flow
audit_log RLS pattern	STILL-OPEN	RLS pattern doc	MEDIUM	OQ-Q113-B follow-up
MCP-action review pass (Theme F)	STILL-OPEN	MCP-action review	MEDIUM	Independent gate from prereqs; WP4 06-mcp-tooling
Per-method scoring (OQ-Q112-A/B)	STILL-OPEN	Operational verification	LOW	Pre-launch QA
Knowledge Map graph substrate	STILL-OPEN	Future S7 spike	DEFERRED	Post-WP4
TS-facing API for cocoindex per-flow-run ledger	STILL-OPEN	Source-code read	LOW	Pre-launch documentation
CocoInsight on-prem deployment	STILL-OPEN	Docs/source read	LOW	Only if KH self-hosts
Anthropic prompt-cache passthrough verification	STILL-OPEN	Empirical verification	MEDIUM	Pre-launch cost projection
Discriminated-union Pydantic with ExtractByLlm	STILL-OPEN	Empirical (Q-EX2)	MEDIUM	Pre-launch schema design
XLSX structure-preserving conversion (Docling may flatten tables)	STILL-OPEN	Spike (Q-XL1)	MEDIUM	Folded into 2d sub-agent if scope permits

5.5 — Docling spike resolution (closed S234 end-of-session)

Docling bake-off completed (phase-b-prerequisite-2d-docling-bakeoff.md, 387-line empirical report, 88% confidence). Closes the spike that §5.4 had listed as IN-FLIGHT. Updates the dispositions below:

Per-format recommendation (final):

Format	Recommended tool	Status	Notes
PDF	Docling	RESOLVED — decisive win	75 headings + 299 GFM table rows vs markitdown’s 0 + 0. Q-number↔question-text association intact (critical for SSQ extraction).
DOCX	Docling (conditional)	RESOLVED-CONDITIONAL	Narrow win on heading-level fidelity (H1-H4 vs H1-H3); table fidelity tied with markitdown + KH’s existing mammoth+Turndown. Consolidate IFF PDF goes Docling.
XLSX	Docling	RESOLVED (post-S235 §9)	Clean GFM output without NaN/Unnamed: placeholder pollution; merged-cell headers handled correctly. URL-drop caveat verified in S235 WP-DOCLING-XLSX (phase-b-prerequisite-2d-docling-bakeoff.md §9): at full-corpus scale on the Cloud Security Principles checklist Docling and markitdown have identical URL recall (14/15 unique URLs, 93.33%; the single miss is a row-39 hyperlink-anchor quirk shared by both tools, not a Docling-only drop). The S234 §2.2 sample-time scoring (Docling 3/5 vs markitdown 5/5) is corrected to a tie at 5/5 in §9.4.
HTML	KEEP pullmd	RESOLVED — no consolidation	Docling matches pullmd’s static-HTML tier but cannot replace pullmd’s Playwright sidecar (JS-pages), Cloudflare short-circuit, Reddit comment-trees, or share-id stable identity contract. Consolidation costs JS-page coverage.
Markdown	(pass-through)	n/a	No converter needed.

License verdict: Docling = MIT, markitdown = MIT, pullmd = AGPL v3 (already tracked PM-Q2 per 0.8.4-pullmd-evaluation.md; this spike did not reopen). All three license-compatible for KH.

Dependency footprint (load-bearing for deployment architecture):

Tool	Disk	Models	GPU?	Vercel-fit (250 MB limit)	Cloud Run-fit
Docling	~1.8 GB (1.3 GB site-packages: torch 443 MB + transformers 101 MB + scipy 98 MB + pandas 71 MB; plus 506 MB HF model cache for layout-heron + docling-models)	layout-heron + docling-models, downloaded on first use	CPU-only viable (this spike ran on CPU; Apple Silicon MPS path not tested)	NO — cannot land in Vercel function bundle	YES — Cloud Run sidecar territory
markitdown	~150-200 MB	none	n/a	YES	YES
pullmd	(per 0.8.4 eval)	n/a	n/a	YES	YES

Architecture implication (NEW finding from spike): Docling’s 1.8 GB footprint cannot land in Vercel functions. The form-extraction pipeline must run as a Cloud Run sidecar (KH already runs Cloud Run for the Python pipeline per CLAUDE.md kh-prod-494815 / kh-staging-494815). Finding 06’s “zero new dependencies for v1” claim is OBSOLETE if Docling adopted. Updates needed to phase-b-prerequisite-2c-cocoindex-doc-handling.md + Finding 06 source-doc explorer doc.

Updates to Theme B step 3 (markdown convert) per spike result:

• PDF: Docling (replaces “Docling-vs-skill-seekers-pending” placeholder)
• DOCX: Docling conditional (alternative: mammoth+Turndown stays as fallback for tracked-changes DOCX edge case)
• XLSX: Docling (broader XLSX corpus verification CLOSED — S235 WP-DOCLING-XLSX phase-b-prerequisite-2d-docling-bakeoff.md §9 confirmed Docling = markitdown on URL recall at full-corpus scale; 95% confidence)
• HTML: pullmd retained

Partial-failure surfaces flagged for Phase B follow-up:

Surface	Severity	Recommendation
Docling XLSX drops NCSC URLs from some Principle rows where URL was sole cell content	CLOSED (S235 WP-DOCLING-XLSX §9)	Verified at full-corpus scale on the Cloud Security Principles checklist (14 URL-only cells, 100% Docling preservation, tied with markitdown). No Docling-specific drop. The S234 inference was wrong; corrected in §9.5 post-mortem. No further action; if a future XLSX fixture regresses, fall back to openpyxl sidecar pre-pass per §9.4.
markitdown 0.0.2 resolved on Python 3.14 (PyPI head is 0.1.5)	LOW	Re-run bake-off on KH’s target Python version (3.x — verify) before commit. Architectural verdict (markitdown lacks layout model for PDF + Readability for HTML) unchanged regardless of version.
Tracked-changes DOCX NOT tested	MEDIUM	Add tracked-changes DOCX to Theme B regression suite. KH has a python-docx Gotcha re Document(path) direct calls — same gotcha may apply to Docling/markitdown on tracked-changes input.

Disposition updates (replace §5.1 Theme B + §5.2.6 Finding 06 entries):

Theme / item	New disposition
Theme B (form extraction pipeline)	RESOLVED (was RESOLVED-DIRECTIONAL pending spike) — step 3 markdown convert: per-format recommendation table above. Cloud Run sidecar architecture required for Docling.
Finding 06 DOCX/PDF/XLSX viewer rewrite	RESOLVED — sidecar-v1 (markdown → Tiptap ContentEditor) with Docling-backed cocoindex pipeline producing the sidecar markdown. “Zero new deps for v1” claim OBSOLETE — Docling 1.8 GB. Cloud Run sidecar required.
N2 (cataloguer skill build-trigger)	RESOLVED — defer. Docling fidelity is high enough that a cataloguer skill isn’t needed pre-launch. Build-now flagged only if Docling fails on broader XLSX corpus verification.
Docling license check	RESOLVED — MIT, compatible. Liam approval check is administrative only.
HTML consolidation question	RESOLVED — no consolidation, keep pullmd.

---

---

§6 — S237 closures appended (Liam-pre-decision CVs + Astro+Starlight docs-site)

Appended 14/05/2026 (S237) after Liam pre-decided 7 outstanding CV items + ratified the docs-site framework. Items applied in commit 099eb5f6. These extend §5.2 per-finding disposition tables where the original deferred items now have a concrete S237 closure.

6.1 — CV-level closures (Liam pre-decided)

Item	Originating finding § (if any)	Post-S237 disposition	Source
CV 02 taxonomy-subtopics prose-vs-frontmatter count drift (33 vs 31)	(S236 WP6 finding)	RATIFIED-S237 — prose reconciled to 33 baseline values. Seed-file derivability deferred to Q-OQR1-16 combined PR.	docs/ontology/02-taxonomy-subtopics.md (S237)
CV 03 layer-vocabulary provenance column ALTER timing	(S236 WP6 finding)	RATIFIED-S237 — ALTER in Q-OQR1-16 combined PR.	docs/ontology/03-layer-vocabulary.md (S237)
CV 03 UI nesting spec (p0-layer-nesting-spec.md)	(S236 INV-1 hybrid 3-axis recommendation)	DEFERRED-S238+ — v1 keeps existing 4 live keys (sales_brief / bid_detail / company_reference / research); hybrid 3-axis architecture (layer + tabs + q_a_pairs+scope_tag) postponed.	docs/specs/wp6-ontology-harness/investigations/INV-1-layer-vocabulary.md deferred
CV 04 content-type — policy vs compliance semantic boundary	OQ-Q-CT-1 (S236 INV-2)	RATIFIED-S237 — author-vs-evidence rule (ISO management-system framing). policy = prescriptive statement; compliance = evidence of adherence to external regime. Lands via docs/reference/classification-prompt.md v4.8+ update; no schema change.	docs/ontology/04-content-type.md Notes block + INV-2
CV 04 content-type — methodology vs capability (retire capability candidate)	OQ-Q-CT-2 (S236 INV-2)	RATIFIED-S237 — retire capability (0 prod rows). Enum 15 → 14 values on Q-OQR1-16 combined PR. methodology absorbs remaining concept space. Lockstep-with-migration retire pattern.	docs/ontology/04-content-type.md + 0.9-collapse-candidates.md §14.1
CV 06 lifecycle-type — regulation vs date_bound semantic boundary	(S236 WP6 finding)	RATIFIED-S237 — regulation-as-specialisation rule. regulation = externally-set effective dates (regulator-published); date_bound = internally-set validity windows (organisation-set). DCAT-AP-aligned. Implementable in lib/freshness.ts + classification-prompt update; no schema change.	docs/ontology/06-lifecycle-type.md Notes block
CV 13 ingest-source — bid_library parameter literal rename	(S236 INV-1 §7.3)	RATIFIED-S237 — rename bid_library → bid_library_extraction in lib/layer-inference.ts:21 + scripts/kb_pipeline/layer_inference.py. Inference-function-internal, NOT a DB value. Cleanup PR separate (out of WP6 scope).	docs/ontology/13-ingest-source.md Notes block + 0.9-collapse-candidates.md §14.4
CV 16 extraction-method — firecrawl provenance enum extension OR prune	(S236 WP6 finding)	RATIFIED-S237 — prune-on-migration timing: firecrawl pruned from baseline_values when CHECK migration drops it (lockstep-with-migration retire pattern).	docs/ontology/16-extraction-method.md Notes block + 0.9-collapse-candidates.md §14.2
CV 16 extraction-method — Python extractor divergence (trafilatura/pdfplumber)	(S236 WP6 finding)	RATIFIED-S237 — retire on Docling adoption per 00-synthesis-v2.md §3.2 + §3.3 (Docling primary PDF/DOCX/XLSX; pullmd retained for HTML). Detailed write-path reconciliation belongs in WP4 architecture sub-docs 02-data-flow.md + 03-tech-stack.md.	docs/ontology/16-extraction-method.md Notes block + 0.9-collapse-candidates.md §14.3
CV 19 engineering-types — keep or drop the entire CV	(S236 WP6 finding)	RATIFIED-S237 — KEEP as engineering-register CV (13 values label internal type domains).	docs/ontology/19-engineering-types.md

6.2 — Docs-site framework closure

Item	Originating finding	Post-S237 disposition	Source
GitBook vs Astro+Starlight docs-site framework	(S236 WP6 plan; S237 Liam direction)	RATIFIED-S237 — Astro+Starlight. Same-repo docs-site/ sub-directory most likely; standalone repo retained as contingency only. GitBook framing in earlier drafts retired. Build deferred to production-readiness track per Liam.	docs/ontology/README.md §“Docs-site auto-update plan (Astro + Starlight)” + 00-synthesis-v2.md §5.4

6.3 — WP6 ontology harness implementation closure

Item	Originating	Post-S237 disposition	Source
WP6 D1 implementer — ontology Zod harness + content-type registry + parity test	S236 TECH-EDITOR commit 68a13f5e (canonical D1 spec)	LANDED-S237 — commit a258d144. 5 new files (lib/ontology/{schemas,loader,content-type-registry}.ts + parity test + cocoindex stub); lib/validation/{schemas.ts:41-57,ingest-schemas.ts:11} swapped to CONTENT_TYPE_VALUES. Test/lint/knip/build all green.	docs/specs/wp6-ontology-harness/TECH.md
WP6 E2 ratifier verdict	S237 acceptance gate	LANDED-S237	docs/specs/wp6-ontology-harness/verifier-reports/E2-implementation-ratifier.md

6.4 — STILL-OPEN items NOT addressed at S237

For audit-trail completeness — items still gating WP4 architecture sub-docs after S237:

Item	Originating	Status post-S237	Why still open
MCP-action review pass (Theme F)	Q4.5 + Finding 03 (1B-5) + feedback-findings-review.md §5.1 Theme F	STILL-OPEN	Theme F was NOT in scope of S237 Liam-pending CV resolutions; remains operational/orthogonal to WP6 ontology work. Lone STILL-OPEN gate blocking WP4 06-mcp-tooling.md.
0.9-intended-architecture.md doc split into architecture/01-*.md … 09-*.md	Phase B WP3 (S232 framing)	SCHEDULED-S238+	Source doc OUTDATED per Liam S237 — wave plan in docs/specs/core-docs-pathway-assessment/INV-architecture-split-readiness.md.

---

End of feedback-findings-review. All open items routed to one of: Ontology prereq, Cocoindex prereq, both, or Liam-only operational. Prereq sub-agents should treat §1 (cross-cutting themes) + §3 (input matrix) as their primary inputs; §4 (raw notes) for nuance. §5 (post-prereq rollup) captures the disposition state after S234 prereqs landed; propagates into 0.9-decision-graph.md + 0.9-collapse-candidates.md + 00-synthesis-v2.md in Phase 3. §6 captures S237 closures (CV-level + docs-site framework + WP6 D1/E2 implementation land).