Summary

• Adds a Seed predictability and trigger choice section to both the TS and Go "Using Randomness in Workflows" guides, explaining that the per-execution seed has no secret mixed in and breaking down predictability by trigger type (Cron: publicly known schedule; EVM Log: as safe as the chain's block production; HTTP: safe only as long as the authorizedKeys signing key stays private).
• Adds a Choosing between CRE randomness and Chainlink VRF section giving concrete guidance on which use cases fit CRE's consensus-based randomness (operational/non-adversarial flows) versus when to use VRF (public draws with direct economic value, where a cryptographic proof of fairness is required).
• Notes a commit-reveal mitigation for teams that need to stay adversarial-resistant on an otherwise grindable/front-runnable trigger.
• Clarifies that CRE's onchain result is accepted via a valid DON signature (attestation of consensus), not a mathematical correctness proof the way VRF's is.
• Updates the TL;DR aside and FAQ answer in both guides to point to the new sections.

Why

Today's guides describe how to generate randomness but don't tell users how predictable that randomness actually is, or when CRE's trust model is/isn't appropriate for a given use case. This fills that gap so users can make an informed choice up front rather than discovering the limitation after shipping an adversarial-facing draw.