Skip to content
Canonical

Pre S244 Project Feedback

User Feedback

Section titled “User Feedback”

  1. In a separate, concurrent session we’re about to merge the prod-readiness track to this branch (and main), which also brings across the implementation work from the now deleted ast-dataflow worktree, which includes new tooling. We should review the pipeline implementation plan, and the wider project plan, to identify where we would benefit from combining e.g., gitnexus & our ast-dataflow tool - T2 + T4 & T5 would look to be the most immediate items which could benefit. We will also have full access to cocoindex-code after the merge.

    • For awareness, after the merge with prod-readiness, product-roadmap.json and product-backlog.json structures will have changed, including the labels + ‘concepts’ being reversed - no action for main track here, as prod-readiness will handle migration actions, but mentioning for your awareness.

  2. We’ll need to update Project Plan & PLAN.md docs based on the work completed across s242 & s243 - starting by checking s242 & s243 continuation prompts.

    • Aside from the previous continuation prompts, the latest specs + outcomes from this feedback may also require updates to the docs.

  3. Now that we have a Project Plan in place and are kicking off the implementation, we should review, strip any non-load bearing content/duplication, and then promote (and version) docs/plans/phase-0-investigation/0.9-decision-graph.md as a project-specific reference document, to allow us to refer back during the implementation phases, if required.

  4. If we’re not already doing so, we should ensure we track:

    • The requirement for a p0-layer-nesting-spec.md (CV 03 UI nesting)
    • The non-canonical pipeline items - “Implementation-readiness audit (S240) surfaced 18 findings across 3 spec pairs.”

  5. We should update where necessary to confirm that it’s now been decided that we should retain the Diff-UI surface, to utilise it on top of the markdown sidecar. We should remove it from collapse list, and ensure it’s tracked in the project plan.

  6. When required from a Project Plan perspective, we should create docs/specs/id-59-concurrent-edit-intent-arbitration/TECH.md - I saw this listed as optional, somewhere, but this is key functionality and needs to be specced. Does this also relate to item 7 below?

  7. S14-Q1 Cocoindex v1.1+ multi-writer support timing:

    • I’ve found the following information which may help us resolve this without waiting for Cocoindex v1.1 - “the engine safely handles concurrent asynchronous updates on singular targets, but true distributed multi-writer support into the same index from entirely separate nodes is not a core, officially released feature.” Alternative options:
      • Branching & Merging: You can use its built-in branch deduplication logic to maintain individual indexes and later merge them.
      • Event-Driven Pipelines: You can use CocoIndex Custom Source API combined with a queue (like Kafka or a standard database) so that all asynchronous write requests are channeled to a single, serialized writer process.
        • https://hackernoon.com/stateful-api-to-database-synchronization-implementing-incremental-data-ingestion-from-rest-apis-wit.
    • Very valuable information on utilising cocoindex and lanceDB together - https://www.lancedb.com/blog/keep-your-data-fresh-with-cocoindex-and-lancedb.

  8. It would be valuable to source and then document any items which have been identified as v2 items (or haven’t been identified for v1, v1.1, or v2). The new architecture docs and 0.9-decision-graph.md are likely key locations to identify some of these, and possibly phase-b-prerequisite-2-cocoindex-deep-dive.md, to verify if all cocoindex functionality identified has integrated into our plans, accordingly.

    • Identifying these and collating them will help to inform the new product roadmap, and aid with planning decisions.

  9. For the item v4-alpha mempalace PG backend availability I’ve reviewed the repo and there has been positive progress in relation to mempalace’s postgres capabilities, which we should reviewing and determine if this changes anything in our plan. Please see the following PRs for more information:

    • https://github.com/MemPalace/mempalace/pull/665
    • https://github.com/MemPalace/mempalace/pull/1072
    • https://github.com/MemPalace/mempalace/pull/1337

  10. From phase-b-prerequisite-1-onthology-pipeline-feedback-investigation.md - §5 — content_items ↔ source_documents relationship mapping (this doc was pre-intended_architecture doc split) and docs/ontology/ I’d like as to do one more pass of the content_item + source_documents interaction, to ensure I fully understand the intended setup.

    • What I would be keen to understand, for example, is where any duplication could occur and how the system handles this:
      • If a user adds a case study to the localfs, is this a source_document with type case_study? What if a case study enters the system another way e.g., file upload, via MCP tool. Are these all tagged/ID the same way in cocoindex?
      • Similar when editing e.g., for UC1 (typo fix Candidate A) — the approach is Tiptap + Yjs + filesystem write to source_documents.original_path) but what if the typo fix is in a content item?
        • I may be missing something and the agreed approach may now be well documented as the topic has come up a few times - my assumption would be that if this is clear anywhere, it’s likely in either the new architecture docs (possibly 09-diagrams.md and others), or the ontology CVs, or more recently, specs/content-model-invariants/PRODUCT.md

  11. From specs/cocoindex-ledger-api/TECH.md - two things that I’d like to understand:

    • (i) I can’t recall the driver for this spec. Assuming that it will be quite a while before non-tech users use MCP tools to check on cocoindex runs, what does this feature provide?
    • (ii) Regardless of the outcome of point (i), whilst I’ve suggested TS-facing, is it also feasible that this could be Python, and if so, which is the more aligned approach, after the implementation of the canonical pipeline? Asking this as a non-technical user.

  12. From specs/reserved-workspace-seats/ - whilst we’ll have a planned, reserved schema baseline for the intelligence workspace, does this take into account the platform’s existing intelligence functionality and DB schema, and any refactoring/migration which may be required?

POST-INPUT AMENDMENT (S244 Wave 0.5 audit, commit 4abf7328): Initial S243 response identified 2 JSONB fields needing Shape B promotion (company_profile_id, guide_id). The Wave 0.5 audit during S244 spec-ratification extended the scope to 3 typed columns by surfacing the relevance_threshold real NULL admin-only SI-L5 pipeline setting (0 prod rows but live write path + UI per lib/validation/schemas.ts:1150-1154; missed read-path site scripts/batch-rescore-articles.ts:157-158 added). T-5 read-path expanded from 13 refs/6 files to ~23 refs/13 files. Type-interface drift in hooks/intelligence/use-intelligence-workspaces.ts:13-18 resolved by surfacing typed top-level API response fields. Helper-first hybrid migration approach (lib/intelligence/workspace-context.ts ships pre-T2 reading JSONB; swapped at T2 PR to read typed columns) ratified. See docs/specs/intelligence-workspaces/TECH.md for full Wave 0.5 amendment summary.

  1. We need to update the project plan to reference that we already have research documentation prepared, which will be the starting point for Phase 3 - Sales Proposals functionality.

    • Current closure criteria is incorrect - the Sales Proposals application is different from e.g., Procurement, and so integration/usage of Q&A pairs isn’t the best success metric, and undersells the actual required functionality for what will be a key KH platform application.

  2. Is there anything in v1.1 which would mean we are almost instantly reworking any of the Phase 1 items, or is everything additive? For example:

    • Markdown sidecar materialisation for approved Q&A pairs (UC5 4.6.Q7 + UC6 4.3.Q7)
    • q_a_extractions to markdown sidecar pipeline

  3. Similar to item 14, are there any tasks in Phase 1 which would benefit from having a full spec in place for any of the reserved satellite tables?

  4. The canonical pipeline implementation plan file (PLAN.md) mentions “§6 Drift items disposition - The 19 drift items from canonical-pipeline-drift-audit-s240.md are mapped to PLAN.md sections or NEW spec files” - we need to ensure that this is the case, to avoid anything being missed during the implementation (unless any of the drift items have since been superseeded based on any work from s241-s243)

  5. Has the removal of functionality which is being retired been been factored into the Project Plan, or at the individual task spec-level?

  6. In the canonical pipeline implementation plan (PLAN.md), items T6 & T7 are currently incorrect - Data migration ISN’T required, re-ingestion via cocoindex pipeline IS.

    • It would be helpful to understand where this misunderstanding came from, just so we can ensure there’s no confusion on this, as it may impact other parts of the wider Project Plan, and to ensure we’re clear on approach and next steps, as I’m guessing this may also have implications on task sequencing.
      • 0.9-synthesis.md section ‘8.4 Cocoindex Option A wiring’ mentions “Create Supabase staging branch” and given the scope of Q-OQR1-16 combined PR migration, is it likely that we’ll hit issues where a blank DB would be the more suitable approach?
        • A key validation for the new canonical pipeline is being able to compare against current KH state, after ingesting the client’s document corpus in our new setup.

  7. We need to check form type’s, presumably in the procurement-workspaces spec, and docs/ontology/26-form-type.md, and ensure that these are accurate. For example, I noticed that g-cloud is a form_type - I may be wrong but I thought g-cloud was a framework. We should validate the others too.