Legalise unchanged
Closest whole-system loop and self-hosted stack, but explicitly evaluation quality with no organisation multi-tenancy.
Blueprint, never live as-is
Corrected convergence · complete AI onboarding case first
One owned VPS application, one God-source blueprint, bounded supplementary repos.
No managed Supabase dependency. PostgreSQL, files, queues, models, backups and networking stay under operator control. Legalise supplies the closest whole-system reference; Harrison’s domain remains custom.
Recommended self-hosted foundation
Adapt the whole-case loop. Own the domain and deployment.
Legalise is the reference implementation. The production product is a Provider Compliance application running on a controlled VPS.
01God-source blueprintLegalise
Matter, documents, selected-source AI, governed skills, sign-off, audit and verifiable export.
02Case authorityPostgreSQL + pgvectorCase state, search, embeddings, versions, approvals and append-only events.
03Owned filesMinIO / encrypted volumeOriginal evidence and generated artifacts on VPS-controlled storage.
04Owned applicationFastAPI + ReactDomain API, consultant workspace, client portal and audited model gateway.
05Bounded workersDocument factorypython-docx, openpyxl, pypdf, Gotenberg and fixture-triggered extraction.
Foundation alternatives
Why this direction beats the tempting shortcuts.
The deciding question is whether the option advances Harrison’s complete case loop without surrendering authority or control.
NocoBase
Strong AI/business-system reference, but advanced approvals and client-delivery rights depend on commercial editions.
Research reference, not defaultOwned VPS adaptation
Rebuild Legalise’s governed loop around provider-registration objects, roles, stages, documents and lifecycle.
Build this vertical sliceDirectus
Useful Postgres, files, APIs and permissions, but still needs the entire case, AI, evidence and sign-off product.
Optional admin substrateDify + n8n + BPMN + GRC
Many visible features, but duplicate workflow and storage authorities with no coherent provider-application case.
Reject as foundation
System mechanics
How the minimum system works.
A model may propose content; it never becomes the case authority or mutates an approved artifact directly.
-
1
Receive and manifest
Files enter versioned storage and receive tenant, case, hash, sensitivity, scope and source records before parsing.
-
2
Structure the case
Pydantic contracts validate backstory, facts, unknowns, claims, evidence, gaps, decisions and approvals stored in Postgres.
-
3
Run a pinned document job
A Python worker reads the exact master edition and performs DOCX, XLSX or PDF operations from a versioned job contract.
-
4
Emit receipts
Every transformation produces input/output census, delta log, validation results and an artifact manifest.
-
5
Approve exact versions
Consultant and client approvals bind to specific claims, decisions and artifact versions.
-
6
Finalise mechanically
Finalisation creates immutable output records; submission remains a separately authorised human event.
Deferred-by-default
Every optional repo has a trigger.
No “we may need it later” dependencies.
Add as an AI-workflow sidecar only when non-developers need to author bounded model/RAG tools.
Add for external notifications, imports and exports—not the provider case lifecycle.
Add when rule volume and effective-date versioning require a separate tested catalogue.
Add when organisation, consultant, client and reviewer relationships exceed direct Postgres policies.
Add when model-call volume requires dedicated trace and prompt comparison.
Add when mixed-format fixtures fail narrow local parsing probes.