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.

Scope

Verified logic exists at more than one level, and you pick the scope before you create it.

Team and workspace entries are managed from Shared Context. Its overview lists them in a Verified Logic section with each entry's scope, status, and runs in the last 30 days. A scope filter (All, your team, Workspace, Built-in) narrows the list, and proposals wait in the one Waiting for review queue shared with Skills and Memories.

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 and Projects 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.

Proposals waiting on a reviewer are listed in Waiting for review on the Shared Context overview, with Verified Logic as their kind.

Create one

Verified Logic is built in a conversation with the agent, not in a form.

Review and approve

Read a Project entry's detail page

In a Project, an entry opens as a full detail page, read from top to bottom:

• Version picker. The proposal, the live version, and older published versions, each with who proposed or published it. Pick an older version to read its files, and click Restore to make it live again.
• Compare switch. Compares the version you are reading with the one before it: changed input and output fields, new tests, and line changes in each file.
• Summary cards. The test result, for example "3 of 3 tests passed", and how many recent runs succeeded.
• Input and output. The fields the entry takes and returns, from action.yaml.
• Tests. Each test with its input, output, and any failure.
• Usage. Executions, success count, median duration, and the last 20 runs across all versions. Test runs do not count toward usage.
• Source files. Every file in the version, with find-in-file and a download for each file.

That history is the best evidence for whether a new version is ready.

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. A Verified Logic step can also submit Work Items, wait for their results, and read them, the same way an agent step can. 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.

When two runs write the same files

Two runs of the same entry can overlap, for example when a Workflow and a custom view call it at once. By default, if both change the same file, the later run fails and names the files that conflicted.

For files that are safe to replace, such as a cache, declare them in action.yaml under workspace_outputs and choose what happens on a conflict:

writes_workspace: true
workspace_outputs:
  - paths:
      - cache/data.json
      - cache/meta.json
    conflict_policy: newer_generation_wins

A run must write or delete every file in a declared group. Both replacement policies overwrite any other change to those files, including edits by people and agents, so declare only files that nothing else edits. The policies apply when a Workflow, a custom view, or the API runs the entry. When an agent calls it, its changes go through the agent's usual review instead.

Logic that reads no Project files

If the entry reads no Project files and writes none, set workspace_mount: none in action.yaml:

writes_workspace: false
workspace_mount: none

When a Workflow, a custom view, or the API runs the entry, it then starts in an empty workspace that holds only the package, instead of loading the Project's files, so it starts faster. The default, workspace_mount: project, gives the entry the Project's files as before. workspace_mount: none requires writes_workspace: false, and changing it needs a new approved version.

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 go back to an earlier version of a Project entry, pick it in the version picker on its detail page and click Restore. The restored package goes live as a new version.

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.

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 works with data: it reads or changes rows in the Project's data sources, or it is linked to a semantic model. It is listed under Data rather than Tools.

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.