Compliance and Legal Posture

KarmaFlow'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 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'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'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 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 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 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 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 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