These are the short workflows I use when showing Relay to someone for the first time. Start with the smallest one that matches what you are reviewing, then follow the evidence back into the source.
Run relay check sketch.ino --suggest. Start with direct RLY101, RLY107, and RLY109 findings,
then inspect estimated call paths. In a structural-language report these findings are
capped to medium confidence, even when the syntax match itself is direct. I prefer changing one
blocking sequence at a time and rerunning Relay so the effect stays easy to explain.
Run relay check . and read the ANALYSIS MODELS header first. Python receives AST-based,
file-local analysis; C/C++, JavaScript, TypeScript, Java, C#, Go, Rust, Kotlin, Swift, Ruby, and
PHP receive explicitly structural analysis. Compare findings within each model rather than
assuming identical semantic depth.
Run relay init, map each task name to its actual function, and specify realistic periods or
latency budgets, execution contexts, and safety_critical flags. Use
relay summary PATH --duration 5s to communicate declared periods and reachable waits. I thought
about making contracts automatic, but explicit names and budgets are easier to audit.
Use relay check src --format sarif --output relay.sarif --fail-on high. A status of 1 means a
finding met the threshold; 2 means invocation or configuration failed. This distinction lets CI
separate “Relay found something” from “Relay could not complete the analysis.”