Customer Automation

The catalog is the product's promise surface: every tenant rule is built from it. Each entry as a record pins what it does, what it costs, and what it refuses, so tenant rules compose from parts the team stands behind.

The action invoice.send-reminder is a record stating its rate cap and its suppression rule.

Reviewed forEach catalog trigger, condition, and action is present as a record.

Marked guidance: a reviewer answers this question.

Tenants write thousands of rules the team never sees, and recording each one would halt both sides. The catalog carries the records instead: instances compose only catalog entries, so the unrecorded part is the composition, never the parts.

A tenant's rule remind overdue invoices every Monday is stored data, while its trigger, condition, and action each point at catalog entries.

Reviewed forTenant instances live in tenant storage with none as a record.

Marked guidance: a reviewer answers this question.

A renamed or retired entry lingers in old instances, and a crafted request can name entries that never existed. Refusing unknown entries keeps every running rule inside the catalog instead of executing a name nobody defined.

An instance naming the retired trigger expense.submitted is refused with the catalog's current trigger list.

Reviewed forThe instance tests refuse entries outside the catalog with the current catalog in the refusal.

Marked guidance: a reviewer answers this question.

Catalog entries evolve: a condition gains an operator, an action changes its payload. Versions pin each instance to the behavior it was composed against, so an entry upgrade never silently rewrites running tenant rules.

The condition order.total-above moves from version 3 to version 4, and existing instances keep running version 3 until the tenant re-saves.

Reviewed forEach catalog entry carries a version, and the stored instances cite the version they run.

Marked guidance: a reviewer answers this question.

A customer endpoint is built by strangers against the hook's word. The may contract states the payload shape, the retry count and spacing, the timeout, and the signature, so the endpoint is written against facts instead of guesses.

The hook invoice.paid states three retries spaced a minute apart, a ten-second timeout, and an HMAC signature header.

Reviewed forEach hook record lists payload, retries, timeout, and signature for its customer endpoint.

Marked guidance: a reviewer answers this question.

What the contract omits, customers invent: they assume order, instant delivery, and payloads that never grow. The may-not contract closes those gaps up front, so a hook that fires twice or arrives late breaks no promise.

The hook invoice.paid states that deliveries may repeat, may arrive out of order, and carry no line-item detail.

Reviewed forEach hook record lists the ordering, timing, and payload bounds its endpoint leaves unassumed.

Marked guidance: a reviewer answers this question.

The trigger's work is done before the hook fires: the invoice is paid, the expense is reimbursed. Failing the trigger because a customer endpoint timed out punishes the product for a stranger's outage. The hook records its own outcome and retries on its own schedule.

A hook call that times out is retried three times and then logged as failed, while the paid invoice stays paid.

Reviewed forThe hook tests fail the endpoint while the trigger outcome stays unchanged.

Marked guidance: a reviewer answers this question.