Skip to content

Clarifying the Use of “Assessed” vs. “Assure” in Phase 2 (Wholeness) #4

@ChristopherA

Description

@ChristopherA

Background:

In our "The Progressive Trust Life Cycle" documentation—specifically in the 2. Wholeness (Integrity Assessed) section—we now recommend using the term “Assessed”. This term is chosen because its etymology, derived from the Latin assidere (“to sit beside” or “assist in judging”), emphasizes the evaluation or estimation of data quality.

We also recently started discourage using “Validate” as it implies a binary check, which doesn't align well with our overall progressive trust model.

The Dilemma:
In our code and documentation, the term we choose sometimes feels awkward when applied to all scenarios. Consider the following examples:

  1. Consistent Use in Reports:

    Inception Commit Audit Report
    Evaluating overall inception commit compliance with standards...
    
    💡 Wholeness Assessment:
    (Progressive Trust Phase 2)
      📌 Assessing repository structure...
        📘 Found inception commit 5c8d388fa6637789a2fb6b635f7cbb3d6c7f80d5
      ✅ Repository Structure: Inception commit found
    
      📌 Assessing commit content...
        📘 Tree hash matches empty commit requirements
      ✅ Content Assessment: Commit is empty as required
    
      📌 Assessing message format...
        📘 Found required initialization message and sign-off
      ✅ Format Assessment: Commit message meets requirements
    

    Here, “assessing” fits naturally as we are evaluating different aspects of the commit.

  2. Function Naming in Code:

    • For locating the inception commit, the term works well:

      # Phase 2 (Wholeness) prerequisite: Find and assess inception commit
      #------------------------------------------------------------------#
      function locate_inception_commit {
    • However, when renaming a function (formerly assess_empty_commit) that checks for an empty commit, changing it to “assess_empty_commit” doesn't feel as natural:

      #------------------------------------------------------------------#
      # Local Function: assess_empty_commit
      # Phase 2 (Wholeness): Assess commit is empty (contains no files)
      #------------------------------------------------------------------#
      function assess_empty_commit {
    • In this context, “assure_empty_commit” might be a better fit:

      #------------------------------------------------------------------#
      # Local Function: assure_empty_commit
      # Phase 2 (Wholeness): Assure commit is empty (contains no files)
      #------------------------------------------------------------------#
      function assure_empty_commit {

I also note that we use the word "ensure" a lot:

In the progressive trust article:

- **Actions**: Perform thorough checks to ensure  the structure and format of data assets are intact, sufficiently complete, and meet expected standards. Check for consistency based on historical data, but not based on cryptographic checks.

and

By remodeling that in the digital medium, we can bring digital interactions up to the same standards, and thus ensure they have the same chances of success.

In my code:

#######################################################################
## Section: ZSH Configuration and Environment Initialization
##--------------------------------------------------------------------##
## Description:
## - Configures the Zsh environment to ensure robust error handling and
##   predictable execution behavior.

Etymological Notes:

While both assure and assess share the prefix ad- (meaning “to” or “toward”), their roots and connotations differ:

  • Assess:
    • Derived from Latin assidere (“to sit beside”), implying the act of evaluating or judging quality or integrity.
  • Assure:
    • Derived from Old French asseurer (from Latin ad + securus), meaning “secure, free from care.”
    • Conveys a sense of guaranteeing or ensuring a condition.
  • Ensure:
    • Also comes from Old French enseurer (a variant of assurer), ultimately from Latin ad + securus. Connotation: Implies making certain or guaranteeing that something will occur or a condition is met.

The Question:
How should we decide when to use “assess” versus “assure” in our documentation and code? Should we:

  • Use “assess” when the primary action is evaluating or judging quality.
  • Use “assure” when the process is about confirming and providing confidence in a state.
  • Optionally use “ensure” when the intent is to guarantee that a condition is met? Or does that make it too complicated? Also, when spoken, "ensure" phonetically is close to "insure" which clearly isn't correct, but I don't know when phonetic confusion should one of our criteria (but it was for verify and validate).

The good news if someone gets it wrong, as they all very similar, and I don't believe are confusing with words used in the other other levels (I hope) thus any choice is OK.

Thus maybe:

    - ___Active Verbs.___ ASSESS, ASSURE, ensure

Does this make sense? Any guidance on establishing clear, consistent naming conventions that respect these subtle differences would be greatly appreciated.

We also should search through our progressive trust articles words "assess" "assessment", "assure", "assurance", "ensure", "valid", "validate", "validation" for consistency.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions