One run, from the request to the receipt.
IVYX Studio is a local AI workspace in which every capability, from the notebook kernel to the dataset manager, the profiler and the database browser, is a typed tool that runs headless. An agent operates the workspace directly, not through a chat panel beside it. Because no one is standing by to approve each action, a policy rule is evaluated at the gate every capability call passes through, and the run accumulates a signed record of what its calls touched and every decision taken along the way.
The clearest way to explain that is to follow one run all the way through.
Retrain the churn model on August data. Promote it to staging if it beats the current model on recall.
Eight things happen. Six of them are mechanisms; two of them are ordinary work.
- 01
A run opens
Nothing has executed yet. IVYX opens a run and gives it an identity. Everything below attaches to this run, not to a file, a notebook or a session.
MechanismRun identity. One id shared by every line that follows, which is what lets a dataset, a file and a tool call appear on the same record.
- 02
The agent finds the data
The agent calls the dataset manager the same way it would call any tool. No window opens, no dialog appears, nobody is watching. This is an ordinary headless invocation of an installed capability: the extension activates, its handler registers, and nothing on screen moves.
MechanismTyped invocation. The dataset manager declares its inputs and outputs as JSON Schema in a manifest, so an agent can call it directly instead of driving a user interface.
capability.audited datasets.download allowed: true
The record names the dataset by its path in the workspace, and carries a content hash beside it wherever the pipeline engine supplies one. Identity first, digest where it exists.
- 03
The first gate
The training pipeline declares its boundary in its manifest: which actions it uses, from a closed vocabulary of fourteen, what risk it carries, and whether it needs a person. Policy is evaluated against that declaration before the call runs.
MechanismPolicy at the gate. The rule is checked against the manifest, not against the code, which is why a component generated minutes ago can be governed at all.
capability.audited mlops.pipeline.run argsBinding 7d6441497d2a allowed: true reason: Allowed by policy rule churn-project#3.
- 04
Training runs
This part is unremarkable, and that is deliberate. Your training code is your training code. IVYX does not rewrite it or ask it to move; it runs on your kernel, and IVYX records around it.
- 05
Evaluation against the golden set
The agent scores the new model against the golden set kept with the project. Deterministic, offline and local.
mlops.gate.evaluate metric: recall value: 0.81 bound: 0.78 boundKind: min championValue: 0.76 → pass
The bound is recorded next to the number, and so is which side of it passes. A metric without the threshold it was judged against is not evidence of anything, and a threshold without its direction can be read backwards.
- 06
The refusal
The agent tries to promote the new model straight to production. Understandable, since it is trying to be helpful, and exactly what nobody asked for. The project policy denies that alias, and the same capability with a different argument is a different question.
MechanismRefused before it ran. A deny rule is terminal: no approval prompt, no standing grant and no click satisfies it. There is no dialog for a nonexistent human to dismiss.
capability.audited mlops.model.promote argsBinding 9f2c41ab5d70 allowed: false args: alias = production reason: Denied by policy rule churn-project#0.
The refusal stays in the record. An audit trail containing only successes is not an audit trail.
- 07
A person, for this one step
Promotion is declared high-risk in the capability manifest itself, so the run stops and waits for you. You see the call, its arguments and the numbers it is claiming, not a summary of them.
MechanismApproval in the path. For this class of action only. Everything else was decided by a rule, which is what makes the interruption meaningful when it comes. The grant is bound to these arguments, not to the capability, so approving staging today does not approve production tomorrow.
capability.audited mlops.model.promote argsBinding 41ab9f2c8830 allowed: true args: alias = staging reason: Approval required (step). → granted, scope: once
- 08
The receipt
From the promotion you build a signed evidence package: the training run it resolves to, the datasets and files the run touched, the evaluation figures with the bounds they were measured against, every gate decision including the refusal, and the approval with its timestamp.
MechanismSigned evidence package. Signed with an ES256 key that never leaves the machine, and checkable by a reader who holds no key of their own. The signature proves the package was not altered after the run. It does not vouch for who produced it: the machine that builds a package is the machine that signs it.
evidence.build model: churn-classifier version: 7 → package signed alg: ES256 selfSigned: true evidence.verify → ok, signature valid, no key required
The four mechanisms
The run above is these four, in the order the work meets them.
Typed capability
Every capability in the workspace declares its inputs and outputs as JSON Schema and runs headless. An agent calls it without a window, a chat or a person. This is what makes the workspace operable by something that is not you.
Manifest
A declaration of what a component may do: which actions it uses, what risk it carries, whether it needs a person. Policy is evaluated against the declaration, which is what makes governing generated code possible at all.
Gate
One gate that every capability call passes through, evaluated before the action executes. Recording tells you afterwards that something happened. A gate decides whether it happens.
Evidence package
One signed package per run, holding the datasets and files its calls touched, every gate decision with the rule that produced it, evaluation figures with their bounds, and any approvals. Its integrity is checkable without IVYX.
Where each part runs
Your machine
All of the above. Files, datasets and local models stay local unless you deliberately connect a hosted service.
Your existing tools
Unchanged. If MLflow is your registry, IVYX writes to it. If DVC versions your data, IVYX reads its lineage. If Ollama serves your models, it keeps serving them. Traces go to any OTLP-compatible backend. IVYX adds the one record none of those can produce together, because they do not share an identity for a run.
Production
Export the policy that governed this run into the files your gateway needs, Obot and Arcade today. The export is never more permissive than the local policy, and it names every rule that could not cross. That is the reason to write the policy here rather than after deployment: you find out a rule is wrong while you are still the only one affected by it.
What IVYX is not
Not an IDE for application code
If you are writing software, an editor built for that will serve you better, and IVYX does not compete with one. It generates components with declared boundaries, not applications.
Not a replacement for your ops stack
MLflow, DVC, Evidently, Ollama, promptfoo: all of them keep working, and IVYX is designed to sit with them rather than in place of them. If what you need is visibility, that stack already gives you visibility for free.
Not a perimeter against the person at the keyboard
Nothing on your own machine can stop you from editing your own policy file, and IVYX does not pretend otherwise. The local gate is not there to defeat a determined insider. It is there so that a policy is exercised while the work is being done, a wrong rule is discovered by the person who wrote it rather than by an incident, and the same rules that ran here are the ones your gateway enforces against everyone. Local gating is a rehearsal that leaves a receipt, not a wall.
Frequently asked
What is the difference between recording and gating an AI system?
Recording captures what an AI system did after it did it, which is what observability tools provide. Gating evaluates a policy at the gate a call passes through and refuses or pauses the action before it executes, so the unwanted action never happens. A record built only from observations can prove harm occurred; one built from gate decisions can show it was prevented.
What is a capability manifest?
A capability manifest is a declaration of what a software component may do: its typed inputs and outputs as JSON Schema, the actions it uses from a closed vocabulary, the risk it carries, and whether it needs a person. Because it is a declaration rather than code, policy can be evaluated against it before the component runs. That is what makes governing generated code possible at all.
Can an agent operate IVYX Studio with nobody watching?
An agent can operate IVYX Studio with nobody at the keyboard, and that is the intended mode. Every capability runs headless: the extension activates, nothing on screen moves, and the result comes back typed. IVYX Studio itself has to be running, because the capability gateway lives in the app and a headless server host is not built yet. Since no one is there to click a confirmation, policy is what refuses, and the decision is recorded whether you are present or not.
Capability ids, rule effects and record lines above are the ones IVYX emits. The dataset name, the figures and the timestamps are an illustrative example, not measurements from a real workload.
Runs on your machine. macOS and Linux.