Feature request: Native knowledge editing, review, releases, and version-aware references

[ambzhang]

Hi Utopia team,
We are evaluating Utopia v0.1.0-rc9 for an internal knowledge base containing business rules, functional specifications, technical documentation, and screenshots.
We understand that Utopia already provides document ingestion, a version ledger, retained-original retrieval, knowledge base permissions, and search/MCP capabilities. We would like to discuss extending these foundations into a native knowledge maintenance workflow.
The following capabilities would be valuable:

1. Native document editing and revision management
   • Create and edit Markdown documents in the UI, with draft saving and preview.
   • View revision history, including the author, timestamp, and change description.
   • Compare revisions and restore historical content as a new revision.
   • Detect concurrent edits to prevent silently overwriting another user's changes.
2. Content review and knowledge base releases
   • Group related document and attachment changes into a single reviewable change set.
   • Bind approval to specific revisions; subsequent edits should require review again.
   • Keep drafts separate from published content.
   • Create immutable, named releases and activate them only after required processing and indexing succeed.
   • Ensure the web UI, search, chat, and MCP consistently consume the active published release.
3. Explicit document–image and attachment relationships
   • Associate screenshots and attachments with specific documents or sections.
   • Preview and access associated images from knowledge pages and search results.
   • Preserve attachment revisions so historical documents continue to reference the correct assets.
   • Expose authorized asset references or retrieval tools for external MCP clients.
4. Version-aware citations
   • Associate citations with the document revision and knowledge base release used to generate the answer.
   • Allow users to open the original supporting content after the document has changed, subject to current access permissions.
   • Clearly indicate when historical content is unavailable.
5. Portable export and processing visibility
   • Export Markdown, attachments, metadata, and release manifests in a documented format.
   • Show separate processing states for parsing, indexing, embedding, and extraction, with actionable errors and retry controls.
     A phased implementation would be welcome. Document editing and revision history could come first, followed by review workflows, a single active published release, and richer historical retrieval.
     Could you clarify which capabilities are already supported, which are on the roadmap, and whether community contributions would be welcome? We would also be happy to split this proposal into smaller feature requests.
     Thank you!