Runtime invariants

While it works, DataMind Oda runs automatic checks over its own parts: each runtime invariant confirms that one part's saved data and its live state still describe the same thing. This page is the reference for those checks. What a failed check means for the task you were running is on Runtime checks, and the tools-side reference is on Runtime consistency checks.

What a check is

• One check, one part. A part of Oda that keeps state registers a check for its own data, and a part that carries no check of its own is not checked.
• Saved data against live state. The check confirms that the part's saved data and its live state still describe the same thing. It watches Oda's own state, not your files or your commands.
• Automatic and silent. The checks run on their own while Oda works: you do not start them, and a passing check produces nothing you see. What you see from a check is its failure report.
• Read only. A check observes; it never rewrites. Nothing Oda sends to a model changes because of a check.

What the checks cover

• 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, the saved records behind them, and the workspace.
• Delegation and longer work. Subagents, 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.
• Only where there is something to watch. A check exists where a part's saved data and live state can drift apart; a part without a check has its own reason, and not every part carries one.
• Not in every setup. Some ways of starting Oda leave the checks out entirely, and then nothing is checked; the standard setup includes them. Where the checks are present, they are on by default.
• Where the checks stop. Loading the check system by itself checks nothing; each check arrives with its part. Operations from before a part was reloaded are outside what its running check saw, and a check on assembled requests covers only the requests the agent loop builds.

When a check fails

• The message. 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.
• What the finding says. The finding names a contradiction between the part's saved data and its live state; for example, that a saved access mode is not one of the modes Oda knows.
• Attribution. The message is attributed to the part that owns the check: the name in it is Oda's own name for that part.
• The stop. Oda reports the failure instead of continuing on the state the check could not confirm, and the operation that hit the failure stops. This is not a command failure: the stop comes from Oda's own state.
• Keep the message as shown. The wording is already Oda's own. Keep the message exactly as it came, including the part name and the code, when you report it. Where the original text stays is on What Oda shows and what its logs keep, and what a failure means for your task is on Runtime checks.

Setting which checks run

• A single switch. All checks can be switched off together and switched back on; they are on by default.
• 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 is not checked: the block list wins.
• 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. An entry that is empty, padded with spaces, repeated, or not a pattern Oda can 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; a change takes effect the next time Oda starts.
• Who changes them. The switch and the lists are settings of how Oda is started; they belong to whoever starts and configures Oda.

How a check is installed and released

• Names are reserved. A check installs under the name of the part it belongs to; while the check runs, the name stays reserved, and a second check cannot take it.
• A failed install is rolled back. If a 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.

Questions, answered

Do all ways of running Oda include the checks?

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

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.

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.

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.

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.

Does a part with no check need one?

Not by itself. A check exists only where a part's saved data and live state can drift apart. Where there is nothing of that kind to watch, no check exists for the part, and that is by design.

Who changes which checks run?

The switch and the two lists are settings of how Oda is started, so they belong to whoever starts and configures Oda.