Verified logic
The first audit question is going to be "what has the AI been authorized to do?". Verified logic is the answer: rules and actions your team has reviewed and approved for the agent to use again and again.
Audience: builders
What it is
A piece of verified logic is a named, reviewable package the agent can call by name. Each one contains:
- A guide. The plain-language description of what it does and when to use it.
- A source. The implementation that runs when it is invoked.
- Examples. Anchor cases that teach reviewers, and the agent, what right looks like.
Approving a journal post over $10,000. Releasing a production hold on a batch. Issuing a refund above policy threshold. The point is that the discrete decision is the asset: once it is approved, the agent always uses the approved version, and every invocation lands in the audit ledger.
That turns "what decisions has the agent been authorized to make?" into a list somebody can read.
Two names for one feature. The product navigation reads Verified logic. Under the hood, in the API and in some older URLs, the same thing is called a Verified action. Either name points to the same surface. When in doubt, follow the nav label.
Scope
Verified logic exists at more than one level, and you pick the scope before you create it.
| Scope | Available to | Approved by |
|---|---|---|
| Project | One Project. Found under Tools in its Context tree | |
| Team | Every Project the team owns | Team admins |
| Workspace | The whole tenant | Workspace admins |
Team and workspace entries are managed from Shared context, where the page carries a tab per scope and a badge counting that scope's pending proposals.
Which level to author into is a real decision: see Shared versus project scope.
Read the row badges
Every entry shows its state on the right of the row:
- Live. Approved and callable by Workflows, Projects, and Data Collections in scope.
- Draft. Scaffolded but not yet submitted for review. Visible only to the author.
- Pending update. A live entry has a fresh proposal in review. The current live version keeps serving until the proposal lands.
A separate Pending proposals section sits above the list when the scope has candidates waiting on a reviewer.
Create one
Open the create dialog
Click Logic 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 it
Title is what teammates see in the row. Slug is the short identifier used in references and the file path; leave it blank and one is generated. Summary is one sentence on what it does.
Create the starter
The new row lands in the list as a Draft and the drawer opens on it. Work through the guide, the source, and the examples in place.
Submit a proposal
Click Submit proposal in the drawer footer. The entry moves to the Pending proposals queue.
Review and approve
Open the proposal
Click a row in Pending proposals. The drawer renders the proposed package alongside the currently live version when one exists.
Approve, reject, or withdraw
Approve makes the proposal the live entry; Workflows and Projects pick it up on the next run. Reject closes it without taking effect, and the Draft stays for the author to revise. Withdraw lets the submitter retract 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. That history is the best evidence for whether a new version is ready.
Approving your own entry is still a decision. Having review permission does not make the review step ceremonial. The value of verified logic is that somebody checked it, and the ledger names who.
Call it
The agent calls verified logic the way it calls any tool: by name, with arguments matching its contract.
- From a Workflow. Reference it by name on the step that calls it. The approved version is pinned when the run starts, so a run's result ties back to exactly what was approved at the time. See Steps.
- From a conversation. Mention it by name, or let the agent pick it when your request matches.
Every call writes to the audit ledger: the actor, the inputs, the outputs, and the version that ran.
Changing and retiring
A live entry is never edited in place. Open the row, edit the package, and submit a proposal. The row stays Live with a Pending update badge until a reviewer approves, at which point the proposal becomes the new live version and the previous one supersedes.
To retire one, archive it from its drawer. Archived entries stop being callable and stop being injected into agent context, but stay searchable so the historical record stays intact.
Check what depends on it before archiving. A live entry may be called by Workflow steps and reached for by agents in conversation. Archiving is not an error anywhere; the calls just stop being possible.
Verified logic and verified queries
Both are things your team approved and pinned. The difference is what they do.
- Verified logic does something: a calculation, a rule, a call out to another system.
- A verified query reads data. It is SQL against a Data Collection's sources.
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.
Every approved entry carries the reviewer, the timestamp, and the package contents at the moment of approval, and every call links back to the version that ran. That chain is the audit artifact, and it is what a controller asks for when the agent has touched a process they care about.