Vault Check-In should be unconditional and atomic

[Dan_Margulius]

Hello 

The core principal of the idea is that Check-In must never fail. Enforcement moves after Check-In.

Vault currently violates a foundational rule of transactional systems, 
It attempts to judge validity before it records existence.

By design, Vault should not decide whether engineering work exists.
Its first responsibility is to capture reality, not to approve it.

Check in must be an unconditional, atomic transaction that always creates a version.
Lifecycle rules, permissions, references, and automations must not block data capture.

Restrictions belong to promotion and release, not to version creation.

Vault should flag invalid versions instead of rejecting them:

• lifecycle non-compliant

• broken references

• failed jobs

Jobs may fail. Files must not.

Autodesk positions Vault as a single source of truth, yet today it behaves like a gatekeeper.
A source of truth records first, judgment comes later.

Vault should act as a ledger, not a judge.

Thanks

Dan

@ihayesjr 

@Richard.Rankin 

[ihayesjr]

Thank you for posting your Idea.

However, I do disagree with your statement. Vault needs to control correct information, which means it will judge if that information should be allowed in Vault.

[Dan_Margulius]

Hi

Thanks for the response.

I think we’re actually very close, even if we’re looking at it from different angles.

I fully agree that Vault must control correctness.

My point is about where that control is applied. From my experience, a system of record works best when it first captures the work as it exists, and then applies governance to decide what can move forward.

In that sense, Check In is about recording engineering work, while lifecycle, promotion, and release are the right places to enforce correctness and compliance.

Blocking Check In doesn’t protect quality as much as it breaks traceability and trust in the system.

I appreciate the discussion, this distinction is exactly why the topic matters.

KR
Dan