# GoodBooks CLM (Contract & Legal Document Lifecycle Management) — Future Session Brief **Status: not started. This is a planning brief for a dedicated future session, not a build plan for the current one.** This document exists so a future CLM design/build session can start from a grounded, code-verified picture instead of re-deriving it. It was produced during the Entitlement engagement (tracker: `in-dowloads-entitlement-folder-we-woolly-stroustrup.md`, §50/§51) after the user asked two questions that turned out to have a much bigger answer than originally scoped: (1) is DMS mature enough to serve as a contract/legal-document engine, and (2) what else — vendor/procurement/e-tendering, partner/dealer, CRM service-contracts/AMC — needs the same kind of capability. Everything below is either a direct finding from reading this codebase, or a design decision the user made explicitly during that conversation (marked as such). --- ## 1. Why this exists — the gap, stated precisely Every entry point that creates an account or a business relationship in GB5 today — trial signup, demo registration, internal client onboarding, vendor onboarding, partner onboarding, a CRM service engagement — has **no real mechanism** to capture, version, or prove acceptance of a legal document. The one checkbox that exists (QuickStart's `acceptTerms`) is decorative: it gates a submit button client-side and sends nothing to the backend. If any of these relationships were ever disputed, GB5 has no way to prove what anyone agreed to, when, or against what document version. Beyond that narrow gap, four other business relationships — vendor agreements, partner/dealer agreements, CRM service contracts (AMC), and e-tendering — have **zero** contract-lifecycle capability of any kind, not even schema stubs. Two of them (CRM, FM) already have real, dangling references waiting for a real implementation to attach to. ## 2. Grounded findings — what's real today, verified by reading the code, not assumed ### 2.1 Document/content management modules - **DMS (`GB5Solution/DMS/`) is a thin CRUD shell, not a document-lifecycle engine.** Its only real business logic (`DMSBLL/ESSDocument/ESSDocumentBLL.cs`) is HR self-service file storage riding on the generic `TATTACHMENT` table. Everything else (`Folder`/`Space`/`Project`) is an Alfresco-migration skeleton (`BulkIngestion`, `AlfrescoMigration` folders) with unused permission/wiki/blog flags and no logic behind them. Against the six capabilities a contract-lifecycle system needs (versioning, approval workflow, e-signature/click-wrap capture, expiry/renewal tracking, taxonomy, ACL), DMS has **none for real** — only a bare `Version` audit column (not content versioning) and an ownership-only access check. - **CMS (`GB5Solution/CMS/`) is a separate, more mature module** — real content versioning (`TCONTENT.CURRENTVERSION`, `TCONTENTVERSION` snapshots, `RestoreVersion.cs`) and a genuine approval workflow (`ContentBLL.cs`: Draft→SubmitForReview→Approve→Publish→Archive, status-machine gated). But it's scoped to marketing/web content, has no acceptance/signature capture, and no expiry/renewal automation beyond an unused nullable field. **This is the direct template to reuse for CLM's own document-version lifecycle** — a closer fit than a binary Draft/Released state machine, since it already models a distinct "submit for review" step separate from "publish." - **IDMS's `LSIGNOFFREGISTER`** — an insert-only, trigger-enforced-immutable sign-off ledger (`SIGNEDBYID`/`SIGNEDON`/`CONTENTHASH` = SHA-256 of a JSON snapshot) scoped to delivery-engagement milestones — is a real, proven "who-accepted-what-when, tamper-evident" pattern. **This is the direct template for CLM's own acceptance/consent ledger.** - **A real, legacy `MDOCUMENTTYPE` table already exists** (`GB5Framework/FrameworkBLL/DocumentType`, part of the captured base schema) — a tenant-scoped ECM classification table (`DocumentCategoryId`/`ModuleId`/`IsValidity`/`RemindDays`/`IsVersion`/`IsCheckInOut`/`IsRecord`/`SecurityGroupIds`) paired with `ECMRights`/`ECMRole`. Its own BLL (`DocumentTypeBLL.cs`) is bare Get/GetSelectList/Delete pass-through — zero logic behind any of those flags; `ECMRightsBLL`/`ECMRoleBLL` are equally plain CRUD with no real access-control enforcement found anywhere. **Same conclusion as DMS: legacy scaffolding, not a working engine.** But its table name is real — **CLM's own schema must not use `MDOCUMENT*`/`LDOCUMENT*` naming**, or it will collide outright. This engagement's own interim Entitlement schema (see §6 below) uses `MAGREEMENT*`/`LAGREEMENT*` for exactly this reason; CLM's own eventual schema should use a `CLM`-rooted prefix (e.g. `MCLM*`/`TCLM*`/`LCLM*`) instead, confirmed by this brief's author to have zero collision via repo-wide grep at time of writing. - **`TATTACHMENT`** — a real, already-proven generic polymorphic attachment table (`OBJECTTYPEID`/`OBJECTID`, `DOCUMENTTYPEID`, `CMSID`, `VALIDFROM`/`VALIDTO`, `VERSION`), already used by DXP's own KYC document upload (`SubmitKyc.cs`'s two-phase RowGuid upload-then-resolve pattern) and by DMS's own ESS documents. **This is the right, already-proven mechanism for storing the actual document bytes a signer saw — CLM should call it directly, not invent a new blob-storage mechanism, and not route through DMS's own thin HR-scoped BLL layer.** ### 2.2 The five business domains checked for existing contract-lifecycle capability | Domain | What's real today | What's missing | |---|---|---| | **Vendor agreements (DXP)** | `PartyKycDAL`/`SubmitKyc.cs` cover identity/onboarding; `VendorPoDAL`/`PoAcknowledgementDAL` cover PO transactions | Zero fields anywhere for agreement terms, a signed document, validity, or renewal. No `agreement`/`contract` concept found in DXP source at all. | | **Procurement / e-Tendering** | Real PR→Purchase-Enquiry→Quotation→PO→GRN transaction flow (`MBIZTRANSACTIONCLASS`-driven); a real Procurement dashboard (`20260830_ProcurementOverviewDashboard_Full_SqlServer.sql`, a reporting layer on top of existing transaction data) | **Zero** tender/RFQ/bid schema anywhere — confirmed via exhaustive grep across every `.cs`/`.sql` file in the repo. No `TTENDER`/`TRFQ`/`TBID` table or BLL exists, not even as a schema stub. "RFQ/Inquiry" in the dashboard is just a biz-transaction-class label. | | **Partner/Dealer agreements** | `TPARTNER`/`TPARTNERPRODUCT` (identity/status only) | `TPARTNERTERM` is confirmed to be a flat terminology-glossary bundle (e.g. what a white-labeled partner calls "Invoice"), not a legal document. No commission-terms, signed-agreement, or validity/renewal field exists anywhere in the Partner module. | | **CRM Service Contracts / AMC** | `TCALL.ContractId`/`TCALL.ContractCycleNumber` — bare, unjoined int columns; `CRMDAL/DTO/Call/ProductServiceContractDTO.cs` — a fully-defined warranty/coverage-scope shape (`SupplierWarrantyFromDate/ToDate`, `LabourExpiryDate`, `PartsExpiryDate`) | The DTO is **completely orphaned** — no QB/DAL/BLL/endpoint references it anywhere in the repo. `TCALL.ContractId` has no contract master table to resolve against. This is the one domain with real, dangling references already waiting for CLM to give them something to point at. | | **FM (asset/equipment)** | `TASSETTYPE.ISAMC` — a single boolean flag classifying an asset type as AMC-covered | No linked contract record, dates, vendor, or value behind the flag at all. | **Bottom line**: this is genuine new-build territory across every named domain, not a case of stitching together several half-built things. The one asset every domain can already share is `TATTACHMENT` as the actual file-bytes store, and CMS's/IDMS's own patterns as the version-lifecycle/acceptance-ledger templates. --- ## 3. Product vision (as directed by the user during the originating conversation) > **GoodBooks Contract & Legal Document Lifecycle Management (CLM)** — a general-purpose enterprise capability that manages the complete lifecycle of contracts and legally significant documents, with specialized extensions for Procurement, Sales, HR, Finance, Projects, Vendors, Customers, etc. Entitlement and Procurement *consume* CLM rather than owning their own contract-management implementation. **What a good CLM must answer** — the acceptance test for the eventual design, not just a feature checklist: 1. **What is this contract?** — parties, entities, type, value, dates, purpose, business owner. 2. **How was it created?** — template, clauses, negotiation, approvals, source transaction. 3. **What was agreed?** — final terms, obligations, pricing, SLA, milestones, liabilities, rights. 4. **Who approved and signed it?** — approvals, authority, signatures, dates, evidence. 5. **What must happen after signing?** — obligations, deliverables, payments, renewals, insurance, certifications, milestones. 6. **What is changing?** — amendments, variations, addenda, change orders. 7. **What is coming due?** — expiry, renewal, notice period, obligations, milestones. 8. **How is the contract performing?** — commercial utilisation, SLA, performance, disputes, claims, penalties. 9. **How does it end?** — completion, termination, expiry, closure, archive, retention. So CLM is **Contract Intelligence + Lifecycle + Obligations + Governance + Evidence** — not a repository with search attached. ### High-level shape ``` GOODBOOKS CLM Contract & Legal Document Lifecycle │ ┌────────────────────┼─────────────────────┐ ▼ ▼ ▼ CONTRACT LIFECYCLE LEGAL DOCUMENT CONTRACT INTELLIGENCE Request→Draft→Review LIFECYCLE & GOVERNANCE →Negotiate→Approve NDA/MOU/Notice/ Clause Library, Risk, →Sign→Execute Licence/Policy/... Compliance, Analytics, AI │ ▼ OBLIGATIONS & PERFORMANCE (deliverables, milestones, SLA/KPI, payments, insurance, guarantees, compliance, renewals, amendments, claims/disputes) │ ▼ RENEW / EXTEND / AMEND / TERMINATE / CLOSE → ARCHIVE & RETENTION underneath: WORKFLOW | DMS | E-SIGNATURE | ECP | GOP SECURITY | AUDIT | NOTIFICATION | ANALYTICS ``` --- ## 4. Architecture decisions already made (confirmed with the user — treat as settled, not open) 1. **CLM is its own module, both tiers.** A separate backend module (`GB5Solution/CLM/`, `CLMDAL`/`CLMBLL`/`CLMSL`, the same 3-tier template every other GB5 module already follows) **and** a separate frontend federation project (mirroring `projects/sqlworkbench`, `projects/pay` — its own `angular.json` entry, its own `federation.config.js`, registered in `gbhost`'s `federation.manifest.json`). Not folded into Entitlement, Procurement, or any existing module. 2. **CLM owns its own DB schema**, prefixed distinctly from the legacy `MDOCUMENTTYPE`/ECM tables (§2.1) — recommend a `CLM`-rooted prefix (`MCLM*`/`TCLM*`/`LCLM*`), confirmed to have zero collision with anything in the current schema. 3. **Procurement, Sales, HR, Projects, Finance, Vendors, Customers all *consume* CLM** — none of them build or own their own contract-lifecycle implementation. A domain-specific extension (like the Procurement one below) adds only what's genuinely domain-specific on top of CLM's shared core. 4. **CLM does not depend on or route through DMS's own BLL layer.** It calls `TATTACHMENT` directly for file storage, the same way DXP's KYC upload already does. 5. **Entitlement's own interim Phase 0 mechanism (§6) is temporary and will migrate into CLM, not run alongside it forever.** Once CLM ships with its own `CLM*`-prefixed schema, the interim `MAGREEMENT*`/`LAGREEMENT*` rows Entitlement built get migrated over as a one-time data migration — see §6 for the exact swap mechanism already built to make this painless. --- ## 5. Full functional domain catalog ### 5.1 General CLM (18 domains) Each entry: the core question it answers, representative capabilities, and a grounding note where something in this codebase already maps onto it. 1. **Contract Request & Intake** — capture request type, parties, purpose, owner, value, dates, risk/confidentiality classification; decide standard-template vs. legal-intervention-needed. Key question: *can this contract use a standard template, or does Legal need to intervene?* 2. **Classification / Taxonomy** — a configurable document-type hierarchy (Supplier/Customer/Employment/Corporate-Legal branches, each with sub-types, e.g. Supply Agreement / Framework Agreement / Rate Contract under Supplier). *Grounding*: the legacy `MDOCUMENTTYPE`/ECM area already models a `DocumentCategoryId` hierarchy — a naming precedent to look at, not working code to reuse. 3. **Contract Authoring** — templates, template versioning/approval, dynamic/conditional clauses, contract variables, commercial schedules, annexures/exhibits/attachments. 4. **Clause Library** — reusable clauses tagged by type/category/jurisdiction/industry/contract-type, with preferred/alternative/fallback/prohibited wording, risk level, legal owner, version, effective/expiry dates, approval status. This is the "legal playbook" — arguably CLM's most differentiating capability versus a bare document repository. 5. **Review & Collaboration** — internal/legal/business/finance/security/compliance/procurement review, comments, mentions, tasks, clause-level and document-level comments, parallel/consolidated review, review history. *Grounding*: this is exactly what ECP (business conversations layered on a business object) already exists for — reuse it, don't rebuild a comment/mention engine. 6. **Negotiation & Redlining** — counterparty negotiation, redlining, version comparison, track changes, added/removed/modified clause tracking, negotiation rounds, counterproposals, accepted/rejected changes, final agreed version, and a **negotiation-position matrix** (preferred / acceptable / escalate-to-legal per clause type, e.g. Payment: 30 days preferred / 45 days acceptable / >60 escalate). Genuinely new territory — no precedent anywhere in this codebase. 7. **Risk & Legal Review** — commercial/legal/financial/regulatory/data-privacy/cybersecurity/operational/IP/liability/insurance/termination risk scoring, rolling up to LOW/MEDIUM/HIGH/CRITICAL with an explanation of *why*. *Grounding*: no rules/scoring engine exists for this today; Enablement's rule-matching engine is the closest structural precedent but is scoped to UI guidance, not risk scoring — a new engine, likely reusing the "why is this flagged" explanation discipline this engagement already applies elsewhere (e.g. Policy & Rules / Enablement architecture). 8. **Approval & Authority** — approval routed by contract type, value threshold, risk level, department, geography, counterparty, deviation-from-standard-clause, duration, delegated authority. *Grounding, important*: this codebase's generic `WorkFlowEngine` exists but has **never had a real production consumer anywhere** (confirmed during an earlier phase of this same engagement, Thread 8's own research). The lighter, already-proven `ChangeRequest`-style Draft→Submit→Approve/Reject pattern (used successfully in SqlWorkbench and Entitlement) is the safer template for CLM's own first real approval-matrix implementation — do not make CLM the platform's first real `WorkFlowEngine` consumer without a strong, separate reason to. 9. **E-Signature & Execution** — signatory selection, signing order (sequential/parallel), digital/e-signature integration, signature status/evidence/certificate/timestamp, re-signing on rejection. *Grounding*: nothing in GB5 today does real cryptographic signing — only click-wrap-style capture (checkbox + IP + timestamp) is proven anywhere (IDMS's `LSIGNOFFREGISTER`). Real e-signature (DocuSign/Adobe Sign or equivalent) is 100% new integration work. 10. **Contract Repository** — CLM must **not** rebuild this; it stores contract identity/metadata/lifecycle/relationships, while DMS/`TATTACHMENT` store the actual files/versions/retention (see §7's ownership table). 11. **Obligations Management** — supplier/customer/internal/payment/delivery/SLA/insurance/certification/warranty/security/compliance/audit/renewal-notice/milestone obligations, each with description, responsible party, internal owner, due date, frequency, required evidence, SLA, status, escalation, consequence. Arguably the most important post-signature capability — a contract's value is realized by obligations being fulfilled, not by being signed. 12. **Milestones & Deliverables** — acceptance criteria, dependencies, responsible party, acceptance/rejection, evidence, payment linkage, delay/extension/penalty. Especially relevant to Projects/Construction/IT/Government contracts. 13. **Commercial Contract Management** — contract ceiling/value/committed/consumed/invoiced/paid/remaining, payment schedule, advance payment, retention, penalties, discounts, price escalation/indexation, tax, commercial milestones. Especially important for Procurement's own extension. 14. **Amendment / Variation** — never overwrite an executed contract in place; amendments/variations/addenda are their own versioned rows linked back to the original, with reason, scope/value/date/term/clause change, risk reassessment, budget impact, and — for material variations — re-validation against policy (potentially triggering a higher approval tier or a re-procurement review). 15. **Renewal & Expiry Management** — notice period, renewal window, auto-renewal, renewal approval/negotiation/proposal/contract, extension, non-renewal, termination, with staged reminders (e.g. 180/90/60/30/7 days before expiry). *Grounding*: this staged-reminder shape already exists in this codebase (Demo/DemoDB's own warning-then-expire job; License's `SupportValidTill`+`GracePeriodDays`) — directly reusable as a pattern, not new architecture. 16. **Claims, Disputes & Termination** — claim/dispute records tied to a specific clause, with type, amount, supporting evidence, responsibility, negotiation, settlement, approval, resolution path (settlement/arbitration/litigation); termination request/reason/notice/contractual-basis/approval/date/exit-obligations/final-settlement/asset-or-data-return/closure. 17. **Contract Closure & Retention** — Active → Completed/Terminated/Expired → Financial Closure → Obligation Closure → Final Evidence → Archive → Retention → Legal Hold / Disposal. Integrates with DMS's own retention mechanism — note that DMS has **no real retention logic today either**, only unenforced date fields, so this integration point itself may need DMS-side work, not just a CLM-side hook. 18. **Contract Analytics & Intelligence** — executive dashboards (contract value, active/expiring/high-risk contracts, supplier/customer concentration, contract utilisation, overdue obligations), legal dashboards (contracts under review, negotiation cycle time, non-standard clauses, legal workload, risk distribution, disputes), business dashboards (performance, SLA, deliverables, renewals, commercial utilisation), finance dashboards (value, commitments, payments, variances, unutilised contracts). *Grounding*: GB5's Analytics/DW platform is real and already proven for cross-module reporting — this is a natural new report-view family on that existing engine, not a new analytics stack. ### 5.2 AI-assisted capabilities (an intelligence layer over the above, not the foundation) Contract extraction from an uploaded document (parties/dates/value/renewal/termination/payment-terms/liability/warranty/insurance/SLA/governing-law/obligations); clause/risk analysis ("show me all unusual liability clauses"); obligation extraction ("create obligations from this contract"); renewal prediction ("which contracts need action in the next 90 days?"); a negotiation assistant ("what changed from our standard position?"); contract summarisation; natural-language Q&A ("what are our termination rights?"); contract-vs-template comparison. **No AI/ML infrastructure of this kind exists anywhere in GB5 today.** This is 100% new capability — not a reuse of anything found in this codebase — and should be sequenced last (see §8's phasing), once there's real production contract data for it to work against. ### 5.3 Procurement-specific extension (12 domains) — not a second CLM, an extension consuming the same core 1. **Award-to-Contract Conversion** — carry winning supplier/scope/price/evaluation result/tender terms straight into a contract draft, no manual re-entry. 2. **Tender-to-Contract Traceability** — the contract retains links back through plan→requisition→RFx→tender→bid→evaluation→award, so "why did we enter this contract" is reconstructable end-to-end for audit. 3. **Procurement Contract Controls** — award amount vs. approved amount vs. contract ceiling vs. budget vs. procurement threshold, approval authority, award/bid validity, bid/performance security, delivery schedule, payment terms, retention, liquidated damages, price escalation, variation limits. 4. **Performance Security / Guarantees** — bid security, performance/advance-payment/retention guarantees, bank guarantee, insurance surety, issuing institution, validity/expiry/claim-period/release/forfeiture, with expiry alerts. 5. **Supplier Insurance & Certifications** — a supplier's mandatory contract-linked compliance documents (insurance/certs/licences/tax); a supplier becomes ineligible if a mandatory requirement lapses — feeds Supplier Risk & Compliance. 6. **Contract → PO Control** — prevent a PO from exceeding the contract's remaining ceiling without an authorised exception. 7. **Contract → Receipt → Invoice** — CLM supplies contractual terms, P2P supplies the transaction, Finance supplies payment — three separate systems, cleanly composed, never merged into one. 8. **Procurement Contract Performance** — on-time delivery/quality/SLA/response-time/defects/service-availability/cost/compliance/documentation/safety/ESG scored against the contract, feeding renewal/extension/re-tender decisions. 9. **Procurement Variations** — reason/value-change/scope-change/time-change/budget-impact/procurement-impact/risk-impact captured explicitly, with policy validation and cumulative-variation-exceeds-threshold escalation (or a re-procurement review trigger). 10. **Framework / Rate Contract Management** — one framework/blanket/rate agreement → many call-offs/release-orders/mini-competitions, with ceiling and available-quantity/value tracked down to each call-off. 11. **Tender Document Lifecycle** — tender notice/RFx, terms & conditions, specification/SOW/BOQ, evaluation criteria, bid forms, addenda, clarifications/Q&A, bid security requirements, contract draft. Explicitly **pre-contract artifacts** — linked to CLM but not "contracts" merely by living in the same repository. 12. **Tender Terms → Executed Contract consistency check** — compare tender terms vs. award vs. draft contract vs. executed contract; flag material deviations (scope/price/duration/payment-terms/SLA/liability/warranty/security changed) and require justification/approval. High-value for audit and public-sector procurement specifically. *Grounding*: PCLM-01/02/03/06/07 have a real transactional spine to attach to (the confirmed-real PR→Enquiry→Quotation→PO→GRN flow). PCLM-04/05/09/10/11/12 are genuinely new territory needing their own schema, not just a CLM hook-up — no tender/RFQ/bid infrastructure exists anywhere in GB5 today (§2.2). --- ## 6. Relationship to what's already built — the P0 interim mechanism, and the migration path While the full CLM vision above was being scoped, Entitlement's own narrower, already-urgent need (proving ToS/EULA/Privacy Policy/AUP acceptance at signup — a real legal-exposure gap) was closed **without waiting for CLM**, via a deliberately swappable boundary. This exists today, in `EntitlementBLL/Legal/`: - **`IAgreementConsentProvider`** — the stable interface every Entitlement signup flow calls (`GetApplicableAgreementsAsync`, `RecordAcceptanceAsync`). This is the **one thing a future CLM session needs to preserve or deliberately replace** — every existing call site (self-service Trial signup, and any future ones) is written against this interface, not against a concrete implementation. - **`LocalAgreementConsentProvider`** — the current, interim implementation, backed by Entitlement's own `MAGREEMENTTYPE`/`MAGREEMENTVERSION`/`LAGREEMENTACCEPTANCE` tables (in Entitlement's own shared platform DB — deliberately named `MAGREEMENT*`/`LAGREEMENT*`, not `MDOCUMENT*`, to avoid the legacy ECM collision in §2.1). - **`IAgreementAuthoringBLL`/`AgreementAuthoringBLL`** — the interim Draft→Published→Superseded authoring flow (immutable-once-Published, `ContentHash` computed at publish time), with 3 internal SL endpoints (`SaveAgreementType`, `CreateDraftAgreementVersion`, `PublishAgreementVersion`) and one public read endpoint (`GetApplicableAgreements`). - **Placeholder content** is already seeded (`Docs/legal-placeholders/`, lorem-ipsum, clearly marked "NOT REAL LEGAL CONTENT") and wired into `SelfProvisionTrialAsync` end-to-end, purely so the mechanism itself could be exercised before real, counsel-reviewed content exists. **The migration, when CLM ships**: implement a new `ClmAgreementConsentClient : IAgreementConsentProvider` — an HTTP client following this codebase's own established cross-module-client convention (`ISqlWorkbenchClient`, `IPaySubscriptionClient`: a named `IHttpClientFactory` client, `Login`-header convention). Swap Entitlement's DI registration from `LocalAgreementConsentProvider` to it. **Zero change to any call site** (`StartSelfServiceTrialAsync`, or whatever else has been wired onto the interface by then). Migrate the historical `LAGREEMENTACCEPTANCE` rows into CLM's own schema once, as a data migration — this is a data-migration problem, not a design problem, precisely because the boundary was built to make it one. **Recommendation for the CLM session**: treat "become the real implementation behind `IAgreementConsentProvider`" as CLM's own first, smallest, already-scoped integration point — a concrete, low-risk way to validate CLM's core document/version/acceptance model against a real, already-proven consumer before building the other four domains' integrations. --- ## 7. Service ownership — who owns what, cross-checked against what's real today | Capability | Owner | Real today in GB5? | |---|---|---| | Contract lifecycle | **CLM** (new) | No — confirmed absent everywhere (§2) | | Contract files | **DMS** (via `TATTACHMENT`) | Partially — `TATTACHMENT` storage is real and proven; DMS's own BLL layer is thin HR-scoped CRUD, so CLM should call `TATTACHMENT` directly (same as DXP's KYC), not route through DMS's `ESSDocumentBLL` | | Content/templates | **CMS** (pattern reuse) | Yes for the version+approval-workflow *pattern* (`ContentBLL.cs`, real and proven) — reusable as CLM's own version-lifecycle template, not a literal runtime dependency (CMS itself is scoped to marketing content) | | Approval | **Workflow** | A real engine exists (`WorkFlowEngine`) but has **never had a real production consumer** anywhere in this codebase. The lighter, actually-proven `ChangeRequest`-style Draft→Submit→Approve/Reject pattern is the safer template for CLM's first real approval-matrix consumer | | Business conversations | **ECP** | Exists, real — appropriate reuse target for review/negotiation collaboration (domains 5/6) | | Communication | **EIP** | Exists — appropriate for notifications (renewal reminders, approval requests), alongside the already-proven `MDIRECTACTION`/`EmailActionHandler` mechanism | | Integration | **GOP** | Exists and already proven for exactly this kind of cross-boundary flow orchestration (the Promotion module) | | Contextual guidance | **Enablement** | Exists, real — a plausible fit for in-app CLM guidance, not for risk-scoring logic itself | | Forms/questionnaires | **FLS** | Exists — plausible fit for structured contract-intake forms (domain 1) | | Identity/security | Platform Security | Real, existing (`MUSER`/`MROLE`/`[MenuRights]`) — CLM's own admin/authoring endpoints should gate through this exactly like every other module | | Analytics | Analytics/DW | Real and proven — domain 18's dashboards are a new report-view family on an existing engine | | AI | "Product Intelligence / AI layer" | **Does not exist as a distinct layer anywhere in GB5 today** — every AI-assisted capability is genuinely new infrastructure | | E-signature | "Platform Integration Service" | **Does not exist** — no DocuSign/Adobe-Sign-style integration anywhere in this codebase; only click-wrap capture is proven | **The one-sentence test for "does this belong in CLM":** - **DMS** answers *where is the document?* - **CLM** answers *what is the legal/business lifecycle of the document or contract?* - **Procurement** (or Sales/HR/whoever the domain owner is) answers *why did we create this contract, and what business transaction does it control?* ### Target module hierarchy ``` GOODBOOKS ENTERPRISE PLATFORM ├── ERP / CRM / HRMS / EAM / SCM / PROCUREMENT ├── CLM ← NEW │ ├── General Contract Lifecycle ├── Obligation Management │ ├── Legal Document Lifecycle ├── Contract Performance │ ├── Clause & Legal Intelligence └── Claims / Disputes ├── DMS / CMS / KMS ├── ECP / EIP / GOP / Workflow ├── Analytics └── AI / Product Intelligence ``` --- ## 8. Recommended phasing Not something to design column-by-column in one pass — 18 general domains + 12 procurement-specific + an AI layer + real e-signature integration is a multi-year, multi-team scope. Suggested sequencing, tied to real business value and to what already exists to build on: - **Phase 0 (arguably already started)** — become the real implementation behind `IAgreementConsentProvider` (§6). Proves CLM's core document/version/acceptance model against a real, working consumer with minimal risk. - **Phase 1** — Classification/Taxonomy (domain 2), Contract Authoring (3), Clause Library (4), Review via ECP (5), a real approval-matrix on the `ChangeRequest` pattern (8). This is the minimum "author, review, approve, publish a real contract" loop. - **Phase 2** — Obligations (11), Milestones/Deliverables (12), Commercial Contract Management (13), Amendment/Variation (14), Renewal/Expiry automation (15), Analytics (18), plus the Procurement spine items with a real transactional base already in place (PCLM-01/02/03/06/07). - **Phase 3** — Negotiation/Redlining (6), Risk & Legal Review (7), Claims/Disputes/Termination (16), Framework/Rate contracts (PCLM-10), full Tendering (PCLM-04/05/09/11/12). Genuinely new territory across the board — each of these deserves its own scoping pass before schema design, not a bundled one. - **Phase 4** — AI layer (§5.2), real e-signature integration (domain 9's WetSignature/ESignature/CounterSignature methods, already reserved in the interim schema's own enum). Deliberately last: no infrastructure exists for either today, and both are high-effort, external-dependency-heavy, and most valuable once Phases 0-2 have real production data to work against. --- ## 9. Additional suggestions for the future session (not previously discussed with the user — flagged as suggestions, not decisions) 1. **Decide the counterparty-identity model early, and make it explicit.** A contract's other party is sometimes a `TPARTNER`, sometimes a DXP vendor `PartyId`, sometimes an `MCLIENT` (customer), sometimes a `TLEAD`/prospect not yet a client, sometimes an internal-only NDA with no external party at all. The interim schema modeled this as a `(CounterpartyType, CounterpartyRef)` pair with `CounterpartyRef` as a portable, non-FK integer (since the referenced tables live in different physical databases depending on type) — recommend CLM keep this shape rather than trying to force a single real FK, but make the resolution rule for each `CounterpartyType` a first-class, tested piece of code, not implicit convention. 2. **Resist making CLM the platform's first real `WorkFlowEngine` consumer without a clear reason to.** This came up twice in this engagement's own history (Thread 8 explicitly declined to be the first consumer, building a lighter `ChangeRequest`-style table instead) — CLM's approval-matrix domain (8) is exactly the kind of feature that *looks* like it needs a general workflow engine, but the actual proven, low-risk path in this codebase is the simpler Draft→Submit→Approve/Reject shape. If CLM's approval needs genuinely outgrow that (multi-level, conditional routing, delegation, SLA/escalation), that's the moment to reconsider `WorkFlowEngine` — with a small pilot, not as CLM's own default from day one. 3. **Don't let DMS's retention gap become CLM's problem to solve.** Domain 17 (Closure & Retention) is written as "integrates with DMS's own retention mechanism," but §2.1 found DMS has no real retention logic today — only unenforced `ValidFrom`/`ValidTo` fields. Either scope a small DMS retention fix as a prerequisite, or have CLM own retention logic for contract documents specifically (simpler, but duplicates what DMS should eventually do for every document type) — this is a real fork in the road worth deciding explicitly rather than discovering mid-build. 4. **Treat the Clause Library (domain 4) as the differentiator, and consider building it before full Authoring (domain 3) rather than after.** A clause library with real jurisdiction/industry/risk tagging is valuable on its own (a legal team can start curating it before any contract-generation UI exists), and de-risks Authoring by giving it real content to assemble from on day one instead of a chicken-and-egg empty library. 5. **Version-identity vs. delivery-package identity — don't conflate them.** This engagement's own SqlWorkbench work distinguishes "which package delivered this" from "what content-version is this" (`RELEASEVERSION` + chain-supersession on `UpgradePackage`). CLM's own document versions should carry a similar, independent content-version identity distinct from whatever authoring/publish workflow instance produced them — useful later for the AI/analytics layer's "compare this contract against our standard template version 3" kind of query. 6. **Plan the e-signature integration's audit trail before picking a vendor.** Whichever e-signature provider is chosen (DocuSign, Adobe Sign, or another), decide up front whether CLM stores just a reference to the provider's own signed-document/audit-trail, or pulls and stores the provider's evidence package into `TATTACHMENT` at completion time (recommended — providers' own retention/audit-log guarantees vary and aren't fully in GB5's control; a self-contained copy is safer for the "prove what was agreed" requirement that motivated this whole effort). 7. **Give the AI layer a narrow, well-scoped first task, not the whole list in §5.2 at once.** Contract extraction (parties/dates/value/terms from an uploaded document) is probably the single highest-value, lowest-risk starting point — it has a clear success criterion (does the extracted data match the document), doesn't require live negotiation data, and directly feeds domain-2 classification and domain-13 commercial tracking once it works. 8. **Consider a lightweight "counterparty portal" question early, even if not built in Phase 0-2.** Vendor/partner-facing acceptance (domain 9, and eventually negotiation in domain 6) implies an external party needs *some* way to view and respond to a contract — whether that's a DXP-hosted vendor-portal extension, a Partner-portal extension, or a standalone CLM external surface is an architecture decision with real security implications (external identity, rate-limiting, document-scoped access) and is worth deciding before Phase 1's Review/Collaboration domain gets built in a way that assumes only internal users participate. 9. **Test strategy**: mirror this engagement's own established conventions — xUnit + Moq for BLL unit tests (guard clauses, state-machine transitions, immutability-once-Published), a real in-memory-SQLite pass for anything with nontrivial SQL logic (the DataSync engine's own hidden bugs were only found this way), and defer live/browser verification explicitly rather than skipping it silently. --- ## 10. Open questions for the CLM session to resolve at kickoff - Exact `CLM*` table-prefix convention and full schema for domains 1-4 (this brief names the shape, not the columns). - Whether `WorkFlowEngine` or the `ChangeRequest` pattern is the final answer for domain 8 — recommend `ChangeRequest`-style per §9 point 2, but not yet decided for CLM specifically. - DMS retention-gap decision (§9 point 3). - E-signature vendor selection and evidence-storage model (§9 point 6). - Counterparty-portal architecture (§9 point 8) — needed before domain 6 (Negotiation) can involve an external party at all. - Which team/session builds the Procurement extension's own tender/RFQ/bid transactional schema (PCLM-11) — this is large enough it may deserve its own sub-thread rather than being CLM's own first deliverable. --- *Source conversation: the Entitlement engagement's master tracker, §50 ("Legal Terms/Agreement Acceptance") and §51 ("CLM — scoped to its own future session"). This brief is the "full vision" §51.3 refers to as deferred rather than reproduced in that tracker.*