docs: change specific db table names to generic concept names

Author: mgwozdz-unicon

docs/decisions/0022-competency-criteria-model.rst

@@ -24,7 +24,7 @@ In short: `CompetencyAchievementCriteria` is the full tree, while `CompetencyCri
 Decision
 --------
 
-1. `CompetencyTaxonomy` concept (`oel_competency_taxonomy`)
+1. `CompetencyTaxonomy` concept (database table)
 
    Represents the set of taxonomies that are competency-enabled rather than generic tag-only taxonomies.
 
@@ -55,10 +55,10 @@ Decision
 
    Lifecycle rules for this parent/child pair:
 
-   - Creating a competency taxonomy creates both the parent `oel_tagging_taxonomy` row and the child `oel_competency_taxonomy` row in one transaction.
+   - Creating a competency taxonomy creates both the parent `oel_tagging_taxonomy` row and the `CompetencyTaxonomy` row in one transaction.
    - Deleting either representation is treated as deleting the competency taxonomy and removes both rows, subject to Decision 7 delete protections.
 
-2. `CompetencyCriteriaGroup` concept (`oel_competency_criteria_group`)
+2. `CompetencyCriteriaGroup` concept (database table)
 
    Represents an internal boolean-expression node for `CompetencyAchievementCriteria`.
 
@@ -74,7 +74,7 @@ Decision
    This new database table will have the following columns:
 
    1. `id`: unique primary key
-   2. `parent_id`: The `oel_competency_criteria_group.id` of the parent group. Null means this is a root group.
+   2. `parent_id`: The `CompetencyCriteriaGroup.id` of the parent group. Null means this is a root group.
    3. `oel_tagging_tag_id`: The `oel_tagging_tag.id` for the competency represented by this criteria tree.
    4. `course_id`: Nullable foreign key to `openedx_catalog_courserun.id` for the course that scopes this criteria tree.
    5. `name`: string
@@ -102,10 +102,10 @@ Decision
    - Empty groups: Persisted criteria definitions should not contain empty groups. Authoring flows may temporarily create empty groups while editing, but backend validation must reject them.
    - Mixed tree depths: Backend supports deeply nested groups. Current frontend authoring constraint is a maximum depth of 3 layers total, using zero-indexed depth (`0=root`, `1=course-scope group`, `2=leaf criteria/group`).
    - Retrieval scope: Evaluation/read paths should be windowed by course run dates, not full-history by default. For a requested date window `[window_start, window_end]`, include (a) all nodes where `course_id is null`, and (b) complete subtrees for course-scoped groups whose course run overlaps the window (`course_start <= window_end` and `course_end >= window_start`, with null `course_end` treated as ongoing). Do not return partial subtrees.
-   - Practical size and growth: Total rows in `oel_competency_criteria_group` are expected to grow over time as course runs are added; this ADR sets no global DB row cap. No max total node-count cap is required per root group. For `course_id is null` branches, expected size is small (realistically <=500 nodes). Pagination is supported for authoring/list APIs.
+   - Practical size and growth: Total rows in `CompetencyCriteriaGroup` are expected to grow over time as course runs are added; this ADR sets no global DB row cap. No max total node-count cap is required per root group. For `course_id is null` branches, expected size is small (realistically <=500 nodes). Pagination is supported for authoring/list APIs.
 
 
-3. `CompetencyRuleProfile` concept (`oel_competency_rule_profile`)
+3. `CompetencyRuleProfile` concept (database table)
 
    Represents a reusable default rule configuration that can be applied to many `CompetencyCriterion` rows.
 
@@ -119,13 +119,13 @@ Decision
    1. `id`: unique primary key
    2. `organization_id`: The `organization_id` of the organization that this competency rule profile is scoped to. Null if it is not scoped to a specific organization.
    3. `course_id`: The `course_id` of the course that this competency rule profile is scoped to. Null if it is not scoped to a specific course.
-   4. `competency_taxonomy_id`: The `oel_competency_taxonomy.taxonomy_ptr_id` of the competency taxonomy that this competency rule profile is scoped to.
+   4. `competency_taxonomy_id`: The `CompetencyTaxonomy.taxonomy_ptr_id` of the competency taxonomy that this competency rule profile is scoped to.
    5. `rule_type`: “View”, “Grade”, “MasteryLevel” (Only “Grade” will be supported for now)
    6. `rule_payload`: JSON payload keyed by `rule_type` to avoid freeform strings. It is structured JSON (not arbitrary freeform data): each `rule_type` defines the allowed payload shape and required keys, and validation enforces this contract. JSON is used instead of fixed columns like `op`, `value`, and `scale` so that future rule types (for example, `MasteryLevel` thresholds or plugin-defined evaluators such as CEL-based rules) can add their own fields without repeated schema migrations or many nullable columns. Examples:
 
       1. `Grade`: `{"op": "gte", "value": 75, "scale": "percent"}`
 
-4. `CompetencyCriterion` concept (`oel_competency_criteria`)
+4. `CompetencyCriterion` concept (`CompetencyCriteria` database table)
 
    Represents one leaf condition in a `CompetencyAchievementCriteria` tree.
 
@@ -148,36 +148,36 @@ Decision
 
 5. Indexes for common lookups
 
-   1. `oel_competency_criteria_group(oel_tagging_tag_id, course_id)`
-   2. `oel_competency_criteria_group(parent_id)`
+   1. `CompetencyCriteriaGroup(oel_tagging_tag_id, course_id)`
+   2. `CompetencyCriteriaGroup(parent_id)`
    3. `oel_tagging_objecttag(object_id)`
-   4. `oel_competency_criteria(oel_tagging_objecttag_id)`
-   5. `oel_competency_criteria(competency_criteria_group_id)`
-   6. `student_competencycriteriastatus(user_id, competency_criteria_id)`
-   7. `student_competencycriteriagroupstatus(user_id, competency_criteria_group_id)`
-   8. `student_competencystatus(user_id, oel_tagging_tag_id)`
-   9. `oel_competency_rule_profile(competency_taxonomy_id, course_id, organization_id)`
-   10. `oel_competency_mastery_statuses(status)` (unique)
+   4. `CompetencyCriteria(oel_tagging_objecttag_id)`
+   5. `CompetencyCriteria(competency_criteria_group_id)`
+   6. `StudentCompetencyCriteriaStatus(user_id, competency_criteria_id)`
+   7. `StudentCompetencyCriteriaGroupStatus(user_id, competency_criteria_group_id)`
+   8. `StudentCompetencyStatus(user_id, oel_tagging_tag_id)`
+   9. `CompetencyRuleProfile(competency_taxonomy_id, course_id, organization_id)`
+   10. `CompetencyMasteryStatuses(status)` (unique)
 
-6. Learner progress status concepts (`student_competency*status`)
+6. Learner progress status concepts (`StudentCompetency*Status` database tables)
 
    When a completion event (graded, completed, mastered, etc.) occurs for an object, determine and track the learner's status in earning the competency. To reduce recalculation frequency, store results at each level.
 
    Relationship to other concepts:
 
-   - `student_competencycriteriastatus` tracks status at `CompetencyCriterion` leaf level.
-   - `student_competencycriteriagroupstatus` tracks status at `CompetencyCriteriaGroup` node level.
-   - `student_competencystatus` tracks top-level competency demonstration state.
-   - All learner status rows use a shared lookup table (`oel_competency_mastery_statuses`) so status semantics live in one place and student status tables stay structurally consistent.
+   - `StudentCompetencyCriteriaStatus` tracks status at `CompetencyCriterion` leaf level.
+   - `StudentCompetencyCriteriaGroupStatus` tracks status at `CompetencyCriteriaGroup` node level.
+   - `StudentCompetencyStatus` tracks top-level competency demonstration state.
+   - All learner status rows use a shared lookup table (`CompetencyMasteryStatuses`) so status semantics live in one place and student status tables stay structurally consistent.
 
    Intended update flow (bottom-up materialization):
 
-   - A learner event updates one `student_competencycriteriastatus` row.
+   - A learner event updates one `StudentCompetencyCriteriaStatus` row.
    - Recompute ancestor `CompetencyCriteriaGroup` statuses upward to the root.
    - At each group, evaluate children in `ordering` sequence and short-circuit when the group's result is already determined by its `logic_operator`.
    - Persist only rows whose status changed.
 
-   1. Add new database table for `oel_competency_mastery_statuses` with these columns:
+   1. Add new database table for `CompetencyMasteryStatuses` with these columns:
 
       1. `id`: unique primary key
       2. `status`: unique status value (seeded values: “Demonstrated”, “AttemptedNotDemonstrated”, and “PartiallyAttempted”)
@@ -186,35 +186,35 @@ Decision
 
       - This table is system-owned lookup data and should be treated as immutable configuration, not user-authored rows.
 
-   2. Add new database table for `student_competencycriteriastatus` with these columns:
+   2. Add new database table for `StudentCompetencyCriteriaStatus` with these columns:
 
       1. `id`: unique primary key
       2. `competency_criteria_id`: Foreign key to `CompetencyCriterion.id`
       3. `user_id`: Foreign key pointing to user_id (presumably the learner's id, although it appears that it is possible for staff to get grades as well) in `auth_user` table
-      4. `status_id`: Foreign key to `oel_competency_mastery_statuses.id`
+      4. `status_id`: Foreign key to `CompetencyMasteryStatuses.id`
       5. `created`: The timestamp at which the student's criterion status was set.
 
-   3. Add a new database table for `student_competencycriteriagroupstatus` with these columns:
+   3. Add a new database table for `StudentCompetencyCriteriaGroupStatus` with these columns:
 
       1. `id`: unique primary key
       2. `competency_criteria_group_id`: Foreign key to `CompetencyCriteriaGroup.id`
       3. `user_id`: Foreign key pointing to user_id (presumably the learner's id, although it appears that it is possible for staff to get grades as well) in `auth_user` table
-      4. `status_id`: Foreign key to `oel_competency_mastery_statuses.id`
+      4. `status_id`: Foreign key to `CompetencyMasteryStatuses.id`
       5. `created`: The timestamp at which the student's criteria-group status was set.
 
-   4. Add a new database table for `student_competencystatus` with these columns:
+   4. Add a new database table for `StudentCompetencyStatus` with these columns:
 
       1. `id`: unique primary key
       2. `oel_tagging_tag_id`: Foreign key pointing to Tag id
       3. `user_id`: Foreign key pointing to user_id (presumably the learner's id, although it appears that it is possible for staff to get grades as well) in `auth_user` table
-      4. `status_id`: Foreign key to `oel_competency_mastery_statuses.id`. This table should have a constraint to only allow status values of “Demonstrated” and “PartiallyAttempted” since it represents overall competency demonstration state, not in-progress states.
+      4. `status_id`: Foreign key to `CompetencyMasteryStatuses.id`. This table should have a constraint to only allow status values of “Demonstrated” and “PartiallyAttempted” since it represents overall competency demonstration state, not in-progress states.
       5. `created`: The timestamp at which the student's competency status was set.
 
 7. Delete protection boundaries
 
    - If no learner status rows exist for a competency definition, hard delete is allowed and cascades through competency metadata tables.
-   - Once any related learner status exists in `student_competencystatus`, `student_competencycriteriagroupstatus`, or `student_competencycriteriastatus`, deletion of associated competency definition rows is blocked.
-   - This delete protection applies to `oel_tagging_taxonomy`, `oel_competency_taxonomy`, `oel_tagging_tag`, `oel_tagging_objecttag`, `oel_competency_criteria_group`, `oel_competency_criteria`, and `oel_competency_rule_profile`.
+   - Once any related learner status exists in `StudentCompetencyStatus`, `StudentCompetencyCriteriaGroupStatus`, or `StudentCompetencyCriteriaStatus`, deletion of associated competency definition rows is blocked.
+   - This delete protection applies to `oel_tagging_taxonomy`, `CompetencyTaxonomy`, `oel_tagging_tag`, `oel_tagging_objecttag`, `CompetencyCriteriaGroup`, `CompetencyCriteria`, and `CompetencyRuleProfile`.
    - Once any related learner status exists, retiring definitions may be archive-only (hidden from authoring and new associations), not hard delete.
 
 .. image:: images/CompetencyCriteriaModel.png
@@ -241,17 +241,17 @@ Content objects:
    - Assignment 7 tagged with "Writing Poetry"
    - Assignment 9 tagged with "Writing Poetry"
 
-2. `oel_competency_rule_profile`:
+2. `CompetencyRuleProfile`:
 
    - Course-scoped default: `Grade >= 75%` for this competency taxonomy
 
-3. `oel_competency_criteria_group`:
+3. `CompetencyCriteriaGroup`:
 
    - Root group uses `OR`
    - Group A (`ordering=1`) uses `AND`
    - Group B (`ordering=2`) uses `AND`
 
-4. `oel_competency_criteria`:
+4. `CompetencyCriteria`:
 
    - Group A + Assignment 7 (uses default rule profile)
    - Group A + Assignment 9 (override to `Grade >= 85%`)
@@ -278,7 +278,7 @@ Rejected Alternatives
       4. Makes it harder to keep competency features optional for deployments that only want generic tagging
       5. Increases risk of future refactor/migration work if the competency domain later needs to be split from tagging
 
-2. Same as above except combine the `oel_competency_criteria` and `oel_tagging_objecttag` tables by adding the rule information as columns on the `oel_tagging_objecttag` table. This would be a more denormalized approach that would reduce the number of joins needed to retrieve competency achievement criteria information but would add complexity to the `oel_tagging_objecttag` table and make it less flexible for other uses.
+2. Same as above except combine the `CompetencyCriteria` and `oel_tagging_objecttag` tables by adding the rule information as columns on the `oel_tagging_objecttag` table. This would be a more denormalized approach that would reduce the number of joins needed to retrieve competency achievement criteria information but would add complexity to the `oel_tagging_objecttag` table and make it less flexible for other uses.
 
    1. Pros