id-95 Supporting Info

• There are questions highlighted in the prompt which may not be covered by the current RESEARCH.md doc, and I’ve provided responses below to the docs remaining OQs.

• Important to note, is that the bulk of the id-90 work is now complete, potentially unblocking id-68.30. Along with the id-90 ledger journals, continuation-prompt-kh-s335-id90-closed-id102-spec-complete.md will provide context on what was done and next steps (id-102).

RESEARCH.md Outstanding OQ Responses

• OQ-95-2 (= OQ-64-8): new preview branch of current Supabase DB, then wipe current prod/staging and cutover with the preview branch data.

  • Could we already create the per-client Supabase project setup? So pre-re-ingest, when the data structure updates are complete, could we create a new Supabase project, and then either the new or current becomes our’s or Phew’s, whichever approach would make most sense.

• OQ-95-4 (= OQ-66-7): AGPL-pullmd conveyance - unless I’ve misunderstood from a technical perspective, wouldn’t an “on-prem” pipeline, by definition, ship into the client perimeter at handover? This isn’t a blocker, as we have mitigation options, I’m just keen to understand.

• OQ-95-5 (= ID-69): client-FS corpus folder structure — we need to design/determine this, currently we have local-fs to replicate a client’s file server. ID-71 will provide additional context on v1 intended approach to document sources/ingestion setup.

• OQ-95-6: platform brand / domain — Is it feasible to use aisolutionhub.co.uk domain for now (which we own), following the approach used by phew, so kh.aisolutionhub.co.uk and then track the brand pick/long-term domain separately? Rename current Vercel knowledge-hub project to knowledge-hub-phew, and create new Vercel project as our main platform project, if that’s determined to be the correct client deployment approach.

• Point 4, from the additional questions in the continuation prompt - for the client content that currently sits on our docs-site, does it need to be client-specific, or is this just because of historic design approach i.e., could it be reworked in a different way, to avoid the need for separate private client repos, or is separate private repos considered the best practice approach for client deployments?

• We actually created demo-bootstrap-spec.md, but it was done a considerable amount of time ago, very early on in the platform’s development. And we’ll reference documentation and schema structures which are likely extremely out of date. But noting here as it sits within the Docsite specs folder and was never archived as the intention was always to at some point be able to ensure we have a split platform and client setup.