Change Log

One consolidated history across the three artifact libraries — entities, briefs, and skills — plus domains. Under History → Change Log on the Studio rail.

What it shows

Every event is one row: when, which artifact, its library, what happened, the version, the comment, and who did it. Six events exist:

EventMeaning
CreatedThe artifact came into existence
ActivatedA version was published — this is what changed what agents receive
Rolled backThe active pointer moved back to an earlier version
DeactivatedWithdrawn from service — the pointer cleared, versions kept
UpdatedA domain changed. Domains aren’t versioned, so they never activate
DeletedThe artifact is gone — this row is the history that survives it

The comment column is the point of the page. Activation requires a comment, and this is where those comments pay off: the log reads as a narrative of why the configuration is the way it is, written by the people who changed it at the moment they changed it. An artifact drafted by the admin agent and activated by a person reads here like any other activation — the comment is the human’s.

Filter by library, search across artifact, comment, and author. Click an artifact to open it — the entity in its builder, a brief or skill on its page, a domain on the Domains page.

Domain events

A domain has no activation, so its comment column records what the save changed instead:

ChangeReads as
Name, description, color, icon, or meaningChanged: name, color
What the domain carriesEntities added: opportunity_360 · Entities removed: case_360
Briefs or skills bound to itBriefs: pricing_policy, brand_voice
Write access through the domainWrites through this domain enabled
Unattended writesUnattended writes (no confirmation) ENABLED
Customer-facing flagCustomer-facing on
Who may read itAccess: granted to Dana Ruiz, 1 manual share revoked
Who may manage itManagers: granted to Sam Okafor

Access lines say granted and revoked, never who has access in total — the Domains page manages manual shares only, and an owner, a sharing rule, or the role hierarchy can grant access it never sees.

Saving a domain without changing anything writes no row.

How it’s kept

The log is its own ledger — one row written at the moment of each event — not a reconstruction from version rows. That distinction matters exactly once: a deleted artifact takes its versions with it, and a reconstructed history would vanish with them. The ledger row stays, label and all.

Draft saves don’t appear, deliberately: drafts change nothing an agent receives. The log records the moments that did.

Who sees what

Admins see everything. Domain managers see the artifacts homed in their domains — the same scope that governs what they can manage. A domain’s own events count as homed in it, so a manager sees the history of the domains they manage and no others.

What’s next

  • Versions — the contract the log is built from