Align journal docs with current model

documentation/AE__Data_Structures.md

@@ -8,21 +8,31 @@ This document outlines the key data structures and their properties used within
 
 These fields are expected to be present in most Aether objects, providing a consistent base structure.
 
-- `id`: Primary key for an object (internal use, often a UUID).
+- `id`: Primary key for an object (internal use, often *returned* by the API as a randomized string value in place of the actual DB autonum).
 - `id_random`: Randomly generated ID for an object (often used for external exposure or URL parameters).
 - `<object_type>_id_random`: Specific random ID for an object (e.g., `person_id_random`).
 - `code`: Short, unique identifier.
 - `name`: Display name.
 - `enable`: Boolean for active/inactive status.
 - `hide`: Boolean for visibility.
-- `priority`: Numeric value for ordering.
-- `sort`: Numeric value for ordering.
+- `priority`: Boolean/tinyint(1) ordering flag used by the object model.
+- `sort`: Numeric value for ordering within a priority group.
 - `group`: Categorization string.
 - `notes`: General notes/comments.
 - `created_on`: Timestamp of creation.
 - `updated_on`: Timestamp of last update.
 
-### 1.2. Special Use Fields
+### 1.2. Journal Entry Fields
+
+Journal entries use the shared object fields plus a few content-specific fields that matter in the UI and config modal.
+
+- `summary`: Short entry summary shown in metadata and list contexts.
+- `content`: Main body text for the entry.
+- `alert`: Boolean flag used to highlight an entry as an alert.
+- `alert_msg`: Supporting alert text shown when the alert flag is enabled.
+- `private` / `public` / `personal` / `professional`: Visibility and audience flags used by the Entry Config modal.
+
+### 1.3. Special Use Fields
 
 Fields with specific purposes or conditional usage across different object types.
 
@@ -32,7 +42,7 @@ Fields with specific purposes or conditional usage across different object types
 - `passcode`: A password or access code associated with an object.
 - `external_id`: An identifier from an external system.
 
-### 1.3. Configuration and JSON Fields
+### 1.4. Configuration and JSON Fields
 
 Fields designed to store structured data in JSON format.
 
@@ -40,7 +50,7 @@ Fields designed to store structured data in JSON format.
 - `data_json`: General purpose data for an object, stored as a JSON string.
 - `linked_li_json`: A list of linked items, stored as a JSON string.
 
-### 1.4. Special Generated Fields (Client-side)
+### 1.5. Special Generated Fields (Client-side)
 
 These fields are generated on the client-side, primarily for facilitating UI logic, such as sorting. They are not typically stored in the backend database.
 
@@ -48,7 +58,7 @@ These fields are generated on the client-side, primarily for facilitating UI log
 - `tmp_sort_2`: Temporary sort field 2.
 - `tmp_sort_3`: Temporary sort field 3.
 
-### 1.5. Future Standard Fields
+### 1.6. Future Standard Fields
 
 A list of potential future standard fields, often prefixed with `obj_`. These are conceptual and represent planned expansions to the data model.
 
@@ -58,7 +68,7 @@ A list of potential future standard fields, often prefixed with `obj_`. These ar
 
 Standardized sorting orders are applied across various data lists to ensure consistent presentation.
 
-- **Default/General Sorting:** `group > priority > sort > updated_on/created_on`
+- **Default/General Sorting:** `group > priority (flag) > sort > updated_on/created_on`
 - **Specific Sorting (e.g., for time-based events):** `type > start_date/time > code or name`
 
 ## 3. Data Storage Mechanisms