Version 3.0
Verified logic

Author verified logic

The first audit question is going to be "what decisions has AI been authorized to make?". Verified logic is the answer: rules and actions your team has reviewed and approved for the agent to use again and again.

Encode the rules and actions once. They become callable by name from any Runbook or chat, the agent always uses the approved version, and every invocation lands in the audit ledger.

Audience: builders

Open the Verified logic tab

Open the Shared Context group in the left nav, then pick Verified logic. The icon on the nav row is a shield-and-tick, which matches the row icon used in the list.

Two names for one feature. The product navigation reads Verified logic. Under the hood and in some older URLs and folders, the same surface is called Verified actions. Either name points to the same workspace. When in doubt, follow the nav label.

Like Shared memories, the page has two scope tabs.

  • Team. Verified logic for the active team.
  • Workspace. Verified logic for the entire tenant.

Each tab carries a badge counting pending proposals in that scope.

Read the row badges

Every entry surfaces its state on the right of the row:

  • Live. Approved and callable by Apps, Projects, and Data Collections in scope. Green badge.
  • Draft. Scaffolded but not yet submitted for review. Yellow badge.
  • Pending update. A live entry has a fresh proposal in review. Blue badge.

A separate Pending proposals section sits above the list when the scope has candidates waiting on a reviewer.

Scaffold a new entry

A verified entry is a named, reviewable package. The starter flow scaffolds the files; you edit them in place, then submit for review.

Open the create dialog

Click the Logic button in the section header. The dialog reads "Create verified logic" with the subtitle "Scaffold the starter first, then edit the generated files in place before submitting a proposal."

Name the entry

  • Title. What teammates will see in the row.
  • Slug. Short identifier used in references and the file path. Optional; one is generated if you leave it blank.
  • Summary. One sentence on what the entry does.

Create the starter

Click Create starter. The new row lands in the list as a Draft and the drawer opens on it.

Submit a proposal

A Draft is yours alone until you submit. Open the row, work through the package contents, then click Submit proposal in the drawer footer. The entry moves to the Pending proposals queue. When a live entry needs to change, open it and click Submit proposal to register a new candidate; the row stays Live with a Pending update badge until the proposal lands.

Review and approve

Reviewers are the same admins who approve Shared memories: workspace admins for workspace scope, active-team admins for team scope.

Open the proposal

Click a row in Pending proposals. The drawer renders the proposed package alongside the currently-live version when one exists.

Reject, approve, or withdraw

  • Approve. The proposal becomes the live entry. Apps and Projects pick up the change on the next run.
  • Reject. The proposal closes without taking effect. The Draft stays for the author to revise.
  • Withdraw. The submitter retracts their own proposal.

The drawer also shows the package footprint: execution count, success rate, last-used time, and the recent execution log when the entry is live. Use that history when deciding whether a new version is ready.

Retire a verified entry

When an entry should no longer be available, archive it from its drawer. Archived entries stop being callable and stop being injected into agent context, but stay searchable so the historical record is intact.

The audit trail

Every create, propose, approve, reject, withdraw, and archive lands in the workspace audit ledger. Filter /audit by the entry name or the actor when a controller asks for the receipt. Pair with Verified actions for the conceptual overview and Shared versus project scope for the rules on when an entry belongs at the team or workspace level.