While it works, DataMind Oda runs built-in checks on its own parts so that each part's saved data and its live state stay consistent. This page covers what the checks watch, the failure they raise and what it means for your task, and how the set of checks is selected.
What a check is
A check belongs to one part. A part of Oda that keeps state installs its own check while Oda runs. Only the parts that carry a check are checked.
A check guards the part's own data. It confirms that the part's saved data and its live state still describe the same thing. It checks Oda itself, never your files or commands.
Automatic and silent. The checks run on their own while Oda works: you do not start them, they ask nothing of you, and a passing check produces nothing you see. What you see from a check is its failure report.
Read only. A check reads assembled requests and saved state; it never rewrites request content, so nothing Oda sends to a model changes because of a check.
Checks arrive with their parts. Loading the checks alone installs none: only a part's own check covers it.
Not in every setup. Some ways of starting Oda leave the checks out entirely, and then nothing is checked. The standard setup includes them, and where they are present they are on by default.
Which parts carry a check
The conversation. The saved records of chats, their agents, and the agent loop that runs a conversation's steps.
The model side. Model calls and their retries, the instructions assembled for a request, and long-chat compaction.
Tools and jobs. The tool pipeline, the to-do list, commands and background jobs.
The surroundings. Files, access modes, settings and credentials, storage, the workspace and chat titles.
Delegation and longer work. Helper agents, workflows and goals.
Interaction. Hooks, approval questions and permission presets.
Scheduling and planning. Scheduled tasks, reminders and plan mode.
The web side. The live reload and runtime pieces behind Oda's browser page.
The list is not exhaustive, and not every part carries a check: a check exists where a part's saved data and live state can drift apart, and a part that carries none has its own reason for the gap.
When a check fails
The message comes from the owning part. A failed check reports a message that begins invariant violated by "<part>": and then says what the check found. It carries the stable code INVARIANT. The name in it is Oda's own name for the part whose check failed.
The operation stops. Oda reports the failure instead of continuing on state the check could not confirm, and the operation that hit the failure stops.
It is not a command failure. The report says that an internal check failed, so the stop comes from Oda's own state rather than from a command that did not succeed.
The finding names a contradiction. Two examples: a saved access mode that is not one of the known modes, or a saved state for Plan mode that is not a plain true or false.
What to do after a failure
Send the request again.
If the same failure comes back, keep the message exactly as shown, including the part name and the code. The text is already in Oda's own wording, and the original wording stays in Oda's own log files; Diagnostic text and logs has the details.
The switch and the lists are settings of how Oda is started, so they belong to whoever starts and configures Oda.
On by default. Every check runs while Oda works. The enabled switch turns all of them off together, and back on.
Two lists select by part. An allow list (package_allowlist) keeps only the parts it names; a block list (package_blocklist) leaves out the parts it names. A part that matches both lists is not checked: the block list wins. Both lists are empty by default.
Entries are patterns, matched case-sensitively. A plain entry matches any part name it appears in; add ^ at the start or $ at the end to pin where the match must begin or end.
A bad entry stops the start. A blank entry, a repeated entry or a pattern Oda cannot read stops Oda from starting, and the message names the list and the entry. Correct the entry, then start Oda again.
Read once. The switch and the lists are read when the checks start and stay fixed while Oda runs, so a change takes effect the next time Oda starts.
How a check is installed and released
One name per part. A check installs under the name of the part that owns it, and the name stays held while the check runs; a second check for the same part is refused.
A failed install is rolled back. If a part's check fails while it installs, Oda disposes it and releases the name: nothing half-installed stays behind, and the part can try again.
Release is complete. When a part or its check is unloaded, the check is removed completely: everything it added and recorded goes away, and the name it held is released. A part that comes back can register its check again cleanly, with nothing carried over.
Boundaries worth knowing
Reloads have a boundary. Checks follow the parts while they run: after a part reloads, operations from before the reload are not part of what the running check saw.
The request check has a boundary. When Oda rebuilds requests to check them, it covers the requests the agent loop builds. A one-off model call made outside the loop is not covered that way.
Questions, answered
What does an INVARIANT message mean?
An internal check failed. The message names the part that failed its check, begins invariant violated by "<part>":, and carries the code INVARIANT. Oda stops the operation instead of continuing on state the check could not confirm.
What should I do when a check fails?
Send the request again. If the same failure comes back, keep the message exactly as shown and contact your DataMind OS administrator with it; see What to do after a failure.
How is a failed check different from a command failure?
A command failure means a command did not succeed. A failed check means Oda's own state failed a check: the message names the part, carries the code INVARIANT, and Oda stops instead of continuing on state it could not confirm.
The failure names a part I do not recognise. What is it?
It is Oda's own name for the part of itself whose check failed. The name is how the failure is attributed; keep it exactly as shown when you report the problem.
Do I have to start the checks or watch them?
No. The checks run on their own while Oda works: you do not start them, and a passing check is silent. What you see from a check is its failure report.
Can the checks be switched off?
Yes. The enabled switch turns all of them off together, and back on. The set that runs can also be narrowed with an allow list and a block list; a part that matches both is not checked, because the block list wins.
Do the list entries have to be exact names of parts?
No. An entry is a pattern matched against part names, and the match is case-sensitive: a plain entry matches any name it appears in. Add ^ at the start or $ at the end to pin the match.
What happens if a list entry is blank or unusable?
Oda refuses to start: a blank entry, a repeated entry or a pattern it cannot read stops the start, and the message names the list and the entry. Correct the entry, then start Oda again.
I expected a part to be checked, but it is not. Why?
Several reasons are possible: the part carries no check of its own; the selection lists leave the part out; the way Oda was started leaves the checks out entirely; or the operations you have in mind happened before a reload of that part, which the running check did not see.
What happens to a check when its part is reloaded?
The check is released with its part: everything it added and recorded goes away, and the name it held is freed. When the part comes back, its check can register again cleanly, and operations from before the reload are outside what the new check saw.
Are all of Oda's model calls covered?
The check on rebuilt requests covers the requests the agent loop builds. A one-off model call made outside the loop is not covered that way.
Do the checks change what Oda sends to a model?
No. The checks read assembled requests and saved state; they never rewrite request content, so nothing Oda sends to a model changes because of a check.