I kept configuration explicit and local to the project so a report can be traced back to the assumptions that produced it.
Relay searches from the analysed path upward for relay.toml; --config FILE overrides this.
The Python API uses the RelayConfig passed by its caller.
[project].targetis descriptive and[project].entrypointsseeds reachability.[tasks.NAME].everydeclares a desired period.[tasks.NAME].maximum_latencydeclares a response budget.[tasks.NAME].execution_contextrecords the scheduler, thread, loop, core, or process assumption supplied by the user. Relay reports it but does not infer or verify it.[tasks.NAME].safety_critical = trueexplicitly opts that task into critical RLY111 findings. A latency budget alone does not imply emergency or safety-critical logic.[functions].NAMEmaps a task to a source function.[analysis].enableoptionally creates an allowlist;disablealways excludes IDs.[analysis].python_sleep_thresholdcontrols synchronous Python sleep reporting.[analysis].maximum_file_bytes,maximum_files, andmaximum_total_bytesbound analysis.
Durations accept us, ms, s, and m. Unknown configuration keys and unknown rule IDs are
rejected so a typo cannot silently change an analysis. Invalid values fail with exit code 2.
Relay 0.2.4 bundles the JSON Schema introduced in 0.2.1 for the data model
produced after parsing relay.toml:
relay schema config --output relay-config.schema.jsonEditors and integrations can use that file for keys, primitive types, duration syntax, and rule
IDs. Relay remains the final validator because it also enforces relationships between values—for
example, maximum_total_bytes cannot be smaller than maximum_file_bytes.
The schema is versioned with the release and is also available in
src/relay/schemas/relay-config.schema.json.