From f709240bf29be743a1ca78c2e34445a9f11464a9 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Mon, 17 Nov 2025 12:05:41 +0100 Subject: [PATCH 01/11] docs: :memo: explain why we call it "check", not "validate" --- docs/design/architecture.qmd | 65 ++++++++++++++++++++++++++++++++++-- 1 file changed, 63 insertions(+), 2 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index ee7559a1..356b7787 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -39,6 +39,67 @@ things consistent. However, we also introduce some new terms and concepts specific to `check-datapackage`. The main objects and actions used throughout the package can be found in the tables below. +### Why "check" and not "validate"? + +If you have ever searched for tools that check something against a +specification, you'll often see the word "validate". And you might +notice that we never use the word "validate" in our package and +documentation. This is intentional. + +While the word is ubiquitous in programming, it often doesn't actually +mean what these tools do. What these tools often do is *verify*, +*check*, or *confirm* that something matches some explicitly described +expectation or specification. There are many websites and articles +comparing the difference between validate and verify, and we won't get +into a detailed explanation here. For a good overview, see the Wikipedia +on this topic in +[general](https://en.wikipedia.org/wiki/Verification_and_validation) and +on +[software](https://en.wikipedia.org/wiki/Software_verification_and_validation) +specifically. + +Briefly, to "validate" something means to ask the question of "are we +building the right product". To "verify" something is asking the +question "are we building the product right". The key difference is +where the word "right" is placed. + +"Validate" is in the overlapy between human need and a product that +solves that need. Are we actually solving the right problem? To answer +that question depends heavily on human judgement and context. Meanwhile, +"verifying" is to ensure that the product is being built well, based on +best practices, regulations, and specifications. It is about the quality +of the product, not whether it fulfills the human need. Usually, +verification can be automated as long as there is a formal and clear +specification to compare against. Validate on the other hand requires +regular human review and input to confirm, "does this still solve the +right need?" + +Sometimes, these two overlap, but often they don't. For example, if you +are involved in creating a specification that accurately describes +something that will solve a need you have, then you are both validating +and verifying the product that you will build. However, if someone else +takes your specification to help them build their own product and they +don't seek our extensive validation from the humans who will use that +product, they are now likely verifying their product, rather than +validating it. + +For many generic software tools that do checks, they often use the word +"validate". For example, in the +[`frictionless`](https://pypi.org/project/frictionless/) package, they +have a command called +["validate"](https://framework.frictionlessdata.io/docs/guides/validating-data.html). +Even widely used tools like +[Pydantic](https://docs.pydantic.dev/latest/) use the word "validate". +However, without knowing the human context, what they are most likely +doing is verifying that something matches some other specification or +expectation. Most of these software tool that "validate" can't know if +they are truly "validating" something since only human judgement and +review can answer that. We can, however, be sure that we're verifying or +checking something. + +So, this is the reason we called the package `check-datapackage` and not +`validate-datapackage`. + ### Objects | Object | Description | @@ -78,8 +139,8 @@ Data Package standard. `check-datapackage` receives the definitions of the Data Package descriptor's structure---including properties that [must or should](https://datapackage.org/standard/data-package/#language) be -included and their formats---from the Data Package standard (version 2). The -standard provides this information through versioned JSON Schema +included and their formats---from the Data Package standard (version 2). +The standard provides this information through versioned JSON Schema profiles that define required properties and textual descriptions that outline compliance. From bda828142fead4b51425ab362dc8edf89089c56f Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Tue, 18 Nov 2025 09:24:28 +0100 Subject: [PATCH 02/11] docs: :pencil2: some minor edits for clarity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Signe Kirk Brødbæk --- docs/design/architecture.qmd | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 356b7787..256b85f2 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -43,15 +43,14 @@ used throughout the package can be found in the tables below. If you have ever searched for tools that check something against a specification, you'll often see the word "validate". And you might -notice that we never use the word "validate" in our package and +notice that we don't use the word "validate" in our package and documentation. This is intentional. -While the word is ubiquitous in programming, it often doesn't actually -mean what these tools do. What these tools often do is *verify*, -*check*, or *confirm* that something matches some explicitly described +Although the word is ubiquitous in programming, it's often used loosely and in ways that deviate +from its actual meaning. Tools that describe themselves as "validating" something often, in practice, *verify*, +*check*, or *confirm* that something matches a defined expectation or specification. There are many websites and articles -comparing the difference between validate and verify, and we won't get -into a detailed explanation here. For a good overview, see the Wikipedia +comparing the difference between validate and verify. For a good overview, see the Wikipedia on this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and on @@ -63,7 +62,7 @@ building the right product". To "verify" something is asking the question "are we building the product right". The key difference is where the word "right" is placed. -"Validate" is in the overlapy between human need and a product that +"Validate" is in the overlap between human need and a product that solves that need. Are we actually solving the right problem? To answer that question depends heavily on human judgement and context. Meanwhile, "verifying" is to ensure that the product is being built well, based on From 01dd13023ce4786cbf6b57743300220c34a3b659 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Tue, 18 Nov 2025 11:40:36 +0100 Subject: [PATCH 03/11] docs: :pencil2: simplify based on review comments --- docs/design/architecture.qmd | 50 +++++++++++++++++++----------------- 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 256b85f2..7e276ec4 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -39,39 +39,35 @@ things consistent. However, we also introduce some new terms and concepts specific to `check-datapackage`. The main objects and actions used throughout the package can be found in the tables below. -### Why "check" and not "validate"? +### "Check" (vs "validate") If you have ever searched for tools that check something against a specification, you'll often see the word "validate". And you might notice that we don't use the word "validate" in our package and documentation. This is intentional. -Although the word is ubiquitous in programming, it's often used loosely and in ways that deviate -from its actual meaning. Tools that describe themselves as "validating" something often, in practice, *verify*, -*check*, or *confirm* that something matches a defined -expectation or specification. There are many websites and articles -comparing the difference between validate and verify. For a good overview, see the Wikipedia -on this topic in +Although the word is ubiquitous in programming, it's often used loosely +and in ways that deviate from its actual meaning. Tools that describe +themselves as "validating" something often, in practice, *verify* that +something matches a defined expectation or specification. There are many +websites and articles comparing the difference between validate and +verify. These two verbs often are done during quality control or +assurance stages of building products and after are simplified to "V&V". +For a good overview, see the Wikipedia on this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and on [software](https://en.wikipedia.org/wiki/Software_verification_and_validation) specifically. -Briefly, to "validate" something means to ask the question of "are we -building the right product". To "verify" something is asking the -question "are we building the product right". The key difference is -where the word "right" is placed. - -"Validate" is in the overlap between human need and a product that -solves that need. Are we actually solving the right problem? To answer -that question depends heavily on human judgement and context. Meanwhile, -"verifying" is to ensure that the product is being built well, based on -best practices, regulations, and specifications. It is about the quality -of the product, not whether it fulfills the human need. Usually, -verification can be automated as long as there is a formal and clear -specification to compare against. Validate on the other hand requires -regular human review and input to confirm, "does this still solve the -right need?" +To "validate" is to assess the overlap between a human need and a +product that solves that need. It answers the question "are we correctly +solving the actual problem"? To "verify" is to ensure that the product +is being built correctly and with high quality, based on best practices, +regulations, and specifications. It answers the question "are we +developing the solution correctly"? An easy way to tell them apart is +that you can often make the verification process automatic, while you +often need to have extensive manual evaluation, judgment, and review for +the validation process. Sometimes, these two overlap, but often they don't. For example, if you are involved in creating a specification that accurately describes @@ -96,8 +92,14 @@ they are truly "validating" something since only human judgement and review can answer that. We can, however, be sure that we're verifying or checking something. -So, this is the reason we called the package `check-datapackage` and not -`validate-datapackage`. +Unfortunately, "verify" and "validate" are often used interchangeably +and are difficult to distinguish between their two meanings. This may be +due to the similarity in their spelling and pronunciation. For that +reason, we decided to use neither word. Instead we wanted to use a more +common word, that accurately reflects what we want this package to do +while also being generic enough to encompass different uses. So we went +with "check", since we "check" that the metadata is correct (based on +the specification). ### Objects From eeeea8b152d12cd3f54ccfc31b9fcd1447e1d971 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Tue, 18 Nov 2025 11:58:21 +0100 Subject: [PATCH 04/11] docs: :pencil2: small clarification to language --- docs/design/architecture.qmd | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 7e276ec4..01aaf4cd 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -60,14 +60,14 @@ on specifically. To "validate" is to assess the overlap between a human need and a -product that solves that need. It answers the question "are we correctly -solving the actual problem"? To "verify" is to ensure that the product -is being built correctly and with high quality, based on best practices, -regulations, and specifications. It answers the question "are we -developing the solution correctly"? An easy way to tell them apart is -that you can often make the verification process automatic, while you -often need to have extensive manual evaluation, judgment, and review for -the validation process. +product that solves that need. It answers the question "have we selected +the correct solution to solving the actual problem"? To "verify" is to +ensure that the solution is being built correctly and with high quality, +based on best practices, regulations, and specifications. It answers the +question "are we developing the solution correctly"? An easy way to tell +them apart is that you can often make the verification process +automatic, while you often need to have extensive manual evaluation, +judgment, and review for the validation process. Sometimes, these two overlap, but often they don't. For example, if you are involved in creating a specification that accurately describes From 0835a19cfd2bc2ea81ced0991dcad41ef0482fd4 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Wed, 19 Nov 2025 08:45:40 +0100 Subject: [PATCH 05/11] Update docs/design/architecture.qmd MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Signe Kirk Brødbæk --- docs/design/architecture.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 01aaf4cd..cc907e4c 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -39,7 +39,7 @@ things consistent. However, we also introduce some new terms and concepts specific to `check-datapackage`. The main objects and actions used throughout the package can be found in the tables below. -### "Check" (vs "validate") +### "Why "check" (and not "validate" or "verify")? If you have ever searched for tools that check something against a specification, you'll often see the word "validate". And you might From d723b7000b89eff28daaa4f99a491922cf08be14 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Wed, 19 Nov 2025 08:46:41 +0100 Subject: [PATCH 06/11] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Signe Kirk Brødbæk --- docs/design/architecture.qmd | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index cc907e4c..1ddde577 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -51,8 +51,8 @@ and in ways that deviate from its actual meaning. Tools that describe themselves as "validating" something often, in practice, *verify* that something matches a defined expectation or specification. There are many websites and articles comparing the difference between validate and -verify. These two verbs often are done during quality control or -assurance stages of building products and after are simplified to "V&V". +verify. These two verbs are often used during the quality control or +assurance stages of building products. For a good overview, see the Wikipedia on this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and on @@ -65,8 +65,8 @@ the correct solution to solving the actual problem"? To "verify" is to ensure that the solution is being built correctly and with high quality, based on best practices, regulations, and specifications. It answers the question "are we developing the solution correctly"? An easy way to tell -them apart is that you can often make the verification process -automatic, while you often need to have extensive manual evaluation, +them apart is that you can often automate the verification process, +while you often need to have extensive manual evaluation, judgment, and review for the validation process. Sometimes, these two overlap, but often they don't. For example, if you @@ -93,12 +93,12 @@ review can answer that. We can, however, be sure that we're verifying or checking something. Unfortunately, "verify" and "validate" are often used interchangeably -and are difficult to distinguish between their two meanings. This may be +and because of that it can be difficult to distinguish between their meanings. This may be due to the similarity in their spelling and pronunciation. For that -reason, we decided to use neither word. Instead we wanted to use a more -common word, that accurately reflects what we want this package to do +reason, we've decided to use neither of those words. Instead, we wanted to use a more +common word that reflects what we want this package to do while also being generic enough to encompass different uses. So we went -with "check", since we "check" that the metadata is correct (based on +with "check", since this package *checks* that the metadata is correct (based on the specification). ### Objects From c30a6b7b3808194f8004a2cbb71d81bf57af289a Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Wed, 19 Nov 2025 08:48:59 +0100 Subject: [PATCH 07/11] docs: :pencil2: make the subheaders make a bit more sense --- docs/design/architecture.qmd | 62 +++++++++++++++++------------------- 1 file changed, 29 insertions(+), 33 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 1ddde577..70f6c176 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -39,6 +39,24 @@ things consistent. However, we also introduce some new terms and concepts specific to `check-datapackage`. The main objects and actions used throughout the package can be found in the tables below. +| Object | Description | +|----------------------------|--------------------------------------------| +| package | A Data Package that contains a collection of related data resources and descriptor(s). | +| descriptor | A standalone and complete metadata structure contained in a JSON file, for example, in `datapackage.json`. | +| properties | Metadata fields (name-value pairs) of a descriptor loaded as a Python dictionary. This can be a subset of the original descriptor or the entire structure. | +| schema | The JSON schema defining the Data Package standard. | +| config | An object containing settings for modifying the behaviour and output of the check mechanism. | + +: Objects used throughout `check-datapackage`. + +| Action | Description | +|----------------------------|--------------------------------------------| +| check | Check that properties comply with the Data Package standard. | +| explain | Explain issues flagged by the check action in more detail using non-technical language. | +| read | Read various files, such as a Data Package descriptor or a configuration file. | + +: Actions that `check-datapackage` can perform. + ### "Why "check" (and not "validate" or "verify")? If you have ever searched for tools that check something against a @@ -52,8 +70,8 @@ themselves as "validating" something often, in practice, *verify* that something matches a defined expectation or specification. There are many websites and articles comparing the difference between validate and verify. These two verbs are often used during the quality control or -assurance stages of building products. -For a good overview, see the Wikipedia on this topic in +assurance stages of building products. For a good overview, see the +Wikipedia on this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and on [software](https://en.wikipedia.org/wiki/Software_verification_and_validation) @@ -66,8 +84,8 @@ ensure that the solution is being built correctly and with high quality, based on best practices, regulations, and specifications. It answers the question "are we developing the solution correctly"? An easy way to tell them apart is that you can often automate the verification process, -while you often need to have extensive manual evaluation, -judgment, and review for the validation process. +while you often need to have extensive manual evaluation, judgment, and +review for the validation process. Sometimes, these two overlap, but often they don't. For example, if you are involved in creating a specification that accurately describes @@ -93,35 +111,13 @@ review can answer that. We can, however, be sure that we're verifying or checking something. Unfortunately, "verify" and "validate" are often used interchangeably -and because of that it can be difficult to distinguish between their meanings. This may be -due to the similarity in their spelling and pronunciation. For that -reason, we've decided to use neither of those words. Instead, we wanted to use a more -common word that reflects what we want this package to do -while also being generic enough to encompass different uses. So we went -with "check", since this package *checks* that the metadata is correct (based on -the specification). - -### Objects - -| Object | Description | -|----------------------------|--------------------------------------------| -| package | A Data Package that contains a collection of related data resources and descriptor(s). | -| descriptor | A standalone and complete metadata structure contained in a JSON file, for example, in `datapackage.json`. | -| properties | Metadata fields (name-value pairs) of a descriptor loaded as a Python dictionary. This can be a subset of the original descriptor or the entire structure. | -| schema | The JSON schema defining the Data Package standard. | -| config | An object containing settings for modifying the behaviour and output of the check mechanism. | - -: Objects used throughout `check-datapackage`. - -### Actions - -| Action | Description | -|----------------------------|--------------------------------------------| -| check | Check that properties comply with the Data Package standard. | -| explain | Explain issues flagged by the check action in more detail using non-technical language. | -| read | Read various files, such as a Data Package descriptor or a configuration file. | - -: Actions that `check-datapackage` can perform. +and because of that it can be difficult to distinguish between their +meanings. This may be due to the similarity in their spelling and +pronunciation. For that reason, we've decided to use neither of those +words. Instead, we wanted to use a more common word that reflects what +we want this package to do while also being generic enough to encompass +different uses. So we went with "check", since this package *checks* +that the metadata is correct (based on the specification). ## C4 Models From 68f719701e648b730f1d34b079e36f07cd18b2bc Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Wed, 19 Nov 2025 09:01:02 +0100 Subject: [PATCH 08/11] docs: :pencil2: simplify text more --- docs/design/architecture.qmd | 51 ++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 70f6c176..69ee5cc9 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -60,39 +60,40 @@ used throughout the package can be found in the tables below. ### "Why "check" (and not "validate" or "verify")? If you have ever searched for tools that check something against a -specification, you'll often see the word "validate". And you might +specification, you'll often see the word "validate". You might also notice that we don't use the word "validate" in our package and documentation. This is intentional. -Although the word is ubiquitous in programming, it's often used loosely -and in ways that deviate from its actual meaning. Tools that describe -themselves as "validating" something often, in practice, *verify* that -something matches a defined expectation or specification. There are many -websites and articles comparing the difference between validate and -verify. These two verbs are often used during the quality control or -assurance stages of building products. For a good overview, see the -Wikipedia on this topic in +Although the word "validate" is ubiquitous in programming, it's often +used loosely and in ways that don't align from its actual meaning. Tools +that "validate" something often, in practice, *verify* that something +matches a defined expectation or specification. These two verbs are +often used during the quality control or assurance stages of building +products. There are many websites and articles comparing the difference +between validate and verify. For a good overview, see the Wikipedia on +this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and on [software](https://en.wikipedia.org/wiki/Software_verification_and_validation) specifically. To "validate" is to assess the overlap between a human need and a -product that solves that need. It answers the question "have we selected -the correct solution to solving the actual problem"? To "verify" is to -ensure that the solution is being built correctly and with high quality, -based on best practices, regulations, and specifications. It answers the -question "are we developing the solution correctly"? An easy way to tell -them apart is that you can often automate the verification process, -while you often need to have extensive manual evaluation, judgment, and -review for the validation process. +solution that solves that need. It answers the question "have we +selected the correct solution to solving the actual problem"? To +"verify" is to ensure that the solution is being built correctly and +with high quality, based on best practices, regulations, and +specifications. It answers the question "are we developing the solution +correctly"? An easy way to tell them apart is that you can often +automate the verification process, while you often need to have +extensive manual evaluation, judgment, and review for the validation +process. Sometimes, these two overlap, but often they don't. For example, if you -are involved in creating a specification that accurately describes -something that will solve a need you have, then you are both validating -and verifying the product that you will build. However, if someone else +are creating a specification that accurately describes something that +will solve a need you have, then you are likely both validating and +verifying the product that you will build. However, if someone else takes your specification to help them build their own product and they -don't seek our extensive validation from the humans who will use that +don't seek out extensive validation from the humans who will use that product, they are now likely verifying their product, rather than validating it. @@ -105,10 +106,10 @@ Even widely used tools like [Pydantic](https://docs.pydantic.dev/latest/) use the word "validate". However, without knowing the human context, what they are most likely doing is verifying that something matches some other specification or -expectation. Most of these software tool that "validate" can't know if -they are truly "validating" something since only human judgement and -review can answer that. We can, however, be sure that we're verifying or -checking something. +expectation. Most of these software tools that "validate" can't know if +the user is using it to "validate" something since only human judgement +and review can answer that. We can, however, be sure that the tool is +verifying something. Unfortunately, "verify" and "validate" are often used interchangeably and because of that it can be difficult to distinguish between their From a164faf209252523a4b1d7329c106b5acdf4fa65 Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Wed, 19 Nov 2025 15:56:46 +0100 Subject: [PATCH 09/11] docs: :pencil2: cut down on paragraphs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Signe Kirk Brødbæk --- docs/design/architecture.qmd | 38 ++---------------------------------- 1 file changed, 2 insertions(+), 36 deletions(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 69ee5cc9..d2e4e4b7 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -67,9 +67,8 @@ documentation. This is intentional. Although the word "validate" is ubiquitous in programming, it's often used loosely and in ways that don't align from its actual meaning. Tools that "validate" something often, in practice, *verify* that something -matches a defined expectation or specification. These two verbs are -often used during the quality control or assurance stages of building -products. There are many websites and articles comparing the difference +matches a defined expectation or specification. +There are many websites and articles comparing the difference between validate and verify. For a good overview, see the Wikipedia on this topic in [general](https://en.wikipedia.org/wiki/Verification_and_validation) and @@ -77,39 +76,6 @@ on [software](https://en.wikipedia.org/wiki/Software_verification_and_validation) specifically. -To "validate" is to assess the overlap between a human need and a -solution that solves that need. It answers the question "have we -selected the correct solution to solving the actual problem"? To -"verify" is to ensure that the solution is being built correctly and -with high quality, based on best practices, regulations, and -specifications. It answers the question "are we developing the solution -correctly"? An easy way to tell them apart is that you can often -automate the verification process, while you often need to have -extensive manual evaluation, judgment, and review for the validation -process. - -Sometimes, these two overlap, but often they don't. For example, if you -are creating a specification that accurately describes something that -will solve a need you have, then you are likely both validating and -verifying the product that you will build. However, if someone else -takes your specification to help them build their own product and they -don't seek out extensive validation from the humans who will use that -product, they are now likely verifying their product, rather than -validating it. - -For many generic software tools that do checks, they often use the word -"validate". For example, in the -[`frictionless`](https://pypi.org/project/frictionless/) package, they -have a command called -["validate"](https://framework.frictionlessdata.io/docs/guides/validating-data.html). -Even widely used tools like -[Pydantic](https://docs.pydantic.dev/latest/) use the word "validate". -However, without knowing the human context, what they are most likely -doing is verifying that something matches some other specification or -expectation. Most of these software tools that "validate" can't know if -the user is using it to "validate" something since only human judgement -and review can answer that. We can, however, be sure that the tool is -verifying something. Unfortunately, "verify" and "validate" are often used interchangeably and because of that it can be difficult to distinguish between their From bb20cff89c79b14e119fb30dd482ce2f3d8df2d4 Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Wed, 19 Nov 2025 14:56:59 +0000 Subject: [PATCH 10/11] chore(pre-commit): :pencil2: automatic fixes --- docs/design/architecture.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index d2e4e4b7..11cb9888 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -67,7 +67,7 @@ documentation. This is intentional. Although the word "validate" is ubiquitous in programming, it's often used loosely and in ways that don't align from its actual meaning. Tools that "validate" something often, in practice, *verify* that something -matches a defined expectation or specification. +matches a defined expectation or specification. There are many websites and articles comparing the difference between validate and verify. For a good overview, see the Wikipedia on this topic in From b2086b73e06fa33632b7ba09c0dcb174b5abd57b Mon Sep 17 00:00:00 2001 From: "Luke W. Johnston" Date: Thu, 20 Nov 2025 13:57:59 +0100 Subject: [PATCH 11/11] docs: :pencil2: remove duplicate empty line Co-authored-by: Joel Ostblom --- docs/design/architecture.qmd | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/design/architecture.qmd b/docs/design/architecture.qmd index 11cb9888..a56324a4 100644 --- a/docs/design/architecture.qmd +++ b/docs/design/architecture.qmd @@ -76,7 +76,6 @@ on [software](https://en.wikipedia.org/wiki/Software_verification_and_validation) specifically. - Unfortunately, "verify" and "validate" are often used interchangeably and because of that it can be difficult to distinguish between their meanings. This may be due to the similarity in their spelling and