Operations
You spent a quarter teaching the platform what your AP data means. Now the agent can answer "what is our exception volume" with the right SQL against the right tables. The next ask from your team is heavier: mark these invoices paid in NetSuite, write the matched payments back to the ERP, log a batch QC result back to MES, update a customer record after a support resolution. Reads are not enough. The agent needs to write.
An Operation is the writable counterpart to a query. It is a named asset on your Data Collection that names the change ("mark invoice paid"), the inputs it takes, the effects it produces, and the binding it writes through. Operations carry the same catalog discipline as entities and metrics, so the change the agent proposes is one your team has already shaped.
Audience: builders
Partial today. Operations are authored and visible in the catalog. End-to-end execution (preview, approve, apply) is not wired yet. See What is shipped today below for the exact line between authored and runnable.
Where Operations live
Operations are a catalog asset, defined in the same semantic model that holds entities, relationships, and metrics. Open the Catalog tab on your Data Collection and look in the Advanced · Operations, Recipes, Rules disclosure under the catalog list. The catalog map also surfaces operation nodes; the Operations legend chip filters the map to them.
Each Operation card carries:
- Inputs. The named parameters the agent fills at call time.
- Effects. The change the operation performs (insert, update, delete, with the table it touches).
- References. The catalog entities and relationships it reads or writes.
- Grounded in. The source relation the binding writes through.
- Highlights. Hard stops and shared rule references that constrain when the operation can run.
The define, approve, grant, run loop
The intended lifecycle for an Operation has four stages. The first is in product today. Stages two through four are partial; see the gap section at the bottom.
Define
Operations are proposed by the catalog build alongside entities and metrics, or you can describe a missing one and rebuild. Open the Operation card in the Catalog drawer to read its inputs, effects, and approval policy. Use Edit with intent to refine it.
Approve
A Live operation is one a reviewer has accepted as part of the published catalog. Draft proposals stay pending until applied through the catalog review banner. Approval lands the operation in the published semantic model.
Grant
A granted operation is one a specific Project is allowed to call. The grant is what stops a Project that reads a collection from also writing through it without an explicit step.
Run
When the agent calls the operation, the platform builds a preview of the change, validates it against the operation's effects and any guardrails, and applies it only on confirmation. Every run logs to the audit ledger with parameters, affected rows, and validation results.
Operations are catalog-scoped, Verified actions are workspace-scoped. An Operation lives on a Data Collection and writes through that collection's bindings. A Verified action is a workspace-level approved package the agent can call from any Project. Reach for an Operation when the change is a write against data the collection already grounds. Reach for a Verified action when the discrete decision is the asset, regardless of which collection it touches.
What is shipped today
Authored and visible in product:
- Operation cards in the catalog, with inputs, effects, references, grounded-in, and highlights.
- Operation nodes in the catalog map, with the Operations legend filter.
- Recent activity surfaces Write preview and Write applied intent labels with their own icons.
- The intent classifier recognizes
semantic_write_previewandsemantic_write_applyroute kinds.
Not yet executable:
- Preview and apply routes return a visible limitation message instead of running. The agent reports "this route is not yet executable" and stops.
- There is no project-level grant surface. Authoring an Operation does not currently restrict which Projects can call it.
- The audit ledger does not yet carry per-operation entries with parameters and affected rows.
Treat Operations today as a catalog asset you can author and reason about. Hold off on telling analysts they can apply writes from chat.
Related
- Build the catalog for how Operations land in the semantic model alongside entities and metrics.
- Use a Data Collection for how the agent classifies a request and picks the right lane.
- Author a Verified action for the workspace-scoped alternative when the change is broader than one collection.