Research dossier: what Harrison needs, what exists, and what we should build.

1. What we actually researched

The discovery dossier combines fifteen preserved source files, Harrison’s 9 minute 25 second process walkthrough, two category master-pack editions, a 331-row document mapping register, 136 live Provider Compliance sitemap URLs, 208 companies and products, and 127 GitHub repositories screened across three technical domains plus the corrective God-source audit. Thirty companies received deeper workflow profiles. Thirty-seven repositories received deep mechanics profiles. The broader count of 67 deep system profiles is the combined 30-company and 37-repository analysis set.

The market work is deliberately split into breadth and depth. The 208-company directory is a global discovery census: every record carries geography, customer, delivery model, capabilities, public proof, confidence and relevance. Use the “30 deep workflow profiles” filter to see only the companies where we documented how the product works and what Harrison should learn. The market synthesis turns those records into seven market archetypes, ten feature-frequency findings, a top-25 learning shortlist and six areas of white space.

The technical work is also split into breadth and depth. The repository explorer contains 95 structured records with lane, purpose, mechanics, gaps, licence information and adoption verdict. The research now covers 43 regulated case/GRC/QMS/whole-case candidates, 44 document-automation candidates and 40 agent/workflow/memory candidates. The source datasets are public: regulated systems JSON, document factory JSON, agent workflow JSON and the corrected VPS architecture JSON.

2. Where every research document lives

The research-pack register is the canonical index. It names every private working paper, explains its purpose and links to a public-safe readable ruling. The raw WhatsApp export, transcript, client applications, master ZIPs, personal data and private prompts remain withheld; the conclusions and evidence counts are published here.

3. What Harrison’s process requires

The video shows a coherent regulated case process currently implemented through manual transfers between specialist Claude projects. Harrison begins with client answers, entity history, selected services, CVs, qualifications and other evidence. He proposes an organisation structure, tests whether responsibility is concentrated sensibly, sends it to the client and preserves the approved version. That structure then governs business plans, financial assumptions, workforce plans, recruitment plans, policies and application answers.

At each stage Harrison distinguishes three things: defects he can repair from existing evidence, reasonable proposals that still require confirmation, and facts or documents only the client can supply. That distinction is a core product feature. When funding, identity, responsible-person suitability, service scope or another material point is unknown, the system must create a gap with an owner and next action. It must not complete the sentence and quietly treat probability as fact.

The master-pack stage is not ordinary mail merge. The Category 1–4 ZIP contains 786 entries and the Category 1–5 ZIP contains 852. There are 282 normalised overlapping paths, and 173 same-path files differ. A job must pin an edition and checksum, determine inclusion from controlled rules, apply typed variables, preserve Word and workbook structure, produce review markings, run a pre/post token census, validate scope and terminology, scrub final metadata and emit an immutable manifest and delta log. The master-pack chapter explains the exact mechanics; the document research explains which libraries can execute them.

The final product is therefore one persistent case with one conversational front door and governed lanes for intake, organisation design, source documents, master-pack construction, application assembly, gap analysis, client review, declaration, external submission and Commission lifecycle. The database and event history are authoritative. The model can extract, propose, compare, draft and validate. Consultants and clients confirm facts and decisions. An authorised human owns the final declaration and submission.

4. What the 208-company market taught us

The “competitor market” is actually seven adjacent industries. Regulated provider operating suites such as Lumary, AlayaCare and WellSky manage clients, staff, scheduling, care and finance. Inspection and audit products such as Gatekeeper, Nomotix, Willow, AlwaysReady Care and Radar Healthcare map obligations, collect evidence and manage corrective actions. Policy consultancies sell templates and expert readiness. Enterprise GRC products such as AuditBoard, Diligent, MetricStream and ServiceNow manage controls, risk and assurance. eQMS and regulatory-submission platforms such as Qualio, Veeva Vault Quality, MasterControl, Rimsys and RegDesk control documents, change and submissions. Workforce products manage credentials, screening, training and expiries. Open-source infrastructure supplies case, document, rule and workflow primitives.

Common features are not the strategic answer. Evidence repositories, policy libraries, checklists, audits, gap actions, credentials and framework mappings are everywhere. They are table stakes. The uncommon capabilities are the ones Harrison’s process depends on: a structured applicant backstory; explicit consultant-versus-client ownership; claim-level links from an application answer to case evidence and regulatory authority; pinned form and master-pack editions; comprehension and declaration history; and continuity from application through information requests, audit, decision, renewal and variation.

The closest direct analogues are useful for different reasons. Gatekeeper demonstrates obligation-to-evidence-to-audit reporting. Nomotix demonstrates continuous aged-care and NDIS readiness. Willow demonstrates multi-framework AI positioning. CareDocs and Radar Healthcare show provider operations and inspection-readiness patterns. Qualio, Veeva and MasterControl show controlled content, review and change. None of the public evidence showed one product clearly joining applicant backstory, categories, people, finances, evidence, document edition, form claims, gap ownership, approvals and post-registration history. That integration is the product wedge.

5. What GitHub can provide—and what it cannot

Lane one: regulated case, GRC and QMS. Forty-two credible candidates were structured and twelve received deep profiles. WKS Platform is the closest single case/workflow benchmark: Spring Boot, React and Camunda provide stages, tasks, timers, assignments and approvals. OpenQMS is the strongest regulated quality reference for controlled documents, deviations, CAPA, audits and change. Unicis is the strongest current open GRC reference. OPA is the strongest external rule-engine option. The best three-project benchmark is WKS + OpenQMS + OPA, but deploying all three would introduce overlapping authorities, Java/Camunda operations, licensing review and substantial integration before one Harrison case is proven. Verdict: learn and probe, not foundation.

Lane two: the document factory. Forty-four projects were screened and twelve profiled. python-docx is the best direct DOCX primitive because it exposes paragraphs, runs, tables, sections, headers and footers. openpyxl covers workbook and register manipulation. pypdf is the first probe for compatible Commission PDF forms. Pydantic types generation jobs, manifests, variables and validator results. Docling, OCRmyPDF, Gotenberg and qpdf are optional workers only when real fixtures prove the core four insufficient. Verdict: adopt the four primitives; keep edition selection, source precedence, inclusion, approval, census and finalisation custom.

Lane three: agents, durable workflow and memory. Forty repositories were verified and twelve profiled. LangGraph is the closest single agent framework for graph state, checkpoints and human interrupts. Temporal is the high-assurance reference for replayable long-running workflows. Langfuse is the strongest observability/evaluation companion; Promptfoo is useful for regression fixtures. Mem0 and Zep can hold derived preferences or reviewed lessons, but must never become applicant authority. OpenFGA and OPA are credible later controls for complex authorization and policy. Verdict: begin with explicit database state; add LangGraph only when real branching and resume complexity justify it, and add Temporal only when direct workers cannot reliably survive multi-day waits.

6. The corrected implementation direction

Run one owned application on a VPS. PostgreSQL 16 + pgvector holds case state, full-text retrieval, embeddings, approvals and audit. MinIO or an encrypted mounted volume holds original evidence and generated artifacts. Redis or Valkey coordinates bounded workers. Gotenberg and LibreOffice handle conversion. FastAPI and React provide the domain API, consultant workspace and client portal. One audited model gateway routes to local Ollama or explicitly approved API models. This keeps storage, networking, backups, retention and model egress under operator control.

Use Legalise as the God-source specification for the matter/document/AI/citation/sign-off/audit/export loop. Rebuild that loop around Provider Compliance objects and stages rather than forking the legal vocabulary unchanged. python-docx, openpyxl, pypdf and Pydantic remain bounded document and contract primitives; Dify, n8n, Docling, Langfuse, OPA, OpenFGA and Keycloak are evidence-triggered sidecars, never the application authority.

SISO-owned code must still define the meaning-bearing layer: applicant backstory; case and person records; category and form versions; claim-to-evidence-to-requirement lineage; consultant/client gap ownership; approval and declaration events; deterministic regulatory validators; append-only business audit; deletion and restore; and the successful/incomplete evaluation fixtures. No repository can safely infer those semantics from Harrison’s files.

The next gate is not “build the full app.” It is one de-identified successful case and one incomplete case represented end to end. Each needs a pinned regulatory and form version, selected master-pack edition, structured backstory, evidence-linked claims, correct gap routing, approvals, document receipts, review and final output sets, submission/outcome history, cross-tenant leakage tests and a deletion/restore exercise. If that fixture passes, add user-facing workflow. If it exposes genuine branching, durability, authorization, evaluation or parsing limits, activate the relevant deferred repository using the triggers documented in the architecture decision.