Versioned State

The Foresight Development Kit is built on a versioned object system where every state change is tracked and persistent.

Versioned Objects

Every object in a project is versioned. Instead of overwriting data, every change creates a new, immutable version of that object.

When you modify data, you are working in a local workspace. This allows you to experiment, undo, and refine your work before synchronizing your changes with the project’s authoritative state.

To learn more about implementing your own versioned objects, see Objects.

Local Undo/Redo vs. Committed Versions

The Foresight Development Kit distinguishes between local session history and the project’s global version history:

• Local Undo/Redo: As you work within a tool or session, every Statement you execute is tracked in a local undo stack. This allows for immediate, granular reversals of your recent actions.
• Committed Versions: For projects stored in the cloud, when you “check in” or commit your changes, those local modifications are flattened into a new authoritative version in the project’s global history. Because the project is versioned at the object level rather than the project level, this enables extremely granular updates and seamless collaboration. This does not apply to local files, which are simply saved rather than committed.

Both systems are built on the same underlying architecture and use the same backwards-compatibility and migration tooling. This means a plugin developer only needs to define how an object is versioned once, and it automatically supports both local undo/redo and collaborative editing.

Workflow

A typical user journey through a versioned project follows a predictable sequence:

1. Exploration: Data is streamed on-demand, allowing users to view the project state. They can use the timeline to scrub through history to see how the project has changed over time.
2. Check Out: To start editing, a user checks out a subset of objects. This signals that the data is being modified in a local workspace.
3. Check in: Once finished with a cloud project, the user checks their changes back in. A new authoritative project version is created on the server, making the changes persistent and visible to others.

Object-Granular Versioning

The Foresight Development Kit uses a “Last Check-in Wins” strategy at the Object level for cloud projects. This means that if two users edit the same object, the last one to check in will define the current state of that object.

Because the SDK is built on versioned objects, no data is ever lost. If User B overwrites User A’s changes to a specific node, User A’s work still exists in the project’s global history. At any time, a user can navigate back to a previous project version to recover data or compare differences.

Digital Twin Server

The Foresight Development Kit is designed for flexibility. A server using the cloud side of versioned objects (the Digital Twin server) does not require any updates when custom objects are modified or added. In fact, a single server can host projects with wildly different object schemas simultaneously without any changes to the server software itself.

This decoupling ensures that the infrastructure remains stable and agnostic to the specific business logic of individual plugins and projects.