Recognize changes and new events

Watch a version change

Save this as version.yaml. Push {"version":"1.0"} and then {"version":"1.1"} to /v1/ingest/deployed-version with fresh idempotency keys. The first input establishes a baseline; the second records a changed event.

apiVersion: ding.ing/v1alpha1
kind: Destination
metadata: {id: console}
spec: {type: console}
---
apiVersion: ding.ing/v1alpha1
kind: Watch
metadata: {id: deployed-version, name: Deployed version}
spec:
  source: {type: push, fields: {version: version}}
  condition: {field: version, operator: changed}
  policy: {trigger: level, interval: 0s}
  destinations: [{ref: console, events: [changed]}]

Download the manifest. Validate and apply it through the normal review flow. Baselines preserve types: the string "1" differs from the number 1. Missing fields are unknown; null is a value. Baselines survive restart and unknown observations.

Deduplicate provider events

apiVersion: ding.ing/v1alpha1
kind: Destination
metadata: {id: console}
spec: {type: console}
---
apiVersion: ding.ing/v1alpha1
kind: Watch
metadata: {id: provider-events}
spec:
  source:
    type: push
    jq: .events[]
    fields:
      id: id
      status: status
      time: timestamp
    observedAtField: time
  condition:
    field: id
    operator: new-event
    dedupFor: 24h
  policy: {trigger: level, interval: 0s}
  message: '{{.Watch}} saw {{.Value}}'
  destinations: [{ref: console, events: [new-event]}]

Download the provider-event manifest. The provider must supply stable string IDs. This example accepts an events array, selects fields, and emits each new ID once within a 24-hour deduplication horizon. Repeated sightings do not extend that horizon. After expiry an ID may emit again.

Both changed and new-event use level policy with an explicit interval; they do not open recovery incidents. Resource exhaustion becomes unknown rather than silently evicting still-valid state. Provider access and upstream calculations remain your responsibility.