Governance & security — Yugmir Kinetic

Staged rollout and rollback

Users are assigned to a channel — Production or Beta — by a file on your master drive. Each machine only ever mirrors its own channel, so a Beta release is invisible to everyone else.

Promoting Beta to Production snapshots the current Production tree first. Rollback restores a snapshot. Both actions are recorded in the audit log with the operator’s name.

Backward compatible. A master drive with no channel folders is synced whole, exactly as before. You can adopt channels later without restructuring anything.

Crash isolation and Safe Mode

A tool that throws is caught before it reaches Revit’s error handling. The user gets a plain-language message confirming their model is unaffected, and the failure is logged with full detail for you.

Three failures within 24 hours and the tool quarantines itself: the button greys out with an explanatory tooltip and refuses to run. A clean window clears the count automatically, so a one-off glitch doesn’t bench a tool permanently.

Tools in a developer’s local sandbox show the full stack and are never benched — authors need the real error
Holding Shift during Revit start loads core only, and offers to reset quarantined tools
Crash counts are visible to administrators, so you fix the tool that’s actually failing

Role-based access

A roster file on the master drive maps roles to Windows usernames or Active Directory groups. A tool folder declares the role it requires. Users without that role never load the tool — it isn’t hidden on the ribbon, it is never loaded at all.

The roster is cached locally, so access still resolves correctly when the drive is unreachable. With no roster present, behaviour is unchanged from a standard install — this is opt-in.

Revocation — the kill switch

When a tool has to stop being used immediately, you add it to a revocation list at the root of the master drive. On the next sync it greys out on every machine, with your stated reason shown to anyone who clicks it.

The list must be signed. An unsigned or altered revocation list is ignored, and the framework logs that it was rejected. This is deliberate: it means write access to the file share is not enough to disable a firm’s tooling. Revocation requires your signing key, so this feature becomes active once code signing is configured.

Audit trail

Governance actions — promotion, rollback, revocation, approval, rejection — append to a log where each entry carries a hash of the one before it. Editing or deleting an entry breaks the chain, and verification reports the first entry that no longer matches.

It records sequence, timestamp, actor and action. It is designed to answer “who changed what, and when” months later, in front of someone who is not inclined to take your word for it.

Two-person approval

Optional. When enabled, promoting to Production becomes a request: an administrator files it with a reason, and a different administrator approves it. Kinetic refuses self-approval outright. Requests, approvals and rejections all land in the audit trail.

Off by default — firms that don’t need separation of duty aren’t slowed down by it.

Tool integrity

Before a tool is loaded, Kinetic can verify it against a signed manifest covering every executable artefact in the published tree, checked against a certificate thumbprint pinned inside the framework.

Ships in warn-only mode. Out of the box, unverified tools still load and the event is written to the log — so adopting Kinetic never breaks an existing toolset on day one. Once your published tools are signed and the log is clean, an administrator switches verification to enforce, and anything not covered by a valid signature stops loading.

Telemetry and privacy

Usage data never comes to us. It is written as per-user files on your own file server, and the reporting in the product reads those files back. We have no access to it.

Consent is two-layered:

A firm-level policy file lets you set collection to optional, required or disabled for everyone
Where the policy leaves it open, each user is asked once, and can change their choice later from the ribbon
Disabled always wins. If the firm switches collection off, no user setting can turn it back on

What’s recorded is operational: which tool ran, whether it succeeded, when, on which Revit version, for which user. No model content and no drawing data.

Licensing that survives a bad connection

Kinetic activates online once. After that it holds a sealed local record and keeps working through an offline grace window — so a site office on a poor line, or an engineer working away from the network, doesn’t lose their tools because a licence server was unreachable.

Everything else — the framework, the tools, the dependencies — is installed locally. There is no runtime dependency on our infrastructure for day-to-day work.

Common questions

Does any model or project data leave our network?

No. The framework loads locally and telemetry is written to your own file server. The only outbound connection is licence activation and validation, which carries the licence key and a machine identifier — no project information.

What happens if our master drive is offline?

Kinetic keeps working from its local copy. Roles and channels resolve from cache, licensing runs on its offline grace window, and the sync simply resumes when the drive returns.

Can we run Revit 2024 and 2025 at the same time?

Yes. Kinetic supports 2019 through 2027 and is built for migration years where two versions run side by side. It never takes an exclusive lock on the shared drive.

Do our own developers have to change how they write tools?

A tool is an ordinary Revit external command. There is no registration step and no framework rebuild — a tool is a folder, and the folder name builds the ribbon. The developer guide covers the conventions.

What if we stop paying?

Your tools are your own code, sitting in ordinary folders on your own drive. Nothing about them is locked into a proprietary container by Kinetic.

Answers for the person who has to sign this off.