> ## Documentation Index > Fetch the complete documentation index at: https://docs.prelude.so/llms.txt > Use this file to discover all available pages before exploring further. # List the signals a rule can read > **Beta.** The request and response shapes may still change. List the Prelude signals a rule expression may reference, and the functions it may call beyond CEL's own operators and standard functions. A signal is a name Prelude resolves for the evaluation being scored, and it means the same thing for every customer. Write it in an expression and compare it like any other value of its type. Prelude provides these names. The rest of a rule's vocabulary is yours - the `signal.ext.` names your rules read off an evaluation and the `param.` names a recipe is configured with - and those do not appear here. A signal may be absent from an evaluation, whatever its type. A rule that reads a signal that did not arrive reports `NOT_EVALUATED` rather than treating the missing value as a zero. Prelude publishes the catalog progressively, so this listing grows over time. Write rules against what it returns: a signal it does not list is one Prelude has not committed to, and it can change or be removed without notice. A signal is a name Prelude resolves for the evaluation being scored: a fact about the request, the device, or the number that Prelude determines for you. Every customer gets the same signals, and each one means the same thing for all of them. Each entry is listed under the `signal.` identifier a rule writes it as, so `name` is what you put in an expression. ## Functions The listing also documents the functions a rule can call beyond CEL's own operators and standard functions: the network, string, list, set and regex extensions. Each function has its `signatures`, a `description` of what it returns, and `examples` you can copy into a rule. Each example is a valid rule expression. ## Your own values are separate A rule can also read your own signals, as `signal.ext.`, and the `param.` names its recipe is configured with. Those belong to you and they are not listed here. They are kept apart from the listed signals, so nothing Prelude adds to this listing can collide with a name of yours. ## An absent signal is not a zero Any signal can be missing from a given evaluation. A rule that reads a signal that did not arrive reports `NOT_EVALUATED` instead of scoring. It does not read the absence as `false`, as `0`, or as an empty string. Write the condition you mean, and let the engine report the absence. ## The listing grows Prelude publishes the catalog progressively, so this listing grows over time. Treat it as the supported vocabulary: a `signal.` name it does not list does not resolve in a rule of yours, and an expression referencing one is refused with ``Unsupported signal `signal.` ``. ## OpenAPI ````yaml get /v2/watch/management/rules/catalog openapi: 3.1.0 info: title: Prelude API version: 2.0.0 description: The Prelude API allows you to send messages to your users. contact: email: support@prelude.so servers: - url: https://api.prelude.dev description: Production server security: - apiToken: [] tags: - name: Notify description: Send transactional and marketing messages with compliance enforcement. - name: Transactional description: Send transactional messages (deprecated - use Notify API instead). - name: Verify description: Verify phone numbers. - name: Watch description: Evaluate email addresses and phone numbers for trustworthiness. - name: Lookup description: >- Retrieve detailed information about a phone number including carrier data, line type, and portability status. paths: /v2/watch/management/rules/catalog: get: tags: - Watch summary: List signals description: >- **Beta.** The request and response shapes may still change. List the Prelude signals a rule expression may reference, and the functions it may call beyond CEL's own operators and standard functions. A signal is a name Prelude resolves for the evaluation being scored, and it means the same thing for every customer. Write it in an expression and compare it like any other value of its type. Prelude provides these names. The rest of a rule's vocabulary is yours - the `signal.ext.` names your rules read off an evaluation and the `param.` names a recipe is configured with - and those do not appear here. A signal may be absent from an evaluation, whatever its type. A rule that reads a signal that did not arrive reports `NOT_EVALUATED` rather than treating the missing value as a zero. Prelude publishes the catalog progressively, so this listing grows over time. Write rules against what it returns: a signal it does not list is one Prelude has not committed to, and it can change or be removed without notice. operationId: listWatchSignals responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/WatchCatalogResponse' '400': description: KO content: application/json: schema: $ref: '#/components/schemas/Error' components: schemas: WatchCatalogResponse: type: object properties: signals: type: array items: $ref: '#/components/schemas/WatchSignal' functions: type: array items: $ref: '#/components/schemas/WatchFunction' description: The functions a rule expression may call beyond CEL's own. required: - signals - functions Error: type: object properties: code: type: string description: The error code. examples: - invalid_phone_number message: type: string examples: - >- The provided phone number is invalid. Provide a valid E.164 phone number. description: A human-readable message describing the error. type: type: string examples: - bad_request description: The error type. request_id: type: string examples: - 3d19215e-2991-4a05-a41a-527314e6ff6a description: >- A string that identifies this specific request. Report it back to us to help us diagnose your issues. param: type: string examples: - phone_number description: The parameter the error refers to, when it applies to a single one. required: - code - message - type WatchSignal: type: object properties: name: type: string description: The identifier to write in a rule expression. examples: - signal.ip type: type: string enum: - bool - int - double - string description: The CEL type the signal compares as. examples: - bool description: type: string description: What the signal means. examples: - >- The end user's IP address: the one sent with the evaluation request, or the one the Prelude SDK collected. required: - name - type - description WatchFunction: type: object properties: name: type: string description: The name to write in a rule expression. examples: - net.inCIDR description: type: string description: What the function returns. examples: - >- Returns true if the IP address is in one of the CIDR ranges, false otherwise. An empty or invalid IP address returns false. An invalid CIDR range is an error. signatures: type: array items: type: string description: >- Each form the function can be called in. `.charAt()` is called on a string, `sets.contains(, )` on its own. examples: - - net.inCIDR(, >) -> examples: type: array items: type: string description: >- Rule expressions that call the function. Each one returns a boolean and is valid as a rule expression. examples: - - net.inCIDR(signal.ip, ["203.0.113.0/24", "2001:db8::/32"]) required: - name - description - signatures - examples securitySchemes: apiToken: type: http scheme: bearer ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.