# Compliance and Legal Posture

Karmaflow.ai's e-signature implementation is built to satisfy the core requirements of the US **Electronic Signatures in Global and National Commerce Act (ESIGN)** and the **Uniform Electronic Transactions Act (UETA)**. This article explains exactly what the platform captures, what it doesn't, and what your team is responsible for.

## The Six ESIGN/UETA Pillars

### 1. Consent to Electronic Records

Before any signer can complete a signature, they must explicitly accept a consent statement disclosing that they are doing business electronically and that their electronic signature has the same legal effect as a handwritten one. Karmaflow.ai captures this consent **per signer, per session**, with:

- Timestamp (server-side, UTC)
- IP address
- User agent string
- Browser language (`Accept-Language` header)

This consent record is stored on the `documentsigningsessions` record and surfaced in the Certificate of Completion.

### 2. Intent to Sign

UETA and ESIGN require an affirmative act demonstrating intent. Karmaflow.ai's signing portal requires the signer to:

- Type their full legal name, **or**
- Draw their signature on the canvas (or both)

Then click **Sign & Submit**. That click is the unambiguous affirmative act. The submit event is recorded with timestamp, IP, and user agent on both the signing-session record and the document's audit trail.

### 3. Attribution

Attribution links a signature to a specific identifiable person. Karmaflow.ai's default attribution mechanism is:

- A unique 32-byte cryptographically random token, delivered to the signer's verified email address
- The token is hashed (SHA256) before storage — Karmaflow.ai never holds raw tokens; the plaintext token only exists in the recipient's inbox
- Each token is per-signer and single-use within an expiration window

Optional second factor: per-signer **SMS OTP** can be enabled on a Document Agent. (The schema is in place; wiring it to your existing SMS sender is a configuration step — contact support to enable it for your tenant.)

For higher-stakes signatures (large financial transactions, sensitive HR documents), consider requiring SMS OTP in addition to email delivery.

### 4. Document Integrity

Karmaflow.ai records the integrity of the final signed document in two ways:

- **SHA256 hash of the final PDF** is computed at finalization and stored on the document record (`finalPdfSha256`).
- **The pre-certificate hash is embedded into the Certificate of Completion** itself. Anyone with the signed PDF can recompute the hash and compare; any modification to the bytes makes the embedded reference no longer match a fresh computation.

The Certificate page also lists every audit event with its timestamp and IP, providing a chain-of-custody record that lives inside the document itself.

### 5. Record Retention

All document assets are stored in your tenant's namespaced prefix in Google Cloud Storage:

- Pre-signing PDF: `{tenantId}/documents/{documentId}/v{N}/document.pdf`
- DOCX: `{tenantId}/documents/{documentId}/v{N}/document.docx`
- HTML snapshot: `{tenantId}/documents/{documentId}/v{N}/document.html`
- Signed PDF (with certificate): `{tenantId}/documents/{documentId}/v{N}/document-signed.pdf`
- Drawn signature images: `{tenantId}/documents/{documentId}/signatures/{signerId}-{timestamp}.png`

These assets are retained indefinitely by default. Your tenant administrator can configure GCS object retention policies for additional compliance requirements (immutability, time-based holds, etc.).

### 6. Copy Delivery

On final signature, Karmaflow.ai automatically emails a copy of the signed PDF to every signer **and** the document's creator. This satisfies the ESIGN requirement that signers receive a copy of the executed document. The audit trail records the delivery event.

## What the Audit Trail Captures

Every meaningful event on a document is appended (never modified) to the `auditTrail` array on the document record, with these fields:

- `ts` — timestamp (UTC)
- `event` — event name (e.g., `created`, `approved`, `invite_sent`, `signed`, `finalized`)
- `actor` — user ID, signer email, or actor type label
- `actorType` — one of `user`, `signer`, `system`, `ai`
- `ip` — IP address of the actor when known
- `ua` — user agent of the actor when known
- `meta` — event-specific structured data

A parallel record lives on each `documentsigningsessions` document, tracking that signer's specific journey (`sent`, `opened`, `viewed`, `consent_accepted`, `signed`, `declined`, etc.).

## What Karmaflow.ai Does NOT Do (Your Responsibility)

- **Specialized industry compliance.** The platform implements ESIGN/UETA general requirements. Industry-specific signature requirements (21 CFR Part 11 for FDA-regulated submissions, eIDAS Advanced/Qualified signatures for EU regulated transactions, etc.) are not provided out of the box — consult counsel and contact support if you need them.
- **Legal advice.** The shipped document templates are practical starting points. They are not a substitute for review by qualified legal counsel, especially for high-value transactions, jurisdictional sensitivity, or specialized industries.
- **Mandatory paper alternative.** ESIGN gives consumers (in B2C contexts) the right to receive paper copies on request. If your workflow includes consumer signers, ensure your business process accommodates that request when received.
- **Record disposal.** If your retention policy requires document deletion at a specific time, that policy lives at your GCS bucket level — Karmaflow.ai does not auto-delete signed documents.

## Recommended Practices

- **Review presets with counsel** before relying on them in customer-facing transactions
- **Capture business context** in the document agent's prompt — the more specific the prompt, the more accurate and on-brand the output
- **Enable SMS OTP** for any document over a threshold (e.g., $25,000 contract value, employment offers, financial agreements) — contact support to wire your SMS sender
- **Lock down hardcoded legal sections** — keep governing law, severability, and limitation of liability as hardcoded sections so the AI cannot accidentally rewrite them
- **Periodically verify integrity hashes** of high-value signed documents by recomputing SHA256 and comparing against `finalPdfSha256`
- **Train internal users** on the difference between an AI-generated draft (subject to review and edit) and an approved document (locked from further AI changes)

## Where to Find Things

- **Document audit trail** — `GET /internal/document/documents/:id` includes the full `auditTrail` array
- **Signing session events** — Stored on `documentsigningsessions` records keyed by `documentId` + `signerId`
- **Integrity hash** — `finalPdfSha256` field on the document record after finalization
- **Cloud storage paths** — `renderedAssets.pdfGcsPath`, `signedPdfGcsPath`, etc. on the document record
- **Tenant LLM usage tracking** — Every generation logs to the tenant's `LlmUsage` collection under feature `document_agent`