@tailor-platform/erp-kit 0.0.1 → 0.1.0

package/src/modules/user-management/db/rolePermission.ts

@@ -0,0 +1,44 @@
+import {
+  db,
+  unsafeAllowAllGqlPermission,
+  unsafeAllowAllTypePermission,
+} from "@tailor-platform/sdk";
+import { role } from "./role";
+import { permission } from "./permission";
+
+export interface CreateRolePermissionTypeParams {
+  fields?: Record<string, unknown>;
+}
+
+export function createRolePermissionType(params: CreateRolePermissionTypeParams) {
+  return db
+    .type("RolePermission", {
+      roleId: db
+        .uuid()
+        .relation({
+          type: "n-1",
+          toward: { type: role },
+          backward: "rolePermissions",
+        })
+        .description("Foreign key to Role"),
+      permissionId: db
+        .uuid()
+        .relation({
+          type: "n-1",
+          toward: { type: permission },
+          backward: "rolePermissions",
+        })
+        .description("Foreign key to Permission"),
+      ...params.fields,
+      ...db.fields.timestamps(),
+    })
+    .indexes({
+      fields: ["roleId", "permissionId"],
+      unique: true,
+      name: "role_permission_unique_idx",
+    })
+    .permission(unsafeAllowAllTypePermission)
+    .gqlPermission(unsafeAllowAllGqlPermission);
+}
+
+export const rolePermission = createRolePermissionType({});

package/src/modules/user-management/db/user.ts

@@ -0,0 +1,38 @@
+import {
+  db,
+  type TailorAnyDBField,
+  unsafeAllowAllGqlPermission,
+  unsafeAllowAllTypePermission,
+} from "@tailor-platform/sdk";
+
+export interface CreateUserTypeParams<F extends Record<string, TailorAnyDBField>> {
+  fields?: F;
+  additionalStatuses?: string[];
+}
+
+const BASE_STATUSES = ["PENDING", "ACTIVE", "INACTIVE"] as const;
+
+export function createUserType<const F extends Record<string, TailorAnyDBField>>(
+  params: CreateUserTypeParams<F>,
+) {
+  const statuses = [...BASE_STATUSES, ...(params.additionalStatuses ?? [])] as [
+    string,
+    ...string[],
+  ];
+
+  return db
+    .type("User", {
+      email: db.string().unique().description("User email address (unique identifier)"),
+      name: db.string().description("User display name"),
+      status: db.enum(statuses).description("User status"),
+      permissions: db
+        .string({ array: true, optional: true })
+        .description("Flattened permission keys from all assigned roles"),
+      ...((params.fields ?? {}) as F),
+      ...db.fields.timestamps(),
+    })
+    .permission(unsafeAllowAllTypePermission)
+    .gqlPermission(unsafeAllowAllGqlPermission);
+}
+
+export const user = createUserType({});

package/src/modules/user-management/db/userRole.ts

@@ -0,0 +1,44 @@
+import {
+  db,
+  unsafeAllowAllGqlPermission,
+  unsafeAllowAllTypePermission,
+} from "@tailor-platform/sdk";
+import { user } from "./user";
+import { role } from "./role";
+
+export interface CreateUserRoleTypeParams {
+  fields?: Record<string, unknown>;
+}
+
+export function createUserRoleType(params: CreateUserRoleTypeParams) {
+  return db
+    .type("UserRole", {
+      userId: db
+        .uuid()
+        .relation({
+          type: "n-1",
+          toward: { type: user },
+          backward: "userRoles",
+        })
+        .description("Foreign key to User"),
+      roleId: db
+        .uuid()
+        .relation({
+          type: "n-1",
+          toward: { type: role },
+          backward: "userRoles",
+        })
+        .description("Foreign key to Role"),
+      ...params.fields,
+      ...db.fields.timestamps(),
+    })
+    .indexes({
+      fields: ["userId", "roleId"],
+      unique: true,
+      name: "user_role_unique_idx",
+    })
+    .permission(unsafeAllowAllTypePermission)
+    .gqlPermission(unsafeAllowAllGqlPermission);
+}
+
+export const userRole = createUserRoleType({});

package/src/modules/user-management/docs/commands/ActivateUser.md

@@ -0,0 +1,36 @@
+# ActivateUser
+
+## Overview
+
+ActivateUser transitions a user from PENDING status to ACTIVE status, granting them full access to the system. This command is typically executed by an administrator after the user's identity has been verified and onboarding requirements are complete.
+
+Only users in PENDING status can be activated. Attempting to activate an already active or inactive user will fail.
+
+## Business Rules
+
+- User must exist in the system
+- User must be in PENDING status
+- Transitions user status from PENDING to ACTIVE
+- Generates USER_ACTIVATED audit event with actor ID, timestamp, and previous status
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive activate request] --> B{User exists?}
+    B -->|No| C[Return error: USER_NOT_FOUND]
+    B -->|Yes| D{Status is PENDING?}
+    D -->|No| E[Return error: INVALID_STATUS_TRANSITION]
+    D -->|Yes| F[Update status to ACTIVE]
+    F --> G[Log USER_ACTIVATED audit event]
+    G --> H[Return updated user]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_NOT_FOUND**: User ID does not exist in the system - return not found error with the provided ID
+- **INVALID_STATUS_TRANSITION**: User is not in PENDING status (already ACTIVE or INACTIVE) - return error with current status and valid transitions

package/src/modules/user-management/docs/commands/AssignPermissionToRole.md

@@ -0,0 +1,39 @@
+# AssignPermissionToRole
+
+## Overview
+
+AssignPermissionToRole creates an association between a permission and a role, granting that permission to all users who have the role assigned. This command enables building up role capabilities by adding permissions one at a time.
+
+The operation is idempotent - assigning the same permission to a role twice does not create duplicate records or return an error.
+
+## Business Rules
+
+- Role must exist in the system
+- Permission must exist in the system
+- Operation is idempotent (assigning same permission twice is not an error)
+- Creates RolePermission association record if not already present
+- Generates PERMISSION_ASSIGNED audit event with actor ID, role ID, permission ID, and timestamp
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive assign request] --> B{Role exists?}
+    B -->|No| C[Return error: ROLE_NOT_FOUND]
+    B -->|Yes| D{Permission exists?}
+    D -->|No| E[Return error: PERMISSION_NOT_FOUND]
+    D -->|Yes| F{Assignment exists?}
+    F -->|Yes| G[Return success - idempotent]
+    F -->|No| H[Create RolePermission record]
+    H --> I[Log PERMISSION_ASSIGNED audit event]
+    I --> J[Return success]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **ROLE_NOT_FOUND**: Role ID does not exist in the system - return not found error with the provided role ID
+- **PERMISSION_NOT_FOUND**: Permission ID does not exist in the system - return not found error with the provided permission ID

package/src/modules/user-management/docs/commands/AssignRoleToUser.md

@@ -0,0 +1,43 @@
+# AssignRoleToUser
+
+## Overview
+
+AssignRoleToUser creates an association between a role and a user, granting the user all permissions associated with that role. This command enables granting access to users by assigning them roles rather than managing permissions individually.
+
+Only ACTIVE users can receive role assignments. The operation is idempotent - assigning the same role to a user twice does not create duplicate records or return an error.
+
+## Business Rules
+
+- User must exist in the system
+- Role must exist in the system
+- User must be in ACTIVE status
+- Operation is idempotent (assigning same role twice is not an error)
+- Creates UserRole association record if not already present
+- Generates ROLE_ASSIGNED audit event with actor ID, user ID, role ID, and timestamp
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive assign request] --> B{User exists?}
+    B -->|No| C[Return error: USER_NOT_FOUND]
+    B -->|Yes| D{Role exists?}
+    D -->|No| E[Return error: ROLE_NOT_FOUND]
+    D -->|Yes| F{User is ACTIVE?}
+    F -->|No| G[Return error: USER_NOT_ACTIVE]
+    F -->|Yes| H{Assignment exists?}
+    H -->|Yes| I[Return success - idempotent]
+    H -->|No| J[Create UserRole record]
+    J --> K[Log ROLE_ASSIGNED audit event]
+    K --> L[Return success]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_NOT_FOUND**: User ID does not exist in the system - return not found error with the provided user ID
+- **ROLE_NOT_FOUND**: Role ID does not exist in the system - return not found error with the provided role ID
+- **USER_NOT_ACTIVE**: User is in PENDING or INACTIVE status - return error indicating only ACTIVE users can receive role assignments

package/src/modules/user-management/docs/commands/CreatePermission.md

@@ -0,0 +1,35 @@
+# CreatePermission
+
+## Overview
+
+CreatePermission defines a new permission in the system using the `resource:action` format. Permissions are the atomic unit of authorization, specifying what action can be performed on what resource. Examples include `orders:read`, `orders:write`, `users:delete`.
+
+Permissions are assigned to roles, which are then assigned to users. This indirection simplifies access management at scale.
+
+## Business Rules
+
+- Permission key must follow `resource:action` format (lowercase letters, colon separator)
+- Permission key must be unique across all permissions
+- Description is optional but recommended for clarity
+- Generates PERMISSION_ASSIGNED audit event when assigned to a role (via assignPermissionToRole)
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive create request] --> B{Validate key format}
+    B -->|Invalid| C[Return error: INVALID_KEY_FORMAT]
+    B -->|Valid| D{Key unique?}
+    D -->|No| E[Return error: PERMISSION_ALREADY_EXISTS]
+    D -->|Yes| F[Create permission record]
+    F --> G[Return created permission]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **INVALID_KEY_FORMAT**: Key does not match `resource:action` pattern - return validation error with format requirements
+- **PERMISSION_ALREADY_EXISTS**: Permission with the same key already exists - return conflict error with existing permission reference

package/src/modules/user-management/docs/commands/CreateRole.md

@@ -0,0 +1,35 @@
+# CreateRole
+
+## Overview
+
+CreateRole establishes a new role in the system with a unique name and optional description. Roles are containers for permissions that can be assigned to users, providing a level of abstraction that simplifies access management. Examples include "Sales Representative", "Sales Manager", "Administrator".
+
+Roles follow the principle of least privilege, bundling only the permissions necessary for a specific job function.
+
+## Business Rules
+
+- Role name must be unique across all roles
+- Role name is required and cannot be empty
+- Description is optional but recommended for clarity
+- New roles start with no permissions assigned
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive create request] --> B{Name provided?}
+    B -->|No| C[Return error: MISSING_REQUIRED_FIELD]
+    B -->|Yes| D{Name unique?}
+    D -->|No| E[Return error: ROLE_ALREADY_EXISTS]
+    D -->|Yes| F[Create role record]
+    F --> G[Return created role]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **MISSING_REQUIRED_FIELD**: Role name not provided - return validation error indicating name is required
+- **ROLE_ALREADY_EXISTS**: Role with the same name already exists - return conflict error with existing role reference

package/src/modules/user-management/docs/commands/CreateUser.md

@@ -0,0 +1,41 @@
+# CreateUser
+
+## Overview
+
+CreateUser establishes a new user account in the system with the provided name and email address. The user is created in PENDING status, awaiting activation by an administrator after verification is complete. This command supports the user onboarding process where new accounts must be verified before gaining system access.
+
+This command enforces email uniqueness across all users (active and inactive) to prevent duplicate accounts.
+
+## Business Rules
+
+- Email must be unique across all users (active and inactive)
+- Email must follow valid email format
+- Name is required and cannot be empty
+- New users are created in PENDING status
+- Generates USER_CREATED audit event with actor ID and timestamp
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive create request] --> B{Validate email format}
+    B -->|Invalid| C[Return error: INVALID_EMAIL]
+    B -->|Valid| D{Email unique?}
+    D -->|No| E[Return error: USER_ALREADY_EXISTS]
+    D -->|Yes| F{Name provided?}
+    F -->|No| G[Return error: MISSING_REQUIRED_FIELD]
+    F -->|Yes| H[Create user record]
+    H --> I[Set status: PENDING]
+    I --> J[Log USER_CREATED audit event]
+    J --> K[Return created user]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_ALREADY_EXISTS**: Email address is already registered in the system - return conflict error with message indicating email is taken
+- **INVALID_EMAIL**: Email does not follow valid email format - return validation error with format requirements
+- **MISSING_REQUIRED_FIELD**: Name or email not provided - return validation error listing missing fields

package/src/modules/user-management/docs/commands/DeactivateUser.md

@@ -0,0 +1,38 @@
+# DeactivateUser
+
+## Overview
+
+DeactivateUser transitions a user from ACTIVE status to INACTIVE status, revoking their access to the system while preserving their data for audit and historical purposes. This command is used when an employee leaves the organization, is terminated, or needs temporary access suspension.
+
+Only users in ACTIVE status can be deactivated. User data, role assignments, and historical associations are preserved.
+
+## Business Rules
+
+- User must exist in the system
+- User must be in ACTIVE status
+- Transitions user status from ACTIVE to INACTIVE
+- User data is preserved for audit purposes
+- Existing role assignments remain but become inactive
+- Generates USER_DEACTIVATED audit event with actor ID, timestamp, and previous status
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive deactivate request] --> B{User exists?}
+    B -->|No| C[Return error: USER_NOT_FOUND]
+    B -->|Yes| D{Status is ACTIVE?}
+    D -->|No| E[Return error: INVALID_STATUS_TRANSITION]
+    D -->|Yes| F[Update status to INACTIVE]
+    F --> G[Log USER_DEACTIVATED audit event]
+    G --> H[Return updated user]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_NOT_FOUND**: User ID does not exist in the system - return not found error with the provided ID
+- **INVALID_STATUS_TRANSITION**: User is not in ACTIVE status (PENDING or already INACTIVE) - return error with current status and valid transitions

package/src/modules/user-management/docs/commands/LogAuditEvent.md

@@ -0,0 +1,37 @@
+# LogAuditEvent
+
+## Overview
+
+LogAuditEvent creates an immutable record of a security-relevant event in the User Management module. This command captures the actor identity, timestamp, event type, and event details for compliance and security purposes.
+
+Typically, this command is triggered internally as a side effect of other commands (createUser, activateUser, assignRoleToUser, etc.) rather than being called directly.
+
+## Business Rules
+
+- Event type must be a valid event type (USER_CREATED, USER_ACTIVATED, USER_DEACTIVATED, USER_REACTIVATED, ROLE_ASSIGNED, ROLE_REVOKED, PERMISSION_ASSIGNED, PERMISSION_REVOKED)
+- Actor ID is required (identifies who performed the action)
+- Timestamp is auto-generated at creation
+- Event payload contains relevant details specific to the event type
+- Record is immutable once created (no updates or deletes allowed)
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive log request] --> B{Valid event type?}
+    B -->|No| C[Return error: INVALID_EVENT_TYPE]
+    B -->|Yes| D{Actor ID provided?}
+    D -->|No| E[Return error: MISSING_REQUIRED_FIELD]
+    D -->|Yes| F[Generate timestamp]
+    F --> G[Create AuditEvent record]
+    G --> H[Return created event]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **INVALID_EVENT_TYPE**: Event type is not one of the recognized types - return validation error with list of valid event types
+- **MISSING_REQUIRED_FIELD**: Actor ID not provided - return validation error indicating actor ID is required

package/src/modules/user-management/docs/commands/ReactivateUser.md

@@ -0,0 +1,37 @@
+# ReactivateUser
+
+## Overview
+
+ReactivateUser transitions a user from INACTIVE status back to ACTIVE status, restoring their access to the system. This command is used when a previously offboarded user returns, such as a contractor returning for a new engagement or a reinstated employee.
+
+Only users in INACTIVE status can be reactivated. Historical associations and role assignments are preserved and become active again.
+
+## Business Rules
+
+- User must exist in the system
+- User must be in INACTIVE status
+- Transitions user status from INACTIVE to ACTIVE
+- Preserves historical role assignments and associations
+- Generates USER_REACTIVATED audit event with actor ID, timestamp, and previous status
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive reactivate request] --> B{User exists?}
+    B -->|No| C[Return error: USER_NOT_FOUND]
+    B -->|Yes| D{Status is INACTIVE?}
+    D -->|No| E[Return error: INVALID_STATUS_TRANSITION]
+    D -->|Yes| F[Update status to ACTIVE]
+    F --> G[Log USER_REACTIVATED audit event]
+    G --> H[Return updated user]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_NOT_FOUND**: User ID does not exist in the system - return not found error with the provided ID
+- **INVALID_STATUS_TRANSITION**: User is not in INACTIVE status (PENDING or already ACTIVE) - return error with current status and valid transitions

package/src/modules/user-management/docs/commands/RevokePermissionFromRole.md

@@ -0,0 +1,40 @@
+# RevokePermissionFromRole
+
+## Overview
+
+RevokePermissionFromRole removes an association between a permission and a role, revoking that permission from all users who have the role assigned. This command is used when restructuring role capabilities or removing permissions that are no longer appropriate.
+
+The association must exist before it can be revoked.
+
+## Business Rules
+
+- Role must exist in the system
+- Permission must exist in the system
+- RolePermission association must exist
+- Removes the RolePermission association record
+- Generates PERMISSION_REVOKED audit event with actor ID, role ID, permission ID, and timestamp
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive revoke request] --> B{Role exists?}
+    B -->|No| C[Return error: ROLE_NOT_FOUND]
+    B -->|Yes| D{Permission exists?}
+    D -->|No| E[Return error: PERMISSION_NOT_FOUND]
+    D -->|Yes| F{Assignment exists?}
+    F -->|No| G[Return error: ASSIGNMENT_NOT_FOUND]
+    F -->|Yes| H[Delete RolePermission record]
+    H --> I[Log PERMISSION_REVOKED audit event]
+    I --> J[Return success]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **ROLE_NOT_FOUND**: Role ID does not exist in the system - return not found error with the provided role ID
+- **PERMISSION_NOT_FOUND**: Permission ID does not exist in the system - return not found error with the provided permission ID
+- **ASSIGNMENT_NOT_FOUND**: Role does not have this permission assigned - return not found error indicating the association does not exist

package/src/modules/user-management/docs/commands/RevokeRoleFromUser.md

@@ -0,0 +1,40 @@
+# RevokeRoleFromUser
+
+## Overview
+
+RevokeRoleFromUser removes an association between a role and a user, revoking all permissions that the user had through that role. This command is used when a user changes positions, leaves a project, or no longer requires the access granted by the role.
+
+The association must exist before it can be revoked.
+
+## Business Rules
+
+- User must exist in the system
+- Role must exist in the system
+- UserRole association must exist
+- Removes the UserRole association record
+- Generates ROLE_REVOKED audit event with actor ID, user ID, role ID, and timestamp
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Receive revoke request] --> B{User exists?}
+    B -->|No| C[Return error: USER_NOT_FOUND]
+    B -->|Yes| D{Role exists?}
+    D -->|No| E[Return error: ROLE_NOT_FOUND]
+    D -->|Yes| F{Assignment exists?}
+    F -->|No| G[Return error: ASSIGNMENT_NOT_FOUND]
+    F -->|Yes| H[Delete UserRole record]
+    H --> I[Log ROLE_REVOKED audit event]
+    I --> J[Return success]
+```
+
+## External Dependencies
+
+- None
+
+## Error Scenarios
+
+- **USER_NOT_FOUND**: User ID does not exist in the system - return not found error with the provided user ID
+- **ROLE_NOT_FOUND**: Role ID does not exist in the system - return not found error with the provided role ID
+- **ASSIGNMENT_NOT_FOUND**: User does not have this role assigned - return not found error indicating the association does not exist

package/src/modules/user-management/docs/features/audit-trail.md

@@ -0,0 +1,80 @@
+# Audit Trail
+
+## Overview
+
+The Audit Trail captures immutable records of all security-relevant events in the User Management module. Every user lifecycle change, role assignment, and permission modification is logged with the actor identity, timestamp, and event details. These records cannot be modified or deleted, ensuring a trustworthy history for compliance and security investigations.
+
+This feature provides the foundation for regulatory compliance and security forensics across the ERP system.
+
+## Business Purpose
+
+Organizations require audit trails for multiple reasons:
+
+- **Regulatory Compliance**: SOX, GDPR, HIPAA, and other regulations mandate tracking of access and authorization changes
+- **Security Investigations**: When incidents occur, audit logs reveal who did what and when
+- **Access Reviews**: Periodic reviews of who has access to what rely on historical assignment data
+- **Accountability**: Users knowing their actions are logged encourages responsible behavior
+- **Change Tracking**: Understanding how access evolved over time supports troubleshooting and planning
+
+## Process Flow
+
+```mermaid
+flowchart TD
+    A[Security Event Occurs] --> B[Capture Event Details]
+    B --> C[Record Actor Identity]
+    C --> D[Record Timestamp]
+    D --> E[Record Event Type]
+    E --> F[Record Event Payload]
+    F --> G[Store Immutable Record]
+    G --> H[Available for Query]
+
+    subgraph Event Types
+    I[USER_CREATED]
+    J[USER_ACTIVATED]
+    K[USER_DEACTIVATED]
+    L[USER_REACTIVATED]
+    M[ROLE_ASSIGNED]
+    N[ROLE_REVOKED]
+    O[PERMISSION_ASSIGNED]
+    P[PERMISSION_REVOKED]
+    end
+
+    subgraph Immutability
+    G --> Q[No UPDATE Allowed]
+    G --> R[No DELETE Allowed]
+    end
+```
+
+## Scenario Patterns
+
+- **User Creation Audit**: When admin creates new user, system logs USER_CREATED event with admin ID, new user details, and timestamp. Provides accountability for onboarding.
+- **Status Transition Audit**: User activation logs USER_ACTIVATED with old status (PENDING) and new status (ACTIVE). Complete state change history maintained.
+- **Role Assignment Audit**: Assigning "Sales Manager" role to user logs ROLE_ASSIGNED with assigner ID, user ID, role ID, and timestamp. Tracks who granted elevated access.
+- **Permission Change Audit**: Adding permission to role logs PERMISSION_ASSIGNED. Even though permission affects many users through the role, the change itself is tracked.
+- **Compliance Query**: Auditor requests all access changes for specific user over past year. System returns chronological list of all role assignments and revocations.
+- **Incident Investigation**: Security team investigates unauthorized data access. Audit trail reveals user's roles at time of access and who assigned those roles.
+- **Bulk Operations**: Even bulk operations (e.g., deactivating multiple users) generate individual audit entries for each user affected.
+
+## Test Cases
+
+- Creating a user should generate USER_CREATED audit entry
+- Activating a user should generate USER_ACTIVATED entry with previous status
+- Deactivating a user should generate USER_DEACTIVATED entry with previous status
+- Reactivating a user should generate USER_REACTIVATED entry with previous status
+- Assigning role to user should generate ROLE_ASSIGNED entry
+- Revoking role from user should generate ROLE_REVOKED entry
+- Assigning permission to role should generate PERMISSION_ASSIGNED entry
+- Revoking permission from role should generate PERMISSION_REVOKED entry
+- Audit entries should include actor ID (who performed the action)
+- Audit entries should include timestamp (when action occurred)
+- Audit entries should be immutable (no update operation allowed)
+- Audit entries should be immutable (no delete operation allowed)
+- Querying audit by user ID should return all entries related to that user
+- Querying audit by date range should return entries within range
+- Querying audit by event type should filter appropriately
+
+## Reference Links
+
+- [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+- [NIST Audit and Accountability](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+- [SOX Compliance Requirements](https://www.soxlaw.com/)