One DocuSign and Fund Setup Workflow
Vendor-neutral agreement execution and fund-setup workflow under One, with Nav/Connections authorization, trusted action confirmation, and e-signature provider options.
TL;DR: Vendor-neutral agreement execution and fund-setup workflow under One, combining stateful fund operations, Nav/Connections consent authorization, trusted action confirmation, and eSignature API v2.1 or DocuSign MCP provider integration.
Status as of 2026-07-24: see body.
Relations
Architecture Overview
The One DocuSign and Fund Setup Workflow defines a vendor-neutral agreement execution capability beneath a stateful Fund Operations workflow in Hussh One. It bridges investor onboarding, legal document preparation, and e-signature execution while preserving strict agent boundaries and zero-knowledge privacy guarantees.
In this architecture, One acts solely as the semantic router and user-facing intelligence layer. It explains workflow progress, gathers required inputs, and presents explicit confirmation cards. Execution authority for e-signatures remains strictly with the vendor-neutral agreement provider (AgreementExecutionProvider), which routes requests through an eSignature API v2.1 adapter or an optional UAT-gated DocuSign MCP server.
Product & Agent Ontology Boundaries
To maintain clear agent responsibilities, agreement execution and fund setup do not introduce a standalone "DocuSign Agent." Instead, tasks are delegated across specialist domains:
- One (Semantic Router): Understands user intent, initiates Fund Operations workflows, and reports real-time status.
- Fund Operations (Workflow Owner): Manages the state machine for fund creation, entity formation, and document tracking.
- Kai (Finance Specialist): Provides financial context, capital commitment parameters, and LP/GP balance data when requested.
- KYC (Identity Specialist): Supplies approved, user-consented identity and investor accreditation outputs without sharing raw documents.
- Nav & Connections (Consent & Auth): Nav manages explicit information disclosure review; Connections owns DocuSign account linkage, OAuth tokens, and revocation status.
- Generated Action Gateway: Enforces trusted confirmation, step-up authentication, and idempotent settlement before sending any binding agreement.
Vendor-Neutral Execution Capabilities
All external e-signature interactions project into stable, vendor-neutral capability interfaces rather than raw provider tool calls:
| Capability | Scope & Function | Confirmation Required |
|---|---|---|
agreements.connection.status | Check DocuSign account linkage & permission posture | No |
agreements.templates.list | List approved counsel-verified fund templates | No |
agreements.envelope.prepare_draft | Create draft envelope bound to reviewed inputs | Yes |
agreements.envelope.review | Generate sender or recipient review URL | No |
agreements.envelope.send | Dispatch reviewed, unchanged draft for signature | Yes (with Step-Up Auth) |
agreements.envelope.status | Track recipient signature and envelope progress | No |
agreements.envelope.remind | Send reminders to pending signers | Yes |
agreements.envelope.void | Void an in-flight agreement | Yes (with Step-Up Auth) |
agreements.envelope.retrieve_completed | Retrieve completed package for PKM vault storage | Yes (Disclosure Review) |
Security & Verification Laws
- Counsel Approval Gate: An LLM or agent cannot invent fund terms, substitute for counsel approval, or modify legal text. Only counsel-approved document templates with immutable hashes are executable.
- Explicit Confirmation & Step-Up Auth: Draft preparation and envelope sending are strictly separate. Sending legally binding documents requires explicit physical user confirmation and step-up authentication. Spoken or typed phrases alone cannot trigger dispatch.
- Encrypted PKM Vault Storage: Upon signature completion, final agreements and certificates of completion are retrieved, encrypted client-side, and stored in the user's PKM source vault. Telemetry retains metadata only.
- Isolated Credentials: DocuSign OAuth tokens and JWT secrets reside exclusively in the enterprise connector domain and are never exposed to agent prompts or client-side storage.