Runtime consistency checks

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 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.
• Checks arrive with their parts. Loading the checks alone installs none: only a part's own check covers it.

Which parts carry a check

The core stateful parts are covered today:

• The work itself. The agent loop, model calls, tools, prompts, compaction, helper agents, goals, commands and jobs carry checks.
• The state around it. Hooks, access modes, files, approvals, settings, storage, the workspace, presets, chat titles, plan mode and reminders carry checks.

The list is not exhaustive, and not every part carries a check: 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 operation stops. Oda reports the failure instead of continuing on state the check could not confirm. What a failed check means for the chat you were running is on Runtime checks.
• 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.
• Keep the message exactly as shown when you report it. The text is already in Oda's own wording, and the original wording stays in Oda's own log files; What Oda shows and what its logs keep has the details. For where to take the problem, see Updates and troubleshooting.

Selecting which checks run

• On by default. Every check runs while Oda works. All of them can be switched off together.
• Two lists select by part. An allow list keeps only the parts it names; a block list leaves out the parts it names. A part that matches both lists is not checked: the block list wins.
• Matching is case-sensitive. An entry is a pattern, not an exact name: it matches any part name it appears in, and the comparison is case-sensitive.
• 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 lists are read when Oda starts and stay fixed for that run, so a change takes effect the next time Oda starts.

When a check fails to install

• 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.

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.
• Requests are never rewritten. A check reads assembled requests and saved state; it never changes request content, so nothing Oda sends to a model changes because of a check.

Questions, answered

Can two checks claim the same part?

No. 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.

What happens when a check fails to install?

The install is rolled back: Oda disposes the check and releases the name, so nothing half-installed stays behind, and the part can try again.

I expected a part to be checked, but it is not. Why?

Three reasons are possible: the part carries no check of its own; the selection lists leave the part out; or the operations you have in mind happened before a reload of that part, which the running check did not see.

Why is an operation from before a reload not checked?

The checks follow the parts while they run. A part that reloads starts checking from that point on; operations from before the reload are outside what the running 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.

How do the two lists choose which parts are checked?

An allow list keeps only the parts it names; a block list leaves out the parts it names. A part that matches both is not checked, because the block list wins. Entries are case-sensitive patterns.

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. This applies to whoever starts and configures Oda.

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.