Contracts that sign themselves — and then live in the same audit log.

The wedge

Every SaaS CLM sells you the workflow — a template library, a signing surface, a renewal calendar — and then leaves the counterparty as a name in a field. Odexy Contracts ties the counterparty to the actual customer record. The deal you signed on Tuesday is the customer you invoice on Wednesday, and the signature, the deal and the invoice all appear on one trail.

What ships today

• Template library — reusable body + party-role placeholders + counterparty-facing info-request forms. Version-controlled; a change is a NEW version, not an edit.
• Party invariants — a contract is frozen text plus people who bound themselves to it. Post-signature edits create a new instrument that references the old one; signed text never mutates.
• Magic-link signing — no counterparty accounts required. Bearer tokens are short-lived, one-scope-per-signer, hashed at rest. Internal signers get an in-app path (never a magic link for accounts you own).
• Info requests — before the send, request missing legal-identifier data (tax ID, VAT number, registration number) via a public form. Missing values render as [not provided] placeholders and the placeholder gate refuses to send until they're filled.
• Obligations extractor — the AI reads a signed contract and drops due-date rows into contract_obligations. Renewal windows, notice-period reminders, and payment obligations become calendar events + email nudges.
• Country-aware legal fields — governing law, jurisdiction, VAT/registration/EIN placeholders resolve per counterparty country via the same legalFieldsForCountry catalogue payroll uses.
• Signed-PDF storage — every executed contract ships to Storage with the full audit chain hashed into the PDF metadata. ESIGN §101(e) + UETA §12 retention friendly.

How it integrates

• CRM — counterparties are crm_companies rows. The same "who's on this account" roster drives the contract signer list.
• Sales — a signed contract can trigger sales.invoice.create (auto-invoice on sign — a subscriber pattern, opt-in per template).
• HRM — offer letters, joining letters, NDAs share the contract engine. Recruitment's "recruit" flow drops the candidate into a contract in draft with the offer template pre-populated.
• Storage — every signed PDF + attachment through storage.object.put_url with purpose: 'contract_signed'. Never inline in the row.
• Automation — contract lifecycle events (.sent, .signed, .declined, .expiring, .renewal_upcoming) register as automation triggers.

How the AI helps

• "Draft a mutual NDA for BigCo based on our standard template; the counterparty is in California so use the CA jurisdiction clause."
• "Show every contract with a renewal in the next 60 days that hasn't had counterparty contact in 90 days."
• "Extract the payment-obligation timeline from the MSA I just signed."
• "This counterparty asked for a change to the indemnity clause — draft a redline against our v3 template and route it to legal."

Every AI-authored draft goes through the same contracts.contract.revise action a human uses; the AI inherits your permissions. Signing itself is never AI-actioned — humans sign contracts.

Built for scale

• Approval chains — per-template approver assignment. Multi-reviewer voting via meta.requiredApprovals.
• Version diff — v3-vs-v7 side-by-side, redline-style. Every version snapshot preserved with the actor + timestamp who authored it.
• Public signing portals — dark-mode-friendly, mobile-first, one-page-per-signer. HTTPS + HMAC-signed magic links; token replay refused.
• Audit trail — every read + click + signature attempt on the public portal logs with IP + user-agent + timestamp for evidence-in-court retention.
• Multi-language — templates carry language per version. Counterparties in Spanish get a Spanish signing portal.