Add AI-assisted document understanding #9050

Goal

Help authorized LibreSign users/signers inspect and understand a document during a signing workflow through optional AI-assisted summaries, key information and document questions.

The source document remains authoritative. AI output is assistance and may be incomplete or incorrect.

Intended capabilities

Potential product slices include:

• document summary;
• key terms/information extraction;
• questions and answers about the current document;
• navigation/provenance back to supporting document locations when the provider/platform can supply reliable source information.

Do not assume every capability must ship together.

Product and research basis

Public signing/document products such as Adobe Acrobat/Acrobat Sign and Docusign use summaries, agreement questions and source-linked navigation to reduce the effort required to inspect agreements.

Research such as CUAD and later contract-analysis benchmarks supports the usefulness of clause/information extraction while also showing that model outputs are probabilistic and can miss or misinterpret content.

This epic therefore treats AI as an inspection/navigation aid, not as legal authority.

Research references

Current public references supporting the product-research statements above:

• Adobe Acrobat AI Assistant summaries and source navigation: https://helpx.adobe.com/acrobat/desktop/use-acrobat-ai/generative-ai-features/generate-summary.html
• Adobe Acrobat AI Assistant questions and source citations: https://helpx.adobe.com/acrobat/desktop/use-acrobat-ai/generative-ai-features/ai-get-answers.html
• Docusign AI-Assisted Agreement Summaries and Q&A: https://www.docusign.com/learn/how-to-summarize-a-contract-with-docusign-ai
• CUAD expert-annotated contract-review dataset: https://arxiv.org/abs/2103.06268

These references establish product/research precedent only. They do not define LibreSign requirements by themselves.

Architectural constraints

Use the shared Nextcloud Task Processing integration.

For document Q&A, prefer supported file/multimodal task capabilities when available. Do not create a LibreSign-specific RAG/vector database merely because simple chat exists.

Cross-document retrieval belongs to the separate Context Chat integration.

Policy and authorization

Every operation is subject to the effective LibreSign AI policy.

Policy resolution determines whether the current actor may send document content for AI processing and which capabilities are allowed. Public/external signer behavior must follow the implemented policy/authorization contract rather than a frontend-only rule.

Security

• Document content is untrusted and may contain prompt injection.
• Treat instructions found in the document as document data, not system authority.
• Keep authorization and domain decisions outside the model.
• Validate structured output.
• Minimize data sent to providers.
• Do not expose hidden metadata or documents outside the actor's normal access.
• Do not ask the model to decide whether a person should sign or whether a contract is legally safe.

UX and prototyping

Prototype the signer/requester experience before implementation when the interaction is not already established.

The proposal should evaluate:

• placement relative to the PDF and primary signing action;
• summary readability;
• suggested questions;
• loading/failure states;
• visibility of AI limitations;
• source/provenance navigation;
• keeping the normal PDF inspection and signing flow primary.

Use Nextcloud-native components where suitable and compare public Adobe/Docusign interaction patterns as references, not designs to copy.

Documentation

Document:

• what summary/Q&A can and cannot do;
• the authoritative role of the original document;
• policy/admin prerequisites;
• possible provider processing;
• source/provenance behavior where supported;
• troubleshooting and feature availability.

Provide contextual help from the document-understanding UI when appropriate.

Planning gate

Do not fully decompose this epic until the AI foundation has established the actual Task Processing, policy, security and test contracts.

After that handoff, choose the smallest useful initial slice and create focused implementation issues. Do not assume summary, Q&A and provenance have the same technical prerequisites.

Non-goals

• legal advice;
• recommending whether to sign;
• replacing the original document;
• building a separate LibreSign AI provider stack;
• building cross-document RAG in this epic.

Done when

• Implemented document-understanding capabilities are gated by capability and policy.
• The source document remains clearly authoritative.
• Prompt-injection and authorization boundaries are tested.
• Provenance/source navigation is provided where the platform can support it reliably.
• The UI has been prototyped/reviewed for the signing context.
• User-facing documentation explains use, limitations and configuration.

Decomposition gate

This epic is intentionally blocked by prerequisite work tracked through GitHub's native dependency relationships.

Do not create a full implementation backlog for this epic while its blockers are open.

When all blockers are complete, review this epic against the contracts, tests, documentation and constraints actually produced by the blocking work. Update the goal, scope, architecture, UX assumptions, security requirements, testing strategy and documentation requirements where needed. Only then create focused implementation sub-issues.

The current description preserves product intent and research; it is not authorization to implement around unfinished prerequisite contracts.