AI Watchers

AI Watchers are governed monitoring definitions and signal records for AI- assisted gap, delay, drift, and risk monitoring. They help teams review what an AI-supported monitor observed before any owning workflow creates final truth.

Watchers do not replace the risk, finding, incident, violation, control, obligation, evidence, lifecycle, or assurance modules. They produce signals or candidates. Final records still move through the owning module, its permissions, review policy, lifecycle rules, audit trail, and approval requirements.

What You Can Manage

Definitions and signals can be created, updated, and archived. Active definitions can also be run manually. Those operations record governed reasons and produce AI Activity/audit evidence.

Registered source contributors can also provide watcher signal candidates. The watcher workbench lets authorized users review those candidates, then materialize them into durable watcher signals with a governed reason. Duplicate candidate signal keys are skipped so the ledger does not create repeated signals for the same observation.

Built-in source contributors currently include governed-evidence freshness, governed-monitoring result review, governed-indicator measurement review, and governed-finding remediation review. Evidence freshness reads accepted evidence claims whose validity has expired, plus claims already marked expired by the governed-evidence module. Monitoring result review reads governed-monitoring results with failed, warning, or error status. Indicator measurement review reads published indicator measurements whose target status is missed, warning, or unknown. Governed-finding remediation review reads active findings that are high severity or overdue. These contributors create display-safe watcher candidates over source refs only. They do not copy source snapshots, finding descriptions, or change the source lifecycle.

Manual and scheduled watcher runs use the same candidate contributor and materialization path. The run record shows how many candidates were available, how many signals were created, and how many candidates were skipped as duplicates. A blocked run can be recorded when the watcher definition is not active.

When a watcher definition explicitly enables AI correlation, Novantra can use an approved AI provider connection to classify newly materialized watcher signals for reviewer triage. The correlation path requires an active and validated provider connection, an approved model record that is allowed for watcher correlation and the source data class, a watcher-correlation use authorization for the AI system, and a source-safe signal payload. If any of those are missing, the run records a blocked or skipped correlation snapshot and does not call the provider.

Watcher correlation and report narratives also pass through the AI data boundary before provider invocation and before provider output becomes reviewable metadata. A blocked boundary decision records sanitized posture and does not call the provider.

Provider correlation stores normalized fields such as correlation level, confidence, reason code, recommendation key, provider connection ref, use authorization ref, and a Novantra-built summary sentence. It does not store raw provider output, prompts, source plaintext, credentials, or source-system payloads in the signal or run snapshots.

Provider-backed watcher correlation also obeys configured AI usage policies. If the relevant provider, model, member, or governance usage threshold is already exhausted, the watcher run records a blocked correlation posture before any provider call is made.

The watcher workbench can also create a draft watcher report dossier from current non-archived signals. The dossier summarizes signal counts and capped signal citations for human review. It is still an AI decision dossier candidate, not a final finding, risk, incident, violation, control, obligation, evidence requirement, exception, assurance engagement, assurance result, or management decision.

AI-enabled tenant job runtime can also create scheduled watcher report dossiers when an active watcher definition explicitly enables report dossiers in its schedule snapshot. The runner creates at most one draft report dossier per watcher period and skips definitions without a report interval, with no loaded signals, or with an existing report dossier for the same period.

Scheduled report dossiers can optionally include provider-backed report narrative metadata. This requires an active validated provider connection, a watcher-report-narrative approved model record, a watcher-report-narrative use authorization for the AI system, and an explicit scheduleSnapshot.reportDossier.narrative policy. When enabled, Novantra sends only refs, counts, statuses, severities, correlation metadata, and snapshot key names. The dossier stores normalized narrative fields and a Novantra-built reviewer summary. It does not store raw provider output, prompts, source plaintext, credentials, or source-system payloads.

Provider-backed report narratives use the same usage-policy gate. When a hard usage limit is exhausted, the dossier records a blocked narrative posture and keeps the report candidate reviewable without sending signal data to the provider.

For an individual signal, the workbench can create a draft conversion dossier. That dossier points back to the watcher signal, source refs, conversion posture, and evidence-ref keys. It is a watcher-binding candidate for review; it does not mark the signal as accepted by the owning module and does not create final source records.

When the conversion target is a governed finding, governed risk, incident, violation, governed control, governed obligation, evidence requirement, governed exception, assurance engagement, or lifecycle review and the user has both AI governance and the owning-module permission, the workbench can also create the final owning-module record through that module’s command seam. The AI watcher signal is then marked converted with a refs-only conversion snapshot that points to the created finding, risk, incident, violation, control, obligation, evidence requirement, exception, or assurance engagement, or review-approval instance. Lifecycle review conversion starts a review-approval record against the watcher source ref; it does not create a generic lifecycle definition or silently start an arbitrary lifecycle instance. AI still does not write owning-module tables directly, does not bypass the owning module, and does not copy signal snapshots, provider output, prompts, or source text into the final record.

How To Use Watchers

1. Create a watcher definition for a source area, such as evidence freshness, lifecycle delay, control coverage, provider posture, or approved measurement stream.
2. Capture the deterministic filter and AI correlation policy as structured summaries. Keep sensitive source content out of the watcher record.
3. Run the watcher manually when you want an immediate governed execution record, or configure a scheduled/hybrid watcher with an interval or next-run schedule so the AI-enabled deployment runner can record due executions.
4. Enable AI correlation only when the AI system has an approved watcher- correlation use authorization, an active validated provider connection, and an approved model allowed for watcher correlation and the source data class.
5. Review contributor candidates and materialize only the observations that should enter the watcher signal ledger.
6. Review watcher signals as candidates, not final breach or risk truth.
7. Create a watcher conversion dossier when a signal needs a governed handoff candidate before the owning module performs final work.
8. Convert to a governed finding, governed risk, incident, violation, governed control, governed obligation, evidence requirement, governed exception, assurance engagement, or lifecycle review only when the source posture and customer policy justify a final owning-module record through the governed-findings, governed-risks, incident-management, violation-management, governed-controls, governed-obligations, governed-evidence, governed-exceptions, governed-assurance, or review-approval module.
9. Create a watcher report dossier when reviewers need a periodic summary of open signal posture and source coverage.
10. Convert only through the owning module when the customer policy allows it.
11. Keep evidence refs and conversion notes attached so later reviewers can see what was observed and why a handoff did or did not happen.

Boundaries

Watcher records should contain refs, statuses, summaries, policy snapshots, and evidence refs. Do not store raw prompts, provider responses, source plaintext, credentials, storage paths, private reviewer notes, or sensitive source-system payloads in watcher snapshots.

AI does not own or directly write final:

• findings;
• risks;
• incidents;
• violations;
• controls;
• obligations;
• evidence requirements;
• exceptions;
• lifecycle reviews;
• assurance or authority-facing snapshots.

Those records remain owned by their source modules and governed foundations. Watcher conversion should call an owning-module command or create an approved candidate when that seam exists.

Current Scope

The current watcher workbench manages the durable definition, run, and signal ledger. It can preview sanitized contributor candidates, run active watcher definitions manually, materialize candidates into watcher signals, and create draft watcher report dossiers over non-archived signals. It can also create draft conversion dossiers for individual watcher signals so teams have a reviewable handoff candidate before final owning-module work. Where the target is a governed finding, governed risk, incident, violation, governed control, governed obligation, evidence requirement, governed exception, or assurance engagement, it can create the final record through the governed-findings, governed-risks, incident-management, violation-management, governed-controls, governed-obligations, governed-evidence, governed-exceptions, or governed-assurance command seam and mark the signal converted with refs-only evidence. When enabled by watcher policy, approved model policy, and use authorization, active runs can also add provider-backed correlation metadata to newly materialized signals without storing raw provider output. AI-enabled tenant job runtime can execute due scheduled and hybrid watcher definitions through the same governed run-ledger path, and can create scheduled report dossiers for watchers whose schedule snapshots explicitly enable that behavior. Those scheduled report dossiers can include provider-backed narrative metadata when a separate report-narrative use authorization and approved model are in place.

Event-triggered execution has an application seam for owning modules to call when they expose safe source events. Governed-evidence freshness, governed- monitoring result review, governed-indicator measurement review, and governed- finding remediation review are available as built-in measured-input contributors. Additional source-specific measured inputs, provider-backed AI correlation policies, and concrete conversion actioners depend on the relevant source modules exposing safe seams. Governed-finding, governed-risk, incident, violation, governed-control, governed-obligation, evidence-requirement, and governed-exception, and governed-assurance-engagement conversions are the first built-in direct conversion seams.

Where no safe conversion seam exists, use the watcher signal as a reviewable candidate and route the final work manually through the owning module.

Cloud, Sovereign, And No-AI Profiles

Cloud and Sovereign AI-enabled deployments include AI Watchers inside the optional AI feature bundle.

No-AI Sovereign profiles physically exclude watcher pages, watcher API routes, AI feature schema, and AI runtime code. Customers moving from no-AI to AI-enabled deployments should use the supported upgrade path, configure AI systems/providers/authorizations, and connect source modules before relying on watchers operationally.

Related

• AI Governance Control Plane
• Context & Retrieval
• Decision Dossiers
• Target Appliers
• Use Authorizations
• Action Policies