Ops Rule Detectors

Rules are the hidden detector layer below anomaly.

They are not a tenth graph hub and they are not arbitrary JavaScript. A rule is a stored JSON program:

normalized evidence adapter
  -> deterministic condition DSL
  -> finding
  -> optional promotion to anomaly/event

Runtime Programming Model

Rules are edited through the Ops API and stored in D1. A future Git checkpoint can serialize selected rules into ops/rules/*.yaml, but runtime truth is the database record.

Rule fields:

• observes: names a normalized adapter such as events.summary, anomalies.search, connectors.summary, or graph.ops.
• condition: a small expression tree with all, any, not, and path/op/value checks.
• anchors: the canonical expectation target. A rule must specify violatesBehaviourIds or challengesIdeaIds, otherwise it cannot create an anomaly.
• creates: templates for finding fingerprint, anomaly title/detail, event title/type, and touched implementations.
• promotion: manual by default, auto when repeated matching should promote immediately.

Noise Control

A rule hit is a finding first. Findings are fingerprinted per rule so repeated matches update one row instead of flooding Ops with new anomalies or events.

An event is only created when a finding is promoted into an anomaly. Repeated evaluations reuse the same stable anomaly/event ids unless the rule fingerprint changes.

Canonical Graph Contract

The rule itself stays evidence/backing. The promoted records use the normal hub relationships:

Anomaly VIOLATES Behaviour
Anomaly CHALLENGES Idea
Anomaly RAISES Event
Infra EXPLAINS Anomaly
Event TOUCHES Implementation
Journal INTERPRETS Event

Generic canonical edges are exposed through POST /graph/edges and validated against @cv/graph before they can enter D1.