Reference

Stimulus channels.

What a channel taxonomy looks like. Reference template, not a product spec. Copy the form, fill in your own channels.

Why this exists.

Threads tell you what lifecycles your product tracks. Stimulus channels tell you how events arrive on those threads. They are the second artifact a substrate-first team produces.

The point of cataloging channels is to make their differences explicit. A webhook signed by a government gateway is not the same as a parsed inbound email. A button click in your own product is not the same as a free-text complaint scraped from a public forum. The engine needs to know which is which, so routing can respect channel trust.

This page shows you the shape, not the contents. Trust scores are calibration. Copy the structure; do not copy the numbers.

The template.

Every channel that can put events on a thread should be cataloged. New channel, new entry. Trust scores get re-calibrated as incident data accumulates.

channel: {channel.name}
  description: One sentence. What kind of stimulus arrives via this channel?
  shape: event | interaction | heartbeat
    # event       = something happened in the world
    # interaction = a persona pressed an intent button
    # heartbeat   = scheduled tick that fires on absence
  source: who or what emits via this channel
  trust_score: 0.00 - 1.00
    # 1.00 = signed, verified, idempotent, single canonical emitter
    # 0.50 = parsed unstructured input, may be ambiguous
    # 0.10 = open public surface, frequently spammed or spoofed
  identity: how the engine recognizes the emitter
    method: signature | api_key | session | parsed_from_address | none
  threads_affected:
    - {thread.name}: which threads accept events from this channel
  payload_shape: canonical fields the engine extracts
  failure_modes: what goes wrong with this channel and how it's caught
  policy_overrides: actions never auto-routed from this channel, regardless of confidence
  notes: incident history, calibration changes

Nine channel families.

Every channel falls into one of nine families. Cataloging your specific channels is easier when you know which family each belongs to — the template above is filled in similarly across a family.

  1. Signed webhook — an outside system POSTs to your endpoint with a verified signature. Highest trust. (Government gateways, payment processors, identity providers.)
  2. Authenticated API pull — you scrape an outside system on a schedule using a credential they issued. High trust, modulo their uptime.
  3. In-app interaction — a persona inside your product presses a button. Identity is established by your own session. High trust.
  4. Inbound email — a message lands in a mailbox the engine watches. Parsed for intent. Medium trust; identity is parseable from the From: header but spoofable.
  5. SMS reply — a persona replies to a message your system sent. Identity is the phone number. Medium trust.
  6. AI agent emission — an LLM or sub-agent that runs inside the engine produces a stimulus. Trust depends on the model's confidence; engine treats agent output as a stimulus, not a decision.
  7. Scheduled pulse — a heartbeat or cron tick from inside the engine. Highest trust, because the engine itself emitted it.
  8. Sensor / device reading — an IoT device, a scanner, a barcode read, a temperature probe. Trust depends on device authenticity and the physical security of the deployment.
  9. Open public surface — a public form, a chat widget, a parsed forum post. Lowest trust. Identity is whatever the surface volunteers, usually nothing.

Every channel in your product fits one of these. The template fields above are filled in differently per family but the shape is the same.

Trust scores: how to think about them.

Trust score is the engine's prior on whether a stimulus from this channel is what it claims to be. It is not the confidence of the routing decision — that's separate. Trust score modulates how much context the engine needs before it acts.

A signed-webhook stimulus with trust 0.97 can route to automation with relatively little additional enrichment. A parsed-email stimulus with trust 0.55 needs more — cross-reference the customer, check the recent thread history, sanity-check the request against policy — before the engine acts on it. Same event type, different paths through the engine, because the trust prior is different.

Trust scores are calibrated, not assigned. Start with rough numbers, then move them based on incident data. If a channel that you scored 0.85 produced three forged stimuli last quarter, that channel is now 0.60 until you can re-verify. Document the change.

The trust scores on this page are illustrative. Your numbers will differ. The discipline is the same: every channel gets a number, every number gets justified, every adjustment gets recorded.

How to use this.

Walk your product's perimeter. Every external system that can put data into your engine is a channel. Every persona who can interact through a UI is a channel. Every cron job and AI agent that runs inside the engine is a channel.

List them. Assign each one to a family. Fill in the template. Calibrate the trust scores against your incident history (or, if you're new, against your gut, then update quickly).

Pair the stimulus channels reference with a thread catalog. Threads define the lifecycles. Channels define the inputs. Together they describe the surface area the engine has to watch.

Build your own taxonomy.

For help writing a stimulus channels taxonomy for your product, see substrate audits. Or read how we build for the method this artifact lives inside.

Read how we build Read the thread catalog reference