Automation builder
Start from one Guard trigger, one destination, and one visible run history.
Builder
Guided automation
Guard should teach one useful workflow first instead of dropping users into a blank orchestration canvas.
Trigger
Investigation changes owner or status
Scope
Choose which Guard work should route automatically.
Destination
Pick the external workflow tool.
Broadcast Guard state changes
Emit a normalized Guard event into the tool your team already uses.
Run history
Recent automation runs
Run history should show where Guard routed work, what succeeded, and what needs operator attention.
Explain this route
Trust, privacy, and decision boundaries
Operators should understand what proof exists, what stays local, and why Guard is asking for attention before acting.
Proof & provenance
The builder only earns trust when each enabled rule still links back to Guard investigations, run history, and a visible destination.
- 100% local by default
- First-party canary fixtures
- Receipts on your device
What stays local versus what syncs
The runtime still creates the evidence locally. The builder is the cloud coordination layer that routes that evidence into shared systems without hiding ownership.
- Harness discovery and artifact snapshots
- Local diffs against your last approved state
- Receipt sync to Guard Cloud
- Curated advisory and revocation feeds
How Guard decides on this route
Automation setup should stay tightly scoped to the Guard trigger, destination, and operator review point that actually reduce response time.
- Prompts should appear only after real drift, queue pressure, or policy mismatch.
- Local protection stays useful on its own before cloud coordination is added.
- Every CTA should land on the exact queue or detail view that explains the state.