Why a spreadsheet cannot classify agent consequence.

Another fair objection sounds almost embarrassingly practical:

"If an agent does something, why not just make it write the action to Excel or a database, then have someone review it?"

For lightweight pilots, that may be good enough. A small team can use a spreadsheet to track proposed actions, reviewer comments, and outcomes. Nobody should feel guilty for starting there.

The problem appears when the spreadsheet quietly becomes the governance system.

At that point, the organization is asking a manual recordkeeping tool to do something much harder: interpret agent consequence across runtimes.

The hard part is not the row

Recording a row is easy.

Classifying the consequence behind the row is hard.

An agent action may arrive as a shell command, an MCP tool call, a workflow step, a plugin invocation, a ChatGPT App review, a custom SDK event, or a cloud automation request. The text can look harmless while the effect is serious. The text can look scary while the actual target is a disposable sandbox.

Two examples:

git push origin main

and

git push origin experiment/runtime-map

Both are "git push." A string matcher may treat them as similar. A spreadsheet may place them in the same category. A serious governance system should not.

The first may trigger production release. The second may update a draft branch. The risk depends on target, branch role, repository sensitivity, CI behavior, actor identity, policy posture, reversibility, and evidence quality.

CAVA exists because consequence lives in context.

Why CAVA is not a spreadsheet with better labels

CAVA stands for Canonical Action Verification and Analysis.

The name is intentionally plain: canonicalize the action, verify its structure, analyze its consequence. It is the part of OSuite that turns raw agent activity into an object policy can actually judge.

A spreadsheet can say:

CAVA needs more:

That is not clerical work. It is semantic analysis.

Similar-looking actions should not receive the same route

One reason early governance products feel fake is that everything gets the same score.

Every bash command is "medium risk." Every write operation is "needs approval." Every read operation is "safe." Every external URL is "low risk." The product looks tidy, but customers can feel the laziness.

CAVA gives OSuite room to be more honest.

A read-only action against a public web page can still require approval if the user frames it as enterprise due diligence, asks the agent to rely on the result for policy, or routes the output into a sensitive decision. A write action can be low-risk if it targets a local draft file inside a disposable environment with no external side effect.

The raw verb is not enough.

The spreadsheet fails under retries and wrappers

Agents do not always perform one clean action. They retry. They call wrappers. They transform prompts into tool calls. They ask one tool to prepare a file and another to publish it. They split work into subtasks. They call the same endpoint with slightly different payloads.

If the governance record is a spreadsheet row written by the agent itself, the system now depends on the agent honestly describing the action it wants to take.

That is a weak boundary.

CAVA treats the runtime event as input, not truth. It attempts to derive a canonical action object from observable fields: tool name, command, target, metadata, runtime lane, policy profile, actor identity, system class, and evidence. The agent's own description can help, but it should not be the only source of classification.

This is the same principle we apply to external verifier work: do not accept important fields only because the caller supplied a nice label. Derive what can be derived. Mark uncertainty where uncertainty remains.

The buyer should see the output, not the machinery

Nobody wants to read a parser trace in a governance UI.

The product output should be legible:

• —The action touches a production-adjacent repository.
• —The action crosses a release boundary.
• —The requested privilege is write plus deploy.
• —Reversibility is partial.
• —Evidence is sufficient for approval, but closure is required after execution.
• —Policy route: require approval.

That is the buyer-facing value of CAVA. It makes an agent action understandable without pretending the action is simpler than it is.

Where Excel still helps

Spreadsheets can still have a place.

They are useful for pilot planning, exception review, customer onboarding, test case inventory, manual reconciliation, and compliance export. OSuite should make it easy to export governed action evidence into formats buyers already use.

The mistake is using Excel as the classifier.

If the action is high-risk, the spreadsheet should receive the governed result. It should not be responsible for deciding what the action is.

The practical answer

If a buyer says, "Can we just track this in Excel?" the answer is:

For a pilot tracker, yes. For runtime governance, no.

Excel can help humans organize work. CAVA helps OSuite understand what the agent is actually trying to do.

That difference is the line between recordkeeping and control.