Current pilot capabilities
OROTOV currently detects evidence drift when an issue lacks the evidence required by its lane. Review and test detection remain pre-GA; broader checks are roadmap work.
The control loop
OROTOV observes configured sources, checks evidence against the work policy, and routes a detected gap to a person or agent to resolve.
In the pilot, an operator-configured GitHub App receives signed repository events and records them in a replayable event stream with connector provenance.
Evidence records retain their source. A person or agent claim stays Claimed; a connector can observe an artifact, and an independent system can verify an outcome.
Evidence drift detection creates board work when a lane requirement is missing. A person or agent must claim and resolve that work; OROTOV does not change customer systems automatically.
Private pilot: Evidence drift detection and remediation dispatch are implemented. GitHub observation requires an operator-configured App. Evidence checks run only where the deployment policy enables them.
Current and pre-GA detection
Evidence drift detection and dispatch are implemented in the private pilot. Review and test detectors remain under pre-GA evaluation and are not generally available.
What this check means
An issue reaches its terminal state without the evidence its lane requires.
Compare completed work with its lane policy, then create a board issue for the team to claim and resolve.
Evidence drift detection and remediation dispatch are implemented. GitHub observation requires an operator-configured App, and deployment policy controls where evidence checks run.
What this check means
A change merges without the approval required by the team.
Compare configured GitHub review events with the approval rule, then route any unresolved gap as board work.
This detector is not generally available. The GitHub App must be configured by an operator, and the connector-backed workflow needs release validation.
What this check means
Implementation changes without the expected test evidence for the affected work.
Compare observed code changes with the test evidence required by the issue and route a gap for review.
This detector is not generally available. It depends on connector-observed changes and further validation of the comparison rules.
Roadmap
These checks need new observed inputs, validated comparison rules, or production telemetry before they can be offered.
Roadmap
Mechanical basis: run existing architecture rules against connector-observed diffs.
Prerequisite: a connector-backed reconciler and release validation beyond the legacy rule engine.
Roadmap
Mechanical basis: compare a completed issue with incomplete blocked-by predecessors in the issue-link graph.
Prerequisite: connector-backed reconciliation and validated dependency rules.
Roadmap
Mechanical basis: compare an approved specification with observed implementation behavior.
Prerequisite: observed implementation inputs and evidence-grounded semantic evaluation.
Roadmap
Mechanical basis: compare observed implementation changes with relevant documentation changes.
Prerequisite: observed diffs, documentation mapping, and semantic evaluation for ambiguous cases.
Roadmap
Mechanical basis: compare significant engineering events with knowledge graph writes.
Prerequisite: broader observed event inputs and a validated knowledge projector.
Roadmap
Mechanical basis: compare context-package timestamps with observed changes that can invalidate them.
Prerequisite: observed change events, package lineage, and revalidation rules.
Roadmap
Mechanical basis: correlate incidents or telemetry with a previously verified change and demote its evidence.
Prerequisite: deployment, telemetry, and incident inputs that OROTOV does not yet ingest.
Begin with observable work
Detection creates work for a person or agent to claim. It does not change a customer system automatically.