Goal
Use AI to suggest fields, recipient roles/associations and related document-preparation information without creating a second LibreSign field model or allowing AI to persist unreviewed workflow changes.
Existing domain dependency
The field/domain foundation is tracked by #8264.
This epic must consume the field identity, type, placement, values/validation, recipient association and API contracts established there.
Visible signature fields remain optional as defined by the product behavior tracked in #8321. AI must not infer that every signer requires a visible field.
Existing template/reuse requirements such as #5628 should be considered where suggestions are reused across document workflows.
Intended assistance
Potential suggestions include:
- signature and initials fields;
- name/date/email/text/checkbox fields supported by the field domain;
- likely recipient role/association;
- reusable role labels;
- signing-order suggestions where a product workflow exists to consume them.
AI suggestions are proposals. Normal LibreSign validation, user review and explicit application remain mandatory.
Security and correctness
- Never let model output define field validation rules outside the established domain.
- Validate coordinates/types/recipient references before presenting or applying suggestions.
- Do not create unsupported field types.
- Do not create recipient identities or send requests without normal workflow confirmation.
- Treat document content and model output as untrusted.
- Preserve access control and document ownership rules.
UX and prototyping
Before implementation, prototype how suggestions are reviewed in the existing document preparation/editor flow.
Evaluate:
- distinguish suggested versus existing fields;
- accept/reject individual suggestions;
- bulk review only where it remains understandable;
- confidence/provenance only when meaningful and supported;
- correction without fighting the AI;
- no implication that a missing visible field is an error.
Research public field-detection/recipient-detection flows from signing products where useful, but align the final interaction with LibreSign and the field editor.
Documentation
Document AI-assisted field preparation as an extension of the normal fields workflow. Do not duplicate the field model documentation. Explain policy prerequisites, review/apply behavior, supported suggestion types and limitations.
Planning gate
Do not create the full implementation breakdown until the relevant #8264 contracts are stable enough to consume and the AI foundation handoff has been completed.
Before decomposition, review this epic against the implemented field domain/API and AI capability contracts.
Non-goals
Done when
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 both the completed AI foundation and the final field/domain contracts from #8264. 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.
Goal
Use AI to suggest fields, recipient roles/associations and related document-preparation information without creating a second LibreSign field model or allowing AI to persist unreviewed workflow changes.
Existing domain dependency
The field/domain foundation is tracked by #8264.
This epic must consume the field identity, type, placement, values/validation, recipient association and API contracts established there.
Visible signature fields remain optional as defined by the product behavior tracked in #8321. AI must not infer that every signer requires a visible field.
Existing template/reuse requirements such as #5628 should be considered where suggestions are reused across document workflows.
Intended assistance
Potential suggestions include:
AI suggestions are proposals. Normal LibreSign validation, user review and explicit application remain mandatory.
Security and correctness
UX and prototyping
Before implementation, prototype how suggestions are reviewed in the existing document preparation/editor flow.
Evaluate:
Research public field-detection/recipient-detection flows from signing products where useful, but align the final interaction with LibreSign and the field editor.
Documentation
Document AI-assisted field preparation as an extension of the normal fields workflow. Do not duplicate the field model documentation. Explain policy prerequisites, review/apply behavior, supported suggestion types and limitations.
Planning gate
Do not create the full implementation breakdown until the relevant #8264 contracts are stable enough to consume and the AI foundation handoff has been completed.
Before decomposition, review this epic against the implemented field domain/API and AI capability contracts.
Non-goals
Done when
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 both the completed AI foundation and the final field/domain contracts from #8264. 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.