diff --git a/LearnJsonEverything/wwwroot/data/lessons/path.json b/LearnJsonEverything/wwwroot/data/lessons/path.json
index 9215311..371ef6d 100644
--- a/LearnJsonEverything/wwwroot/data/lessons/path.json
+++ b/LearnJsonEverything/wwwroot/data/lessons/path.json
@@ -772,7 +772,7 @@
     "id": "616e2915-a7cf-41a6-be40-ae62965479b3",
     "skip": false,
     "title": "JSON Path: Filter Functions - match() & search()",
-    "background": "The `match()` and `search()` functions evaluate a string against a regular expression.\r\n\r\nRegular expressions follow the new I-Regexp specification, [RFC 9485](https://www.rfc-editor.org/rfc/rfc9485.html).  Because regular expression support is so widely varied across languages, this specification was developed to define a minimally compatable feature set that _should_ be supported by most languages.  This feature set is what is expected to be supported by all implementations.  Though implementations can choose to support more, such support might not be interoperable.\r\n\r\nThe `match()` function interprets the regular expression as \"implicitly anchored\", meaning that the start `^` and end `$` constraints are implied.  This results in only exact matches.  This behavior comes primarily from JSON Path's roots in XPath.\r\n\r\nThe `search()` function interprets the regular expression as \"explicitly anchored\", meaning that the user must specify the start `^` and end `$` of the string within the expression.  This is the more common usage seen across the internet today, as supported by https://regex101.com/ and many other online interpreters.\r\n\r\nBoth functions take two value parameters, the string content and the regular expression (in that order), and return a boolean **true** if the content matches the regular expression and boolean **false** if it doesn't.\r\n\r\nIf either parameter is not a string, `Nothing` is returned.  (Parsing can only check that values are provided; it cannot check that the values are strings.)\r\n\r\nAs with other functions, these values may be supplied by literals, singular paths, or other functions which return the appropriate values.",
+    "background": "The `match()` and `search()` functions evaluate a string against a regular expression.\r\n\r\nRegular expressions follow the new I-Regexp specification, [RFC 9485](https://www.rfc-editor.org/rfc/rfc9485.html).  Because regular expression support is so widely varied across languages, this specification was developed to define a minimally compatable feature set that _should_ be supported by most languages.  This feature set is what is expected to be supported by all implementations.  Though implementations can choose to support more, such support might not be interoperable.\r\n\r\nThe `match()` function interprets the regular expression as \"implicitly anchored\", meaning that the start `^` and end `$` constraints are implied.  This results in only exact matches.  This behavior comes primarily from JSON Path's roots in XPath.\r\n\r\nThe `search()` function interprets the regular expression as \"explicitly anchored\", meaning that if the user wants to anchor the start `^` and/or end `$` of the expression they must include those characters.  This is the more common usage seen across the internet today, as supported by https://regex101.com/ and many other online interpreters.\r\n\r\nBoth functions take two value parameters, the string content and the regular expression (in that order), and return a boolean **true** if the content matches the regular expression and boolean **false** if it doesn't.\r\n\r\nIf either parameter is not a string, `Nothing` is returned.  (Parsing can only check that values are provided; it cannot check that the values are strings.)\r\n\r\nAs with other functions, these values may be supplied by literals, singular paths, or other functions which return the appropriate values.",
     "docs": "path/basics",
     "api": null,
     "schemaDocs": null,