Document LibreSign AI foundation configuration, policies, and limitations

Start by reading the existing LibreSign documentation structure and the documentation contribution and screenshot rules in issue #46; use the contracts and UI behavior delivered by LibreSign/libresign#9047 as the source of truth. Fit foundation guidance into existing policy, configuration, security, and signing material, cross-reference authoritative Nextcloud provider documentation, and avoid describing roadmap features. Done means the listed administrator and user guidance is covered, documentation checks pass, and the pull request includes rendered-page screenshots.

Goal

Document the AI foundation delivered by LibreSign/libresign#9047 as product documentation for administrators and users.

This issue covers the shared prerequisites, capability availability, policy model, administrative transparency, security boundaries and limitations established by the foundation.

It does not document downstream AI features that are still only roadmap items.

Each downstream epic must document its own user-facing feature when that epic is later reviewed and decomposed.

Information architecture

Fit the foundation content into the existing LibreSign documentation structure instead of creating an isolated AI section that duplicates policy, configuration or signing concepts.

At minimum, place and cross-reference documentation for:

• Nextcloud-side AI prerequisites and configuration ownership;
• LibreSign AI capability availability;
• LibreSign AI policies and delegation;
• administrative capability/status information;
• provider/data-processing notice;
• common limitations and human-review expectations;
• troubleshooting when an expected capability is unavailable.

Prefer cross-references to existing policy, configuration and security documentation over repeating those concepts.

Do not reorganize unrelated manuals in this issue.

Administrator documentation

Explain:

• LibreSign consumes AI capabilities exposed by Nextcloud;
• provider/model/API credential configuration remains a Nextcloud responsibility;
• technical capability availability and LibreSign policy authorization are different concepts;
• how system/group/user policy delegation and customization affect AI use according to the contract established by #9047;
• what administrators can expect when a capability/provider is unavailable;
• that processing location/privacy depends on the configured Nextcloud provider unless Nextcloud exposes authoritative metadata;
• where administrators can inspect LibreSign's AI capability/policy state when the foundation UI provides that surface.

Do not present a LibreSign Ethical AI Rating or infer provider trust from provider/model names.

User-facing foundation guidance

Document only user-facing behavior that actually exists as part of the foundation.

At minimum, make clear that:

• AI-assisted output can be incomplete or incorrect;
• the source document and normal LibreSign rules remain authoritative;
• AI capability availability does not itself grant authorization;
• normal LibreSign validation/confirmation remains authoritative for state-changing operations.

Do not describe summaries, document Q&A, field suggestions, Context Chat or Context Agent as released functionality unless the corresponding downstream epic has actually shipped.

Those features belong in the documentation work of their own epics.

Security and AI literacy

Use concise product language to explain:

• documents or derived content may be processed by the AI provider configured in Nextcloud;
• AI does not decide LibreSign authorization, signature validity, certificate trust or effective policy;
• model output is assistive and may be wrong or incomplete;
• consequential actions remain subject to normal LibreSign validation and confirmation.

Avoid generic or alarmist AI disclaimers that do not help users make a concrete decision.

Contextual links from LibreSign

Coordinate with foundation UI work so relevant settings/status surfaces can link to the correct documentation page or section.

Links should be stable and contextual.

Do not create links for downstream screens that do not exist yet.

Screenshots

Follow the documentation contribution/screenshot rules tracked in #46.

For any new or materially changed rendered documentation page:

• include screenshots of the rendered page in the pull request;
• show enough surrounding context for a reviewer to inspect headings, lists, links, admonitions and layout;
• do not include credentials, personal data, private documents or customer information.

Screenshots are review evidence and do not replace source documentation or automated checks.

Maintenance and downstream handoff

Keep terminology aligned with the UI and contracts actually delivered by #9047.

When a downstream AI epic later ships:

1. document that feature in the workflow/manual where users encounter it;
2. cross-reference this foundation documentation for shared prerequisites, policies and limitations;
3. do not expand this issue retroactively into the documentation backlog for every future AI feature.

Out of scope

Do not:

• document roadmap-only downstream features as released;
• duplicate Nextcloud provider configuration instructions when an authoritative Nextcloud page can be referenced;
• invent provider trust/privacy metadata;
• write an implementation diary;
• create product behavior that is not established by #9047.

Done when

• Nextcloud-side prerequisites/configuration ownership are documented.
• LibreSign capability availability and policy behavior are documented.
• System/group/user policy behavior is explained in product terms.
• Administrative capability/status behavior delivered by #9047 is documented.
• Shared limitations and human-review expectations are documented.
• Provider configuration is correctly delegated to Nextcloud documentation.
• No unsupported Ethical AI/provider-trust claims are made.
• Roadmap-only downstream AI features are not documented as released.
• Contextual application links can target stable relevant documentation.
• Cross-references avoid duplicating existing LibreSign documentation.
• Documentation build/checks pass.
• The PR includes required screenshots of rendered documentation.