Skip to content

Edit and subscribe to well updates

Bounded Workspace pilot · 24 September 2026. Save a SQL-well edit, retain its original input, then offer the result to colleagues. A recipient can subscribe once and choose when updates reach their private Workspace working copy.

A deployment administrator must configure a supported SQLite/PostgreSQL connection with explicit retention, redistribution and recipient policy. The author needs project administration and their own source access. The recipient needs project membership and permission to read the shared version; no borrowed SQL credentials are used.

  1. In Data, open the SQL wells, edit a well, create a draft and save changes.
  2. In Shared versions, start a capture and select the saved edit. Its exact original input is included automatically. Exact draft IDs and generations are available under Technical details.
  3. Supply a name, intended use and permitted recipients. Review is optional. If requested, approval must happen before the shared version can be offered.
  4. In Updates, create an update, choose the shared version and a meaningful name.
  5. To publish a later version to that stream, save/capture another edit of the same source. Choose Offer another version, review and confirm. Before you confirm, the review says how many people will be told (2 people will be told.), which subscriptions take each new version by themselves, and how many people who take the update may not see this version; you confirm that last group explicitly.

A stream contains explicit frozen versions. Choosing Group does not share live personal group membership. Original inputs and other selected package assets remain inspectable in Shared versions. Each consumer version supports one edited SQL-well result, with at most 200 wells. Larger results remain exportable.

Open an update and Subscribe to updates. Subscribe once: a newer version then waits for you and reaches your working copy only when you choose Get, in the update itself or in the Updates list at the top of the project. Keeps this version until you change it holds your current version and still lists newer ones. Nothing is applied for you automatically, and nothing checks on a timer while a page is open: the project checks when you open it and when you choose Check for updates. Get all takes every listed version that can be taken now; versions blocked by your working edits, or not yet available, are listed apart and are not included.

After a Get, the item is listed under Taken recently with Go back to version N (for a shared update) or Go back to the version before (for a source held at a version; only a project administrator can choose it). Going back is one step: it restores the version your last Get replaced and lists the newer one again, so you can take it later. A source that keeps only its newest version says so instead: This source keeps only its newest version, so there is no going back to the version before. If a copy has edits, going back is refused until you open it and decide; if someone changed the item since you looked, nothing is changed and you are told what it is at now.

The status rows have different meanings:

StatusMeaning
AvailableThe publisher offered this snapshot version.
ApprovedSomeone approved that exact snapshot for its stated purpose.
DeliveredThe browser acknowledged receiving a verified preview.
AppliedYour durable Workspace working-copy version advanced.

Applying does not write upstream or prove that another application used the data. Select Approved releases only when unreviewed snapshots are unsuitable for your work. Requesting review pauses a snapshot until approval; withdrawal blocks future delivery.

Edit values in My working copy and save them privately. Both unsaved and saved edits block Get for that copy. Discard working edits explicitly removes them before an update can be applied. These private edits cannot yet be published onward.

Zero is a value; NULL is missing; empty text is a separate SQL value. Text inputs can be empty; use Set missing for NULL. Blank numeric input means missing. No gap is filled with zero and no interpolation or CRS/unit conversion happens. IDs, units, CRS and depth context stay protected. Original SQL scalar encodings and unmapped columns remain in the retained input; the derived result declares its projection losses.

Saved edits and applied versions survive gateway restart. Unsaved edits survive a session-expiry/sign-in cycle in the same loaded tab and account, but not a browser reload after ignoring the warning. Save before leaving. A conflicting edit from another tab requires reload/review or explicit discard, never silent rebasing.

If access is revoked, retained content is hidden. Restore permission or explicitly discard and unsubscribe. Previously exported copies cannot be recalled. If a source changes before capture, start a draft from its new verified revision. Retrying the same snapshot offer never creates a duplicate version.

Qualification used two synthetic wells with distinct IDs but the same name. The first had depth 0 and a NULL operator; the second had NULL depth and empty operator text. The author changed the first depth to 12.25, then 20 and 30. A second browser account without a source principal tested review, pin, follow, dirty protection, session recovery and approval. Server tests additionally cover non-admin recipients, revocation, corruption, concurrent offers, stale generations, rollback and backup/restart.

No offline push, generic SQL console, external application delivery or OSDU writeback is claimed. See the API contract and current availability.