> For the complete documentation index, see [llms.txt](https://docs.openreview.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openreview.net/reference/api-v2/entities/invitation/dollar-sign-notation.md). # Dollar Sign Notation The dollar sign notation is used to copy values from one field whose path is specified inside the dollar sign notation to the one where the dollar sign notation was specified. The path defined in the field is a relative path and can only refer to fields that are passed when the object is posted or to fields that are generated by the backend before it gets saved to the database. The dollar sign notation is a string has the following format: ```json ${/path/to/other/field/value} ``` Probably the most common and simple example is the one for signatures and Note number. Consider the following simplified **Note Edit Invitation**: ```json { id: "OpenReview.net/Venue_Organizers/-/Submission", signatures: [ "OpenReview.net/Venue_Organizers" ], writers: [ "OpenReview.net/Venue_Organizers" ], invitees: [ "~" ], readers: [ "everyone" ], edit : { signatures: { param: { regex: ".+" } }, readers: [ "OpenReview.net/Venue_Organizers", "${2/signatures}" ], writers: [ "OpenReview.net/Venue_Organizers" ], note: { signatures: [ "OpenReview.net/Paper${2/number}/Authors" ], readers: [ "everyone" ], writers: [ "OpenReview.net/Venue_Organizers", "${3/signatures}", "OpenReview.net/Paper${2/number}/Authors" ], content: { title: { value: { param: { type: "string" } } } } } } } ``` Then a valid **Note Edit** replying to this Invitation will look like this: ```json { signatures: [ "~Test_User1" ], note: { content: { title: { value: "This is a title" } } } } ``` The **final Edit** that will be saved to the database after all values have been resolved will look like this: ```json { signatures: [ "~Test_User1" ], readers: [ "OpenReview.net/Venue_Organizers", "~Test_User1" ], writers: [ "OpenReview.net/Venue_Organizers" ], note: { signatures: [ "OpenReview.net/Paper1/Authors" ], readers: [ "everyone" ], writers: [ "OpenReview.net/Venue_Organizers", "~Test_User1", "OpenReview.net/Paper1/Authors" ], content: { title: { value: "This is a title" } } } } ``` According to the **Note Edit Invitation** there are only 2 fields that the user needs to fill up: `signatures` and the `value` of the `title` because those are the only 2 fields with the `param` keyword. The rest of the field values are populated by what is defined in the Invitation as constants. Refer to the [Specifiers](/reference/api-v2/entities/invitation/specifiers.md) subsection for more information. There are 3 fields that contain the dollar sign notation and 4 values that need to be resolved. Let us start with the one inside `edit/readers/1`. The value `${2/signatures}` means that it will go up twice and then select the value of `edit/signatures`. Note that the value here is `[ "~Test_User1" ]`. The array will replace the value where `${2/signatures}` would be located in the **Note Edit** and then flattened. In a similar way, the value inside `edit/note/writers/1` will be resolved and flattened. The only difference is that the relative path is different, but they resolve to the same value. The other example refers to the field `number`. This field is not defined when the **Note Edit** is posted, because it is created by the backend. However, the field can be referred to when creating the **Note Edit**. The `number` field is the only exception to the rule where all the field values that can be referred to with the dollar sign notation need to be present when the **Note Edit** is posted. As you can see, when the Note number value is resolved it replaces the value of the dollar sign with the number of the Note. ## When the notation is resolved The notation is stored in the Invitation, but nothing is resolved there. It is resolved when an object is posted against that Invitation, and the value it reads is read from **the object being created**, not from the Invitation. This is why the notation can only refer to fields of that object, and why the paths below are the paths of the posted Edit rather than of the Invitation. The Invitation's `edit` block is the template for the object, so translating between the two is mechanical: * The Invitation's leading `edit` is not part of the path. A notation written at `edit/note/content/x/readers/1` in the Invitation sits at `note/content/x/readers/1` in the posted Edit. * A `param` keyword is not part of the path either. A notation written at `edit/note/content/x/value/param/const` occupies `note/content/x/value` in the posted Edit, because that is where the constant ends up. * When an Invitation creates another Invitation, the inner template is kept: `edit/invitation/edit/note/...` in the outer Invitation is `invitation/edit/note/...` in the posted Invitation Edit. ## Working out the number of levels The integer is **not** fixed for a given field name: it counts how far the notation has to travel up from the place where it is written. Two fields that end up with the same value use different integers whenever they sit at different depths, which is the most common source of confusion. Write down the path the value occupies in the posted object, counting every key and every array index as one segment. `${/path}` removes that many segments from the end and appends `path` to what is left. `${0/...}` removes nothing and reads from the same level. Applying this to the **Note Edit Invitation** above: | Notation | Written at, in the Invitation | Path in the posted Edit | After removing the segments | Resolves to | | ----------------- | ----------------------------- | --------------------------- | --------------------------- | ------------- | | `${2/signatures}` | `edit/readers/1` | `readers` / `1` | the root of the Edit | `signatures` | | `${2/number}` | `edit/note/signatures/0` | `note` / `signatures` / `0` | `note` | `note/number` | | `${3/signatures}` | `edit/note/writers/1` | `note` / `writers` / `1` | the root of the Edit | `signatures` | | `${2/number}` | `edit/note/writers/2` | `note` / `writers` / `2` | `note` | `note/number` | Array indices count as segments. `${2/signatures}` and `${3/signatures}` reach the same value only because the first is written two segments below the root of the Edit and the second is written three below it. Removing more segments than the path has is an error, which is the mechanism behind the restriction described at the end of this page: there is nothing above the root of the object being created to reach. ## The same value can have more than one path The number of a submission is a good example. It sits at a different path, and therefore behind a different integer, depending on which form you are customizing. **On the submission form**, the object being created is the submission's own Note Edit, and the number is the Note's `number` field: ```json "readers": [ "Your/Venue/ID/Program_Chairs", "Your/Venue/ID/Submission${4/number}/Authors" ] ``` In the posted Edit the notation sits at `note` / `content` / `` / `readers` / `1`. Removing 4 segments leaves `note`, so it resolves to `note/number`. **On a reply form** (review, meta review, comment, decision), the Invitation you are customizing does not create the reply directly: it creates one per-submission Invitation for each paper, and *that* Invitation creates the reply. The object being posted is therefore an Invitation Edit, and the submission number reaches it as a parameter rather than as a field of a Note: ```json "readers": [ "Your/Venue/ID/Program_Chairs", "Your/Venue/ID/Submission${7/content/noteNumber/value}/Area_Chairs" ] ``` In the posted Invitation Edit the notation sits at `invitation` / `edit` / `note` / `content` / `` / `readers` / `1`. Removing 7 segments lands on the root, and the number is read from `content/noteNumber/value` there. {% hint style="info" %} When you customize a form through the venue request form or the workflow console, you only type the `content` block, but that block is nested inside a complete object when it is posted. Count the segments from that whole object, not from the JSON in the text box. See [Customizing Forms](/getting-started/customizing-forms.md#setting-the-readers-of-a-field) for the full examples. {% endhint %} {% hint style="warning" %} The dollar sign notation cannot refer to values that are at the root of the Invitation. This is because when an object is created, it only has access to its own fields, not to the fields of the Invitation that allows its creation. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.openreview.net/reference/api-v2/entities/invitation/dollar-sign-notation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.