Event Intake

Who the node is. The id is the key the DOT pins.

id

event-intake

name

Event Intake

type

tool

phases

none declared

What it does, and the prose the agent is handed when the graph runs.

action27 words

Accept an inbound event from the ticket queue or the alert bus, stamp it with a correlation id, and drop anything that repeats inside the dedupe window.

spec117 words

Take the raw payload the ticket queue or the alert bus handed you and turn it into exactly one event record. Attach a correlation id that will stay with this item for the rest of the run, record which source it arrived on and the time it arrived, and leave the payload itself untouched, you normalise the envelope, never the contents. Compare the record against the ones you admitted in the last 120 seconds and admit nothing that repeats one of them: a duplicate is dropped here and emitted nowhere. Emit the admitted record on event, and treat yourself as done when either one record has gone out or the item has been dropped as a repeat.in full above

model

whatever the graph supplies

agent

not named

skill

skills/event-intake.md

tools

none

mcp

none

params

sources: ["ticket-queue","alert-bus"], dedupe_window_s: 120

What arrives, what leaves, which nodes it expects to hear from, and what may not.

inputs

none

outputs

event : json

dependencies

none

cannot

no type is refused

will_not

change the payload it admits, admit a record that repeats one inside the dedupe window

The keys the static analysis reads. Nothing here instructs the agent.

risk_markers

none

notes49 words

A support ticket and a production alert are the same shape at this boundary, payload, source, timestamp, which is why both support lines start here. No lupo/pii-handling marker: a shared card may only claim the risks that hold in every blueprint pinning it, and an alert payload carries none.

The card's own version, and who wrote it.

version

1.0.0

author

autogen

provenance

not stated