The content lifecycle
Perpetual is built around a content management system that enables you to confidently apply complex changes to live content. Content autosaves as you type. Your edits collect in a changeset. Nothing reaches running configuration until you commit it. The changeset gives you a place to make required edits across related content resources and test those edits before applying them to running configuration. Perpetual's changesets will feel familiar if you have used a version control system.
A changeset isolates your work until you commit
A changeset holds one staged edit per content resource: a creation, update, or deletion. Perpetual creates a changeset when you begin editing and none is active.
Until you commit, a staged edit does not become the resource’s committed version or change any running materialization. Autosave runs basic validation on each resource, but full changeset validation checks dependencies across all staged edits. You can prepare every related edit before that check has to pass.
The commit boundary still lets you go beyond basic validation while you work. A staged query shows what the changed logic produces, and running the full changeset check without committing reports what would fail in the current batch.
The Simba agent works within the same boundary. Simba opens a changeset and stages its content edits there for you to review and commit. The agent's edits do not affect the running system until you commit, and you can validate and test them as you would edits you made yourself.
Check your change before it goes live
A clean validation means the changeset passes the full check in its present state. Testing answers the separate question of whether the change behaves as intended. You can test staged query logic against a known outcome by running it over a period containing a known incident or a quiet stretch that should return nothing.
Perpetual makes a test reflect uncommitted query logic by substituting the staged definitions it can evaluate into the test query. The query evaluates those definitions inline instead of using their deployed versions. Every substituted definition in the dependency chain adds work to the test.
A long dependency chain can make a downstream test too slow. You can commit the upstream work first and wait for its result to reach the running system. The downstream test then reads that result instead of recomputing the dependency inline. Once testing establishes how the staged logic behaves, proposing the changeset brings another reader into the decision.
Proposing opens a changeset for review
A changeset moves among four states: draft, proposed, committed, and declined.
A draft you open is private. Proposing makes the complete changeset available to other organization members who can read every Space it touches, while the changeset remains editable. A second reader who knows the data can catch a behavioral problem that validation cannot before the change affects anything running.
The person who proposed the changeset can return it to draft. Someone with write access to every affected Space can instead decline it, ending the changeset without applying its changes. These transitions govern who can review and end the work. Review and resolution stay inside the changeset.
Review remains optional because you can also commit directly from draft.
Committing atomically applies staged changes
Perpetual applies a changeset only when it can apply the complete batch, recording every staged change in committed content in one transaction. Each changed resource advances to a new version that later edits use as its base, and history preserves the change and its committer.
Perpetual runs the full changeset check before starting the transaction. If the changeset's base has moved, Perpetual first attempts to merge the newer committed work into it. Only unresolved conflicts stop the commit. After the commit, a background job attempts to rebase the other open changesets. When their work merges cleanly, the rebase preserves those changesets and their owners do not have to rebuild them.
The transaction ends after Perpetual records the complete change in committed content. The completed commit remains in history while the running system may still use an earlier version.
Committed changes reach the running system asynchronously
After commit, Perpetual starts applying the committed versions to the running system. Perpetual leaves the previously deployed dataset version queryable until it successfully applies an update. A new dataset becomes queryable only after Perpetual successfully applies its first version.
Perpetual tracks each committed dataset version through that work and reports whether the application attempt succeeded or failed. A failed attempt leaves committed and running versions different until recovery. A first deployment remains unavailable until it succeeds, while an update continues to answer queries through its previous version. Even a successful application can reveal behavior that you need to reverse.
A rollback is another staged change
You roll back a query resource that exposes version history by staging an earlier query as a new change. Like other staged work, you can test the rollback before commit. The full changeset check must also pass. Only query resources with version history and diffs support this rollback path.