diff --git a/beps/0009-scaffolder-templating-in-parameters/README.md b/beps/0009-scaffolder-templating-in-parameters/README.md
index 450538ab8a..d5fc78497c 100644
--- a/beps/0009-scaffolder-templating-in-parameters/README.md
+++ b/beps/0009-scaffolder-templating-in-parameters/README.md
@@ -167,6 +167,20 @@ This is a pretty ugly workaround, but maybe the only option we have. Also at thi
 
 Perhaps we just accept this as a limitation, and document it as such.
 
+Templating for `errorMessages` has been solved by using the `ajv-errors` library https://github.com/backstage/backstage/pull/25624, you can see more about [backrefs and pointers here](https://ajv.js.org/packages/ajv-errors.html). Any other template strings that will be passed through the underlying components and to be left untemplated should be encapsulated with options instead of passing through raw strings. The below example illustrates an `entityAndName` format, which under the hood, might do something like `${{ parameters.entity }} - ${{ parameters.name }}`, but this implementation never leaks out to the templating language.
+
+```yaml
+parameters:
+  properties:
+    ...
+    description:
+      type: string
+      default: Test-description
+      ui:field: CustomDisplayField
+      ui:options:
+        format: entityAndName
+```
+
 ## Release Plan
 
 <!--
@@ -194,4 +208,9 @@ information to express the idea and why it was not acceptable.
 #### Templating client side
 
 - This could lead to confusion as `filters` such as `parseRepoUrl` and `pick` and any custom filters which you define in the backend would not be available in the client side.
+
 - Also with the limitations of the `default` value being updated only on first render and never re-evaluated, there's no performance benefit of doing things client side anymore.
+
+```
+
+```