API/UI versioning inadequate for exports

Hi ​@sata,

Thank you for your thoughtful post and idea in our Lucid Community! The "Alice and Bob" scenario you described perfectly illustrates the technical challenge of maintaining a single source of truth for regulatory exports.

Unfortunately, marrying named revisions from the UI with numeric versions in the API isn’t currently supported in Lucid, but we’re very interested in your feedback and committed to continually improving our products. If you’re willing to share, we’d love to hear more details about your use case or what you’d like to see in this experience within this thread. This thread is visible to others within the Product Feedback section of the community - from here, they can upvote it and add details of their own.

We encourage anyone else who’s interested in this to upvote this post and share any additional details about your use case or what you’d like to see in this experience. For more information about how we manage feedback in this community, please take a look at this post:

Hi ​@alison cheney 

The use case is as mentioned for regulatory purpose in UK jurisdiction for finance industry. We need to demonstrate how our diagrams are approved by a CAB group, stored via version control in a immutable way and when exported (i.e. embedded in documentation), being able to reference back to which exact version the diagram consist of. I don’t believe this storage needs to sit with lucid but lucid should aim to make it easier for people to follow regulatory needs. Currently, one  way to reconcile this in automated way is to do perceptual hash matching of the images via Magick library to ensure what we have in our version controlled system matches the latest version in lucid before introducing a new change on top of it. 

If Lucid offered immutable named versions (i.e. they can’t be reused once created), and such named versions were visible through API, this reconciliation would be much easier. If any discrepancy is found, i.e. an unwanted changed was introduced in Lucid, the ability to revert the document to the last immutable named version would be easily done to ensure a clean state.

I can see FedRAMP have similar requirements via NIST SP 800-53:

• CM-3 (Configuration Change Control) — requires documenting change decisions, reviewing proposed changes for security/privacy impact, implementing changes through a Change Advisory Board, and retaining records of configuration-controlled changes for a defined period.
• CM-3(1) — mandates automated documentation of all proposed and implemented changes with notifications to approval authorities.
• CM-5(1) — requires automated audit records of enforcement actions to support after-the-fact verification of authorization and detection of unauthorized changes.

I can see Lucid is now authorized for FedRAMP, perhaps this is worth looking into, how regulatory needs are met for public sector in the US as well.

Hi ​@sata,

Thank you so much for providing this additional detail. This level of context regarding regulatory requirements, specific compliance frameworks like NIST, and your current technical workaround is incredibly helpful for our product team as they review and prioritize these requests.

We encourage anyone else who is interested in this functionality to upvote this post and share more about your own use cases or what you’d like to see in this experience!