AutomationConfig
Each brand’s workflow binding holds a JSONAutomationConfig that drives all behavior. This is
what makes one workflow serve every brand.
A binding for one brand, with every section above populated:
Skip rules
Skip rules cause an early exit with no response generated. They are evaluated in order and the first matching rule wins.chrono-tz, so a brand’s hours behave correctly
across clock changes rather than drifting by an hour twice a year.
Escalation rules
Pattern-based detection of sensitive topics in ticket text.
The regex cache is bounded at 512 entries with a 10KB pattern limit, so a pathological config
can’t exhaust memory.
Environment
Temporal and API
Control plane
AppConfig::validate() runs at startup in both the API and worker, so an invalid configuration
fails fast rather than surfacing as a runtime error later.
Dashboard
A minimal working environment for a local worker and API:
Logging
Structured JSON logging viatracing and tracing-subscriber, configured by RUST_LOG.
AppConfig::validate() runs at startup in the API and the worker, so a
malformed value stops the process rather than surfacing later as a failed
workflow. If the worker exits immediately after a config change, read the
first line of its log — the reason is there, not in Temporal.Next steps
ResponseAutomationV2
The workflow every value above steers.
Control plane
Authoring and syncing these configs across brands.
Operations
Running the engine, and what to check when a config change lands badly.
Policy engine
Where escalation rules meet the verified-decision gate.