TenaVault
Book a demo
Product · Changes & seals

Nothing reaches production without a seal.

Every write to a governed key can go through a change request — diffed, checked, approved by someone who isn’t the proposer, and only then merged.

Propose, approve, merge — a real diff, not a guess

A change request captures exactly what's changing: the key or document, the scope it targets, the old value, and the new one — shown as a real before/after, the same way a code review shows a diff. Nothing is applied the moment it's proposed; it sits open until it collects the approvals your org requires.

Approval policy, not an honor system

Orgs can define a sequential approval chain — specific people, or anyone holding a given role, in a fixed order. A proposer can never approve their own change request, full stop, regardless of role. If no policy is configured, a single approver or admin seal is enough — but that's a default, not a ceiling.

The seal is the deploy

Once a change request has every required approval, merging it is the only thing that actually writes the new value — and merging is blocked outright if the target environment is frozen. There's no separate "now go apply it somewhere else" step to forget.

Attribution that matches git blame, not click history

A merged change is attributed to the person who proposed it — the author of the content — not whoever happened to click merge last. Who approved and who merged are their own separate, fully logged events, so accountability for the review process is never lost either; it's just not conflated with authorship of the value itself.

See it on your config
30 minutes. Your messiest tenant. Real answers.
Book a demo
RegistryLedger & time travelPromotions & freeze