QENEX Law — Design Spec (v0.1, parked)#
Working name: QENEX Law · Proposed domain: law.qenex.ai Status: PARKED — internal-first build, deferred until current unfinished work (Lab focus, fundraise/AA, infra remediation) is cleared. Owner: CEO / Founder · Date: 2026-08-09
1. Purpose#
An internal AI legal/contract automation tool for QENEX LTD — a self-hosted alternative to GitLaw (git.law), the service used to draft the pre-seed term sheet. Goal: draft, review, version, and sign QENEX's own legal documents with AI assistance and provable provenance, reusing infrastructure QENEX already runs. Public offering is a possible later phase, explicitly not near-term.
2. Guiding principles#
- Internal-first, dogfood-only. No external users until the clause library and QA are trustworthy and the liability/UPL questions are addressed.
- Templates over blank-page generation. Draft from a curated, version-controlled clause library — not free-form LLM output (this is what avoids errors like the 18-month-longstop SEIS/EIS trap).
- Human-approve gate on every material change. AI proposes; a human accepts.
- Provenance by default. Every version cryptographically timestamped and anchored.
3. Architecture — reuse existing QENEX infrastructure#
| Capability | Existing QENEX component |
|---|---|
| Version control ("git for law") | Forgejo (git.qenex.ai) |
| In-document editing / track changes | Collabora (qenex_collabora_, qenex_office_) |
| AI drafting / review / specialist routing | qenex_ai_proxy, qenex_multi_inference, qenex_research_council, provider-switch |
| Reasoning + memory of standard terms | LCO / qenex_brain |
| Cost control | semantic cache |
| Document output | qenex_pdf_generate / pdf_generate_ai |
| Tamper-evident provenance | dual-rail audit anchoring (BOSA RFC-3161 + OpenTimestamps/Bitcoin) + IPFS pinning |
| Contract metadata store | Supabase (ops backend, project tmsvyuxaiozmcxdaaqeu) |
| Contacts / dashboard / renewal alerts | Odoo + qenex_deadlines/aide |
| Auth / SSO | Keycloak (auth.qenex.ai) |
| Web app / frontend | qenex_web_weaver / qenex_site_provisioner → law.qenex.ai |
| e-sign | Docusign connector (or self-built) |
4. Differentiators (vs GitLaw)#
- Provable provenance: every clause and signature version cryptographically timestamped and anchored to Bitcoin — independently verifiable, not just an internal "audit trail".
- Self-hosted / sovereign: documents never leave QENEX infrastructure.
- Native fit with the rest of the QENEX estate (SSO, Odoo, deadlines, mail).
5. Phased plan#
- Phase 0 (now, zero-build): keep every QENEX legal doc in Forgejo as clean, structured, annotated templates. This accumulates the clause library — the real moat — at no extra cost.
- Phase 1 (internal MVP, ~weeks when unparked): Forgejo-backed templates + AI proxy drafting/review with human-approve gate + anchored versioning. Dogfood on QENEX's own paperwork only.
- Phase 2 (internal hardening): clause trust-scoring, jurisdiction/contract-type routing, renewal dashboard via Odoo, Collabora track-changes UX.
- Phase 3 (public — only after unfinished work clears): external users, requiring legal-content QA, professional-liability and unauthorised-practice-of-law groundwork, and a standards/review process.
6. Key risks / guardrails#
- Legal content is the hard part, not the software. The moat and the cost is the lawyer-reviewed clause library and QA — not the tech (which mostly already exists).
- Regulatory / liability: putting legal documents in front of others raises UPL and professional-liability exposure — a Phase 3 gate, not a Phase 1 concern.
- AI accuracy: template-anchored drafting + human gate + specialist review to prevent plausible-but-wrong output (e.g. the SEIS/EIS longstop issue).
- Focus: must not pull attention from Lab (sole strategic focus) — hence internal-first and deferred.
7. Open questions#
- Repo/org home in Forgejo (e.g.
qenex-admin/qenex-law). - Build vs. reuse for e-sign (Docusign connector vs. self-hosted).
- Which document types to template first (term sheet, ASA, NDA, employment, board resolutions).