LCJ

LCJ stands for Lightweight Candidate Journal. Nova uses it as a compact journal for learning-relevant events and candidates: evidence that may become useful, but is not trusted long-term knowledge yet.

LCJ records what happened during real agent work on websites: tool outcomes, observations, repeated blockers, selector drift, navigation patterns, and short learning claims that can be reviewed later.

LCJ feeds ALP. ALP can only suggest, generate, promote, or reject learning when enough real evidence exists. PKS stays reserved for reviewed website knowledge that has passed the learning gates.

Most LCJ evidence appears automatically while normal Nova tools run. Agents and integrators use LCJ directly only when they need memory statistics or want to add an explicit candidate inside a claimed work context.

In short

• LCJ stores learning evidence, not executable guidance.
• Normal tool work creates most LCJ observations automatically.
• Manual candidates require a claimed target context.
• Candidates use the states unverified, verified, or disproven.
• Verified candidates can become promotable only after enough evidence.
• LCJ never replaces current-page confirmation or safety gates.

What LCJ records

LCJ keeps the raw material that later learning decisions need. It records evidence before that evidence becomes handbook-like guidance.

1. Tool events LCJ can keep whether a tool succeeded, failed, how long it took, and which website context mattered. This lets later review distinguish a real success from a guessed claim.
2. Observations Observations describe meaningful signals such as action_success, action_failure, blocker_dismissed, selector_drift, perceive_signature or telemetry_confirmed.
3. Candidates A candidate combines component, claim, status and confidence. It says what might be worth learning without making it active knowledge.
4. Evidence strength Finalize review separates weak, medium, and strong evidence. A verified candidate becomes promotable only when its evidence score reaches the promotion threshold.
5. Statistics Memory statistics expose LCJ counts, verification rates, curation rates, finalize/outbox health, and rollout-readiness signals through nova.memory_stats.
6. Learning history Promotion and feedback events keep the decision path visible, so later agents can understand why a candidate moved forward, stalled, or was rejected.

When this matters

Use LCJ when repeated website work should leave evidence behind: recurring consent dialogs, selectors that fail and recover, repeated form patterns, fragile navigation paths, action outcomes that should be reviewed, or task evidence that may become reusable guidance later.

Knowledge model for agents

For an agent, LCJ answers four questions: where did the evidence happen, what claim is being made, how mature is that claim, and what must be reviewed before it can affect future work?

Work context

Manual candidates are tied to a claimed target. Without a current nova.tab_claim context, an agent cannot add LCJ candidates safely.

Observation

A normalized learning signal from real work, such as a successful action, failure, blocker, drift signal, or page signature.

Candidate

A short reusable claim that may become useful after evidence and review. It is still a candidate, not trusted knowledge.

Component

The category key in component. It groups related candidates such as a blocker, navigation pattern, automation lock, or UI behavior.

Status

unverified is the default state, verified means supporting evidence exists, and disproven records evidence against the claim.

Confidence

A score from 0.0 to 1.0. It helps rank the candidate, but it does not make the candidate executable.

Finalize stats

finalizeStats reports how many LCJ candidates were considered, verified, promotable, or prepared for curated knowledge writes when a work context is finalized.

Memory statistics

nova.memory_stats reads LCJ, finalize, outbox, and runtime learning metrics for a chosen time window.

How agents use LCJ information

LCJ is a journal, not a shortcut. The agent first creates or uses real evidence, then reads or writes small candidate signals, and lets ALP decide what should become durable knowledge.

1. Claim the work context An agent claims the relevant tab with nova.tab_claim. This binds manual LCJ candidates to the right target and owner.
2. Let normal work create evidence Browser tools such as nova.perceive, nova.click_selector or nova.type_selector produce outcomes that can become LCJ observations.
3. Add explicit candidates sparingly When a reusable pattern is clear, an agent or integration can call nova.memory_add_candidate with a concrete component and short claim.
4. Inspect memory health nova.memory_stats returns windowed LCJ counts, verification rates, curation rates, finalize decisions, outbox status, and selected runtime learning health signals.
5. Let ALP review the evidence ALP tools such as nova.learn_suggest, nova.learn_generate and nova.learn_feedback turn LCJ evidence into reviewed learning decisions.
6. Finalize without turning evidence into action finalizeStats can summarize LCJ candidates when a claim context is released. The summary can prepare review or promotion, but it does not execute website actions.

When LCJ evidence applies

LCJ state describes evidence maturity. It can make a pattern visible, but only promoted PKS knowledge may guide future work, and even then only after the current page confirms the situation.

Failure and guard conditions

These are the hard edges an agent or integration should expect from LCJ-facing MCP tools.

Agent interpretation example

The example shows LCJ as an evidence contract: the agent writes a short candidate, reads the returned identifiers, and still waits for review before treating it as guidance.

Candidate request

{
  "tool": "nova.memory_add_candidate",
  "arguments": {
    "targetId": "active",
    "agentId": "default",
    "component": "consent-dialog",
    "claim": "Consent banner disappears after clicking the footer reject link.",
    "status": "unverified",
    "confidence": 0.65
  }
}

Relevant response fields

{
  "structuredContent": {
    "ok": true,
    "targetId": "tab_12",
    "taskId": "claim_4f9d",
    "ownerAgentId": "default",
    "candidateId": 42,
    "created": true,
    "status": "unverified",
    "confidence": 0.65,
    "updatedAtUtc": "2026-05-07T10:30:00.0000000Z"
  }
}

Agent interpretation

{
  "treatAs": "learning evidence candidate",
  "mayExecute": false,
  "beforePromotion": "gather repeated evidence and review through ALP",
  "beforeUse": "only promoted PKS knowledge may guide action, and only after current-page confirmation"
}

MCP contract

This is the deterministic layer under the explanation. It describes LCJ fields that agents and integrators should read as contract signals, not as free-form documentation prose.

Execution rule: No LCJ field may trigger a website action; LCJ evidence must pass ALP/PKS review and current-page confirmation before it can guide behavior.