CLS

CLS stands for Closed-Loop System. Nova uses it to treat browser actions as verifiable state transitions: an action is not reliable just because a click, input, or submit was dispatched.

CLS belongs to moments where an agent changes page state. Nova can check preconditions, dispatch the action, observe the result, and report whether the expected postcondition was confirmed, contradicted, or still unclear.

This prevents false success. If the page confirms the intended result, the agent can continue from the new state. If the page shows an error, remains ambiguous, or the action never reached the page, the next step should repair, observe again, or stop safely.

CLS connects execution with memory. TOB supplies observed evidence, OK supplies current service facts, PKS can learn from verified successes and failures, and ETM can use the result when deciding whether a task run is really complete.

In short

• Dispatch is not proof that a browser action succeeded.
• Commit-point actions need preconditions and postconditions when they can send, submit, log in, switch state, or otherwise change a service.
• CLS separates pre-dispatch blocks from post-dispatch uncertainty so agents do not repeat dangerous actions blindly.
• Verified outcomes can feed task progress, PKS health, ALP review, and later guidance.
• CLS does not grant permission by itself; Nova safety gates and user control still apply.

What CLS verifies

CLS checks the parts of an action that are easy to confuse when an agent only sees tool success.

1. Preconditions Before dispatch, the current page must still match the expected starting state. If the precondition fails, the action should not run.
2. Dispatch Nova reports whether the action actually reached the page. A pre-dispatch block is different from a click that fired but did not produce the expected result.
3. Postconditions After dispatch, Nova checks success, forbidden, and ambiguous signals. This is where “sent” becomes “confirmed”, “failed”, or “unclear”.
4. Retry safety CLS tells the agent whether it may retry, must not retry, or should check the postcondition first because a repeat could duplicate the action.
5. Goal resume When a closed-loop goal is active, Nova can expose the current step so an agent can resume after context compression without guessing where it left off.
6. Learning feedback Verified outcomes provide stronger evidence for task completion, PKS health, and later learning than a raw tool success.

When this matters

Use CLS for actions where the result changes state and a blind retry would be risky: sending a message, submitting a form, confirming a login, changing a model or workspace, dismissing an overlay that controls access, or closing a task step that should only count after visible proof.

CLS model for agents

For an agent, CLS answers four questions: what goal is active, what pre-action state must hold, what result proves success or failure, and what should happen if the result is unclear?

Goal

A durable work objective on a target. It can contain ordered steps and appears as goalContext when active.

Step

One action inside a goal. A step can be planned, dispatched, verifying, done, ambiguous, failed, blocked, or aborted.

Transition contract

The structured agreement for one meaningful action: preconditions, action kind, postconditions, retry policy, and ambiguity policy.

Assertion

A machine-checkable condition such as a fact existing, matching a value, changing, or becoming absent. Assertions can be grouped as all, any, or forbidden.

Guarded commit

The result object that tells the agent what CLS did: dispatch status, verification status, retry advice, failed assertions, and timing.

Action dispatch

The point where the page was actually touched. If actionDispatched is true, a retry may duplicate a submit, send, or state change.

Postcondition-first retry

A recovery rule for non-idempotent actions: inspect the result first, then decide whether another dispatch is safe.

How agents use CLS information

CLS gives agents a verification loop around actions that matter. The agent should read the page, bind or resume the goal, use a guarded action, and then let the returned state decide the next move.

1. Read the page and goal context The agent starts with nova.perceive. If goalContext is present, it reads the active step before acting.
2. Create or query a goal when work spans steps For multi-step work, nova.goal_register can create, query, close, or annotate the active closed-loop goal.
3. Use a guarded commit tool for meaningful actions For common commit points, the agent prefers nova.guarded_send_message, nova.guarded_submit_form, nova.guarded_login, nova.guarded_switch_model, or nova.guarded_switch_sandbox.
4. Provide a transition contract when using raw input tools If the agent uses nova.click_selector or nova.type_selector for a commit point, it supplies transitionContract with preconditions and postconditions.
5. Read dispatch and verification separately The agent checks actionDispatched, guardedCommit.dispatchStatus, guardedCommit.verificationStatus, and guardedCommit.retryAdvice.
6. Continue only from verified state Verified success can advance. Verified failure, a blocked precondition, or an indeterminate result should trigger repair, another observation, or a safe stop.

When CLS state applies

CLS state is trustworthy only inside the current target and action context. A previous result is not permission to assume the page still looks the same after navigation, reload, user interaction, or another agent action.

Failure and guard conditions

These are the hard edges an agent or integration should expect from CLS contracts.

Agent interpretation example

The example shows CLS as a contract: the agent states the action goal, Nova verifies the postcondition, and the response tells the agent whether the next step may continue.

Guarded action request

{
  "tool": "nova.guarded_send_message",
  "arguments": {
    "targetId": "active",
    "text": "Please summarize the selected article.",
    "transitionContract": {
      "postconditions": {
        "success": {
          "any": [
            {
              "factKey": "chat.streamActive.started",
              "operator": "eq",
              "expected": true
            },
            {
              "factKey": "chat.assistantTurnCreated",
              "operator": "eq",
              "expected": true
            }
          ]
        }
      }
    }
  }
}

Relevant response fields

{
  "structuredContent": {
    "ok": true,
    "status": "ok",
    "actionDispatched": true,
    "guardedCommit": {
      "dispatchStatus": "dispatched",
      "verificationStatus": "verified_success",
      "retryAdvice": "do_not_retry",
      "outcomeVerdict": "satisfied"
    }
  }
}

Agent interpretation

{
  "treatAs": "verified action outcome",
  "mayContinue": true,
  "doNotRepeat": "actionDispatched is true and the send is non-idempotent",
  "memorySignal": "success can support task progress and future learning"
}

MCP contract

This is the deterministic layer below the explanation. It lists CLS fields that agents and integrators should treat as contract signals rather than free prose.

Execution rule: No commit-point action is complete until its current postcondition is observed or uncertainty is explicitly surfaced.