Repository: meshery/meshery
Pull request #14475: Improved Documentation for Contributing To Notification Center
Author: login: FaheemOnHub
Labels: name: area/docs
description: Documentation update needed
Created: 2025-04-21T13:55:51Z | Merged: 2025-04-22T14:54:24Z

**PR Description**

- This PR adds comprehensive documentation for contributing to the Meshery UI Notification Center. It includes detailed sections on:
- Metadata Formatter
Details on how event metadata is processed and displayed, including types of formatters (specific and dynamic).

- How Notification Metadata is Rendered
Explanation of the rendering logic and fallback mechanisms.

- Key Files and Directories
Overview of essential files and directories for working on the Notification Center.

- Event-Specific Formatters
Documentation for formatters like Error Formatter, Model Registration Formatter, Relationship Evaluation Formatter, Dry Run Formatter, Deployment Summary Formatter, and PropertyFormatters.

- When to use existing formatters and props used by these formatters.



**[Signed commits](https://github.com/meshery/meshery/blob/master/CONTRIBUTING.md#signing-off-on-commits-developer-certificate-of-origin)**
- [x] Yes, I signed my commits.

<!--
Thank you for contributing to Meshery! 

Contributing Conventions:

1. Include descriptive PR titles with [<component-name>] prepended.
2. Build and test your changes before submitting a PR. 
4. Sign your commits.
5. Include before and after screenshots/terminal output.

By following the community's contribution conventions upfront, the review process will 
be accelerated and your PR merged more quickly.
-->



Diff:
diff --git a/docs/_layouts/default.html b/docs/_layouts/default.html
index 5c1ebe45864f..d1d56b1d46cd 100644
--- a/docs/_layouts/default.html
+++ b/docs/_layouts/default.html
@@ -1,7 +1,7 @@
 <!DOCTYPE html>
 <html lang="en" class="no-js">
   <script src="https://cdn.jsdelivr.net/npm/clipboard@1/dist/clipboard.min.js"></script>
-  <script src="../assets/js/error-code-handler.js"></script>
+  <script src="{{ site.baseurl }}/assets/js/error-code-handler.js"></script>
   {% include_cached head.html title=page.title description=page.abstract %} {%
   include_cached header.html %}
   <body class="td-section dark-mode">
diff --git a/docs/assets/img/notification-center/dry-run-formatter.png b/docs/assets/img/notification-center/dry-run-formatter.png
new file mode 100644
index 000000000000..6fd05f026d5b
Binary files /dev/null and b/docs/assets/img/notification-center/dry-run-formatter.png differ
diff --git a/docs/assets/img/notification-center/error-formatter.png b/docs/assets/img/notification-center/error-formatter.png
new file mode 100644
index 000000000000..edf08b8cdc4c
Binary files /dev/null and b/docs/assets/img/notification-center/error-formatter.png differ
diff --git a/docs/assets/img/notification-center/model-register-formatter.png b/docs/assets/img/notification-center/model-register-formatter.png
new file mode 100644
index 000000000000..9729d3582660
Binary files /dev/null and b/docs/assets/img/notification-center/model-register-formatter.png differ
diff --git a/docs/assets/img/notification-center/relationship-evaluation-formatter.png b/docs/assets/img/notification-center/relationship-evaluation-formatter.png
new file mode 100644
index 000000000000..9b013a25707d
Binary files /dev/null and b/docs/assets/img/notification-center/relationship-evaluation-formatter.png differ
diff --git a/docs/pages/project/contributing/contributing-ui-notification-center.md b/docs/pages/project/contributing/contributing-ui-notification-center.md
index 9f0f79a118e0..0a308d3033d5 100644
--- a/docs/pages/project/contributing/contributing-ui-notification-center.md
+++ b/docs/pages/project/contributing/contributing-ui-notification-center.md
@@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+## Types of Event Specific Notification Formatters
+
+### Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+### Error Formatter
+
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+<a href="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png"><img alt="Error Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png" /></a>
 
-The `TypingFilter` component accepts the following props:
+**When to Use:**
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+### Model Registration Formatter
 
+The `Model Registration Formatter` formats and displays model registration details, including components and relationships, in Meshery UI's Notification Center. It ensures structured representation of imported models and error handling during the import process.
 
-## Finite State Machine (FSM) for `TypingFilter` Component
+**Path:** `ui/components/NotificationCenter/formatters/model_registration.js`
 
-This section provides an overview of the Finite State Machine (FSM) implementation used to manage the state of the `TypingFilter` component. The FSM is responsible for handling user interactions, such as selecting filters, entering values, and clearing the filter, within the component. The FSM implementation within the `TypingFilter` component ensures that user interactions are correctly processed and managed, resulting in a smooth and intuitive filtering experience.
+**Components:**
 
-**Table of Contents**
+1. **UnsuccessfulEntityWithError**: This component is used to handle error cases during model import. It identifies the type and count of entities that failed to import.
 
-- [Overview](#overview)
-- [State Definitions](#state-definitions)
-- [Reducers](#reducers)
-- [State Transitions](#state-transitions)
-- [Initial State Handling](#initial-state-handling)
+   **Props:**
 
-### State Definitions
+   - `modelName` (string): The name of the model being imported.
+   - `error` (object): Contains details about the error encountered during import.
 
-The FSM code defines three sets of constants to represent important elements within the state management:
+2. **ModelImportedSection**: Displays the details of the imported model along with components, relationships, and any errors that occur.
 
-#### 1. `FILTERING_STATE`
+   **Props:**
 
-Defines the possible states that the `TypingFilter` component can be in. These states include:
-- `IDLE`: Represents the initial state when the component is not actively filtering.
-- `SELECTING_FILTER`: Indicates that the user is selecting a filter.
-- `SELECTING_VALUE`: Indicates that the user is entering a filter value.
+   - `modelDetails` (object) – Contains model import data.
 
-#### 2. `FILTER_EVENTS`
+<a href="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png"><img alt="Model Register Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png" /></a>
 
-Represents the events that trigger state transitions within the FSM. Some of the events include:
-- `START`: Initiates the filtering process.
-- `SELECT`: Indicates the selection of a filter.
-- `INPUT_CHANGE`: Represents a change in the filter input.
-- `CLEAR`: Clears the filter.
-- `EXIT`: Exits the filtering process.
+### Relationship Evaluation Formatter
 
-#### 3. `Delimiter`
+The **Relationship Evaluation Formatter** is responsible for rendering notifications related to the evaluation of relationships between components in a design. It provides a detailed breakdown of changes in components and relationships, such as additions, updates, and removals, during the evaluation process.
 
-Defines delimiters used to separate filter and value entries within the component. Delimiters include:
-- `FILTER`: Separates multiple filters.
-- `FILTER_VALUE`: Separates filters from their corresponding values.
+**Path:** `ui/components/NotificationCenter/formatters/relationship_evaluation.js`
 
-### Reducers
+#### Key Components
 
-The FSM implementation includes two key reducer functions:
+1. **RelationshipEvaluationEventFormatter**:  
+   The main formatter component that renders the event description and invokes the `RelationshipEvaluationTraceFormatter` to display detailed traces.
 
-#### 1. `commonReducer`
+**Props:**
 
-This common reducer function handles events that are common across all states. It includes logic to handle "CLEAR" and "EXIT" events, which reset the component's state and clear any entered values.
+- `event` (object): Contains:
+  - **description**: A description of the evaluation process.
+  - **metadata.trace**: Contains categorized changes in components and relationships:
+    - `componentsAdded` (Array)
+    - `componentsUpdated` (Array)
+    - `componentsRemoved` (Array)
+    - `relationshipsAdded` (Array)
+    - `relationshipsUpdated` (Array)
+    - `relationshipsRemoved` (Array)
 
-#### 2. `filterSelectionReducer`
+<a href="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png"><img alt="Relationship Evaluation Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png" /></a>
 
-The `filterSelectionReducer` is a specific reducer used to manage transitions between "SELECTING_FILTER" and "SELECTING_VALUE" states. It handles events related to selecting filters and entering values. The logic ensures that delimiters are appropriately added or removed when the user interacts with the filter.
+#### When to Use
 
-### State Transitions
+The **Relationship Evaluation Formatter** is specifically designed to handle notifications related to changes in components and their relationships during an evaluation process. Use this formatter in the following scenarios:
 
-State transitions are managed based on user actions and the current state of the component. For example, when the user selects a filter, the state transitions from "SELECTING_FILTER" to "SELECTING_VALUE." When the user inputs values or clears the filter, the state transitions are managed accordingly.
+1. When a notification involves the evaluation of relationships between components in a design.
+2. When you need to display categorized changes in components and relationships.
+3. When the event metadata includes a `trace` object containing detailed information about the changes in components and relationships.
 
-### Initial State Handling
+#### User Experience: Relationship Evaluation Notification
 
-The FSM implementation includes handling for the initial state, where it listens for the "START" event to transition from "IDLE" to "SELECTING_FILTER." This ensures that the filtering process is initiated when the user interacts with the component.
+1. **Evaluation Summary**:  
+   The notification starts with a summary of the evaluation process.  
+   Example:  
+   `"Relationship evaluation completed for design 'Deploy Meshery using Meshery-X' at version '0.0.11'"`  
+   This gives the user context about which design and version were evaluated.
 
-## Bulk Operations
+2. **Detailed Changes**:  
+   The notification breaks down the changes into categories:
 
-Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+   - **Components**:
+     - **Added**: New components introduced in the design.
+     - **Updated**: Existing components that were modified.
+     - **Removed**: Components that were deleted from the design.
+   - **Relationships**:
+     - **Added**: New relationships established between components.
+     - **Updated**: Existing relationships that were modified.
+     - **Removed**: Relationships that were deleted.
 
-**How It Works**
+3. **Component Details**:  
+   For each component, the notification displays:
 
-### Initiating a Bulk Operation
+   - **Kind**: The type of the component (e.g., `Deployment`, `Service`).
+   - **Name**: The name of the component.
+   - **Model and Version**: The model and version associated with the component.
 
-- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
-- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
-- Once initiated, the bulk operation begins processing the selected notifications.
+4. **Relationship Details**:  
+   For each relationship, the notification displays:
+   - **Type**: The type of relationship.
+   - **Source and Target**: The components involved in the relationship (e.g., `Pod` to `Pod`).
+   - **Model and Version**: The model and version associated with the relationship.
 
-### Further Enchacements
+### Dry Run Formatter
 
-To ensure a seamless user experience with bulk operations in the Notification Center, consider the following best practices:
+The **Dry Run Formatter** is responsible for rendering notifications related to the dry run validation of a design. A dry run simulates the deployment or undeployment of a design to identify potential errors without actually applying the changes.
 
-- Provide clear and concise messaging to inform users about the progress and outcome of the bulk operation.
-- Implement error handling to gracefully handle any issues that may arise during the operation and communicate errors to the user.
-- Consider offering a confirmation dialog before initiating a bulk operation to prevent accidental actions.
+**Path:** `ui/components/DesignLifeCycle/DryRun.js`
 
+#### Key Components
 
-## Metadata Formatter
+1. **FormatDryRunResponse**:  
+   The main formatter component that renders the dry run validation results. It displays the total number of errors.
 
-When an event is received from the server, it adheres to a fixed schema containing information that is valuable for presentation to the user. This information typically includes details such as the description, date, user_id, system_id, action, and acted-upon resources. Additionally, sometimes there may be a detailed traceback, a summary, or a comprehensive error log, all of which are dynamically generated data encapsulated within the metadata of the event. Presenting this structured data in a user-friendly manner is a crucial task because it contains valuable insights into ongoing operations.
+**Props:**
 
-To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+- **dryRunErrors** (array): An array of errors detected during the dry run. Each error includes:
+  - `type`: The type of error (e.g., `RequestError`, `ComponentError`).
+  - `fieldPath`: The specific field in the design where the error occurred.
+  - `message`: A detailed error message.
+- **configurableComponentsCount** (number): The number of configurable components in the design.
+- **annotationComponentsCount** (number): The number of annotation components in the design.
+- **validationMachine** (object): The state machine handling the dry run validation process.
+- **currentComponentName** (string): The name of the component currently being validated.
 
-1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
-2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
-     - Text strings are rendered using the BodySectionRenderer (more on this later).
-     - Arrays are rendered using the ArrayRenderer.
-     - Key-value pairs are rendered using the KeyValueRenderer.
-     - Nested objects are recursively rendered.
+<a href="{{ site.baseurl }}/assets/img/notification-center/dry-run-formatter.png"><img alt="Dry Run Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/dry-run-formatter.png" /></a>
 
-### BodySectionRenderer
-The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+#### When to Use
 
-### ArrayRenderer
-The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+The **Dry Run Formatter** is used in the following scenarios:
 
-### KeyValueRenderer
-Object properties with string values are considered key-value pairs and are rendered as such.
+1. When a notification involves the validation of a design through a dry run process.
+2. When you need to display errors detected during the dry run.
+3. When the event metadata includes details about configurable and annotation components.
 
-### The Metadata Specific Formatter
-Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+## Deployment Summary Formatter
 
-### Reusability
-While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+The **Deployment Summary Formatter** is responsible for rendering notifications related to the deployment or undeployment of components in a design.
+
+**Path:** `ui/components/DesignLifeCycle/DeploymentSummary.js`
+
+#### Key Components
+
+1. **DeploymentSummaryFormatter**:  
+   This component is used to display:
+   - **Event Description**: A brief description of the deployment event.
+   - **Errors**: Any errors encountered during the deployment process.
+   - **Component Details**: A list of components with their deployment status and metadata.
+
+**Props:**
 
+- **event** (object): Contains:
+  - **description**: A brief description of the deployment event.
+  - **action**: The type of action performed (e.g., `deploy`, `undeploy`).
+  - **severity**: The severity level of the event.
+  - **metadata**:
+    - **summary**: A detailed summary of the deployment process, including component details.
+    - **error**: Any errors encountered during the deployment process.
+    - **design_name**: The name of the design being deployed.
+    - **design_id**: The ID of the design being deployed.
+
+#### When to Use
+
+The **Deployment Summary Formatter** should be used in the following scenarios:
+
+1. **Deployment or Undeployment Events**:  
+   When the `event.action` is either `deploy` or `undeploy` and the `event.metadata` includes `design_name`.
+2. When a notification involves the deployment or undeployment of a design.
+
+### PropertyFormatters and PropertyLinkFormatters
+
+**Purpose:**  
+When an event does not match an event in `EventTypeFormatters`, **PropertyFormatters** and **PropertyLinkFormatters** are used to format and render specific metadata fields in a structured and visually appealing way.
+
+#### Examples of Property Formatters
+
+1. **trace**: Converts large trace data into a downloadable file link.
+2. **ShortDescription**: Displays a short description of the event.
+3. **Error**: Uses the `ErrorMetadataFormatter` to display structured error details.
+
+#### When to Use
+
+Use **PropertyFormatters** and **PropertyLinkFormatters** in the following scenarios:
+
+1. When an event does not have a specific `EventTypeFormatter` defined.
+2. When you need to render individual metadata fields in a structured and visually appealing way.
+3. When metadata includes fields like trace data, short descriptions, or error details that require specialized formatting.
+
+---


Reviews:
user: login: gemini-code-assist[bot]
body: Hello @FaheemOnHub, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

## Summary of Changes
This pull request focuses on improving the documentation for contributing to the Meshery UI Notification Center. It introduces detailed explanations of the Notification Center's purpose, metadata formatting, key files and directories, and specific event formatters. The documentation aims to guide contributors in understanding and working with the Notification Center effectively.

### Highlights
* **Notification Center Overview**: Introduces the Notification Center as a central panel in Meshery's UI for monitoring and responding to system events.
* **Metadata Formatting**: Explains the use of metadata-specific and dynamic formatters to present structured data in a user-friendly manner.
* **Key Files and Directories**: Outlines essential files and directories for working on Notification Center metadata formatters, including `NotificationCenter/`, `formatters/`, `index.js`, `metadata.js`, and `notification.js`.
* **Event-Specific Formatters**: Documents various event-specific formatters such as Error Formatter, Model Registration Formatter, Relationship Evaluation Formatter, Dry Run Formatter, and Deployment Summary Formatter, detailing their purpose, props, and usage.
* **Bulk Operations**: Documents the functionality of bulk operations in the Notification Center, including initiating bulk operations and future enhancements.

### Changelog
<details>
<summary>Click here to see the changelog</summary>

* **docs/_layouts/default.html**
  * Updated the script source URL for `error-code-handler.js` to use `{{ site.baseurl }}` for correct path resolution.
* **docs/pages/project/contributing/contributing-ui-notification-center.md**
  * Added an introductory section explaining the purpose and function of the Notification Center.
  * Replaced italicized text with emphasized text for future notification status.
  * Added documentation for bulk operations in the Notification Center.
  * Added documentation for Metadata Formatters, including Metadata Specific Formatters and Dynamic Formatters.
  * Added documentation for how notification metadata is rendered, including event-specific formatter checks and fallback mechanisms.
  * Added documentation for key files and directories related to the Notification Center.
  * Added documentation for various event-specific formatters, including Common Formatter, Error Formatter, Model Registration Formatter, Relationship Evaluation Formatter, Dry Run Formatter, and Deployment Summary Formatter.
  * Added documentation for PropertyFormatters and PropertyLinkFormatters.

</details>


<details>

<summary><b>Using Gemini Code Assist</b></summary>
<br>

The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips.

<b>Invoking Gemini</b>

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands.

Feature | Command | Description
--- | --- | ---
Code Review | `/gemini review` | Performs a code review for the current pull request in its current state.
Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state.
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments.
Help | `/gemini help` | Displays a list of available commands.

<b>Customization</b>

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github).

<b>Limitations & Feedback</b>

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments to provide feedback.

</details>

<b>You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the [Gemini Code Assist IDE Extension](https://cloud.google.com/products/gemini/code-assist).</b>


[^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/review-github-code). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).

---

> A notification's tale,
> Metadata's structured scale,
> Formatters refine,
> Insights brightly shine,
> In Meshery's UI trail.


state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-21T13:56:02Z
user: login: gemini-code-assist[bot]
body: ## Code Review
This PR introduces comprehensive documentation for contributing to the Meshery UI Notification Center, covering metadata formatters, rendering logic, key files, and specific formatters. The documentation is well-structured and provides valuable information for contributors. However, there are a few areas where improvements can be made to enhance clarity and completeness.

### Summary of Findings
* **Inconsistent Heading Levels**: The documentation uses inconsistent heading levels, which can affect the overall structure and readability. Ensure that heading levels are used hierarchically to represent the content's organization effectively.
* **Missing Examples for Some Formatters**: While some formatters have examples, others lack them. Providing examples for all formatters would greatly enhance the documentation's usability and understanding.
* **Grammar and Typos**: There are a few grammatical errors and typos in the documentation. Proofreading the content would improve its professionalism and credibility.

### Merge Readiness
The documentation provides a good overview of the Meshery UI Notification Center and its components. Addressing the identified issues related to heading levels, missing examples, and grammatical errors would significantly improve the documentation's quality and make it more valuable for contributors. I am unable to approve this pull request, and recommend that others review and approve this code before merging.
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-21T13:56:16Z
user: login: zihanKuang
body: Hi @FaheemOnHub , thanks so much for the great work on this!

1. **Just a small suggestion regarding visual clarity**: you might consider removing the horizontal rules (`---`) throughout the document. Since the sections are already clearly separated, the extra lines can make the page feel a bit visually heavy.

2. **About the heading structure**: it could be helpful to streamline the hierarchy a bit. For example, the top-level heading `## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>` might not be necessary and could potentially be removed. Also, using `##` for primary sections and `###` for subsections consistently across the document would improve readability and structure.

3. **Given the document’s length**, it might be helpful to add a short table of contents near the beginning that lists the main `##` sections. This could make it easier for readers to navigate through the content and get an overview of what’s included.
state: CHANGES_REQUESTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-21T17:42:58Z
user: login: zihanKuang
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-21T17:55:07Z
user: login: zihanKuang
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-22T14:42:22Z
user: login: zihanKuang
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-22T14:53:25Z

Review comments:
diff_hunk: @@ -21,6 +21,14 @@ list: include
  Your browser does not support the video tag
 </video>
 
+---
+
+### What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
> Want to understand how users interact with the Notification Center? [Learn more here]({{ site.baseurl }}/guides/infrastructure-management/notification-management/user-intent).
```
created_at: 2025-04-21T17:24:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -40,182 +48,348 @@ The `NotificationCenter` component of Meshery UI Switching to Graphql subscripti
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+## Bulk Operations
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Bulk Operations
```
created_at: 2025-04-21T17:25:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -40,182 +48,348 @@ The `NotificationCenter` component of Meshery UI Switching to Graphql subscripti
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+## Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+**How It Works**
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
```
created_at: 2025-04-21T17:29:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -40,182 +48,348 @@ The `NotificationCenter` component of Meshery UI Switching to Graphql subscripti
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+## Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+**How It Works**
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Initiating a Bulk Operation
 
-### Notification Filtering and Searching
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
 
-**Table of Contents**
+## Metadata Formatter
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+When an event is received from the server, it adheres to a fixed schema containing information that is valuable for presentation to the user. This information typically includes details such as the description, date, user_id, system_id, action, and acted-upon resources. Additionally, sometimes there may be a detailed traceback, a summary, or a comprehensive error log, all of which are dynamically generated data encapsulated within the metadata of the event. Presenting this structured data in a user-friendly manner is a crucial task because it contains valuable insights into ongoing operations.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+---
+
+### How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
+
+---
+
+### Key Files and Directories
+
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
+
+#### `NotificationCenter/` _(Root Directory)_
+
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
+
+#### `formatters/` _(NotificationCenter/formatters)_
+
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
+
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
+
+---
+
+### Types of Event Specific Notification Formatters
+
+### Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+---
 
-### Usage
+### Error Formatter
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+**When to Use:**
 
-The `TypingFilter` component accepts the following props:
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+---
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+### Model Registration Formatter
 
+The `Model Registration Formatter` formats and displays model registration details, including components and relationships, in Meshery UI's Notification Center. It ensures structured representation of imported models and error handling during the import process.
 
-## Finite State Machine (FSM) for `TypingFilter` Component
+**Path:** `ui/components/NotificationCenter/formatters/model_registration.js`
 
-This section provides an overview of the Finite State Machine (FSM) implementation used to manage the state of the `TypingFilter` component. The FSM is responsible for handling user interactions, such as selecting filters, entering values, and clearing the filter, within the component. The FSM implementation within the `TypingFilter` component ensures that user interactions are correctly processed and managed, resulting in a smooth and intuitive filtering experience.
+**Components:**
 
-**Table of Contents**
+1. **UnsuccessfulEntityWithError**: This component is used to handle error cases during model import. It identifies the type and count of entities that failed to import.
 
-- [Overview](#overview)
-- [State Definitions](#state-definitions)
-- [Reducers](#reducers)
-- [State Transitions](#state-transitions)
-- [Initial State Handling](#initial-state-handling)
+   **Props:**
 
-### State Definitions
+   - `modelName` (string): The name of the model being imported.
+   - `error` (object): Contains details about the error encountered during import.
 
-The FSM code defines three sets of constants to represent important elements within the state management:
+2. **ModelImportedSection**: Displays the details of the imported model along with components, relationships, and any errors that occur.
 
-#### 1. `FILTERING_STATE`
+   **Props:**
 
-Defines the possible states that the `TypingFilter` component can be in. These states include:
-- `IDLE`: Represents the initial state when the component is not actively filtering.
-- `SELECTING_FILTER`: Indicates that the user is selecting a filter.
-- `SELECTING_VALUE`: Indicates that the user is entering a filter value.
+   - `modelDetails` (object) – Contains model import data.
 
-#### 2. `FILTER_EVENTS`
+---
 
-Represents the events that trigger state transitions within the FSM. Some of the events include:
-- `START`: Initiates the filtering process.
-- `SELECT`: Indicates the selection of a filter.
-- `INPUT_CHANGE`: Represents a change in the filter input.
-- `CLEAR`: Clears the filter.
-- `EXIT`: Exits the filtering process.
+### Relationship Evaluation Formatter
 
-#### 3. `Delimiter`
+The **Relationship Evaluation Formatter** is responsible for rendering notifications related to the evaluation of relationships between components in a design. It provides a detailed breakdown of changes in components and relationships, such as additions, updates, and removals, during the evaluation process.
 
-Defines delimiters used to separate filter and value entries within the component. Delimiters include:
-- `FILTER`: Separates multiple filters.
-- `FILTER_VALUE`: Separates filters from their corresponding values.
+**Path:** `ui/components/NotificationCenter/formatters/relationship_evaluation.js`
 
-### Reducers
+---
 
-The FSM implementation includes two key reducer functions:
+#### Key Components
 
-#### 1. `commonReducer`
+1. **RelationshipEvaluationEventFormatter**:  
+   The main formatter component that renders the event description and invokes the `RelationshipEvaluationTraceFormatter` to display detailed traces.
 
-This common reducer function handles events that are common across all states. It includes logic to handle "CLEAR" and "EXIT" events, which reset the component's state and clear any entered values.
+**Props:**
 
-#### 2. `filterSelectionReducer`
+- `event` (object): Contains:
+  - **description**: A description of the evaluation process.
+  - **metadata.trace**: Contains categorized changes in components and relationships:
+    - `componentsAdded` (Array)
+    - `componentsUpdated` (Array)
+    - `componentsRemoved` (Array)
+    - `relationshipsAdded` (Array)
+    - `relationshipsUpdated` (Array)
+    - `relationshipsRemoved` (Array)
 
-The `filterSelectionReducer` is a specific reducer used to manage transitions between "SELECTING_FILTER" and "SELECTING_VALUE" states. It handles events related to selecting filters and entering values. The logic ensures that delimiters are appropriately added or removed when the user interacts with the filter.
+---
 
-### State Transitions
+#### When to Use
 
-State transitions are managed based on user actions and the current state of the component. For example, when the user selects a filter, the state transitions from "SELECTING_FILTER" to "SELECTING_VALUE." When the user inputs values or clears the filter, the state transitions are managed accordingly.
+The **Relationship Evaluation Formatter** is specifically designed to handle notifications related to changes in components and their relationships during an evaluation process. Use this formatter in the following scenarios:
 
-### Initial State Handling
+1. When a notification involves the evaluation of relationships between components in a design.
+2. When you need to display categorized changes in components and relationships.
+3. When the event metadata includes a `trace` object containing detailed information about the changes in components and relationships.
 
-The FSM implementation includes handling for the initial state, where it listens for the "START" event to transition from "IDLE" to "SELECTING_FILTER." This ensures that the filtering process is initiated when the user interacts with the component.
+---
 
-## Bulk Operations
+#### User Experience: Relationship Evaluation Notification
 
-Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+1. **Evaluation Summary**:  
+   The notification starts with a summary of the evaluation process.  
+   Example:  
+   `"Relationship evaluation completed for design 'Deploy Meshery using Meshery-X' at version '0.0.11'"`  
+   This gives the user context about which design and version were evaluated.
 
-**How It Works**
+2. **Detailed Changes**:  
+   The notification breaks down the changes into categories:
 
-### Initiating a Bulk Operation
+   - **Components**:
+     - **Added**: New components introduced in the design.
+     - **Updated**: Existing components that were modified.
+     - **Removed**: Components that were deleted from the design.
+   - **Relationships**:
+     - **Added**: New relationships established between components.
+     - **Updated**: Existing relationships that were modified.
+     - **Removed**: Relationships that were deleted.
 
-- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
-- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
-- Once initiated, the bulk operation begins processing the selected notifications.
+3. **Component Details**:  
+   For each component, the notification displays:
 
-### Further Enchacements
+   - **Kind**: The type of the component (e.g., `Deployment`, `Service`).
+   - **Name**: The name of the component.
+   - **Model and Version**: The model and version associated with the component.
 
-To ensure a seamless user experience with bulk operations in the Notification Center, consider the following best practices:
+4. **Relationship Details**:  
+   For each relationship, the notification displays:
+   - **Type**: The type of relationship.
+   - **Source and Target**: The components involved in the relationship (e.g., `Pod` to `Pod`).
+   - **Model and Version**: The model and version associated with the relationship.
 
-- Provide clear and concise messaging to inform users about the progress and outcome of the bulk operation.
-- Implement error handling to gracefully handle any issues that may arise during the operation and communicate errors to the user.
-- Consider offering a confirmation dialog before initiating a bulk operation to prevent accidental actions.
+---
 
+### Dry Run Formatter
 
-## Metadata Formatter
+The **Dry Run Formatter** is responsible for rendering notifications related to the dry run validation of a design. A dry run simulates the deployment or undeployment of a design to identify potential errors without actually applying the changes.
 
-When an event is received from the server, it adheres to a fixed schema containing information that is valuable for presentation to the user. This information typically includes details such as the description, date, user_id, system_id, action, and acted-upon resources. Additionally, sometimes there may be a detailed traceback, a summary, or a comprehensive error log, all of which are dynamically generated data encapsulated within the metadata of the event. Presenting this structured data in a user-friendly manner is a crucial task because it contains valuable insights into ongoing operations.
+**Path:** `ui/components/DesignLifeCycle/DryRun.js`
 
-To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+---
 
-1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
-2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
-     - Text strings are rendered using the BodySectionRenderer (more on this later).
-     - Arrays are rendered using the ArrayRenderer.
-     - Key-value pairs are rendered using the KeyValueRenderer.
-     - Nested objects are recursively rendered.
+#### Key Components
 
-### BodySectionRenderer
-The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+1. **FormatDryRunResponse**:  
+   The main formatter component that renders the dry run validation results. It displays the total number of errors.
 
-### ArrayRenderer
-The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+**Props:**
 
-### KeyValueRenderer
-Object properties with string values are considered key-value pairs and are rendered as such.
+- **dryRunErrors** (array): An array of errors detected during the dry run. Each error includes:
+  - `type`: The type of error (e.g., `RequestError`, `ComponentError`).
+  - `fieldPath`: The specific field in the design where the error occurred.
+  - `message`: A detailed error message.
+- **configurableComponentsCount** (number): The number of configurable components in the design.
+- **annotationComponentsCount** (number): The number of annotation components in the design.
+- **validationMachine** (object): The state machine handling the dry run validation process.
+- **currentComponentName** (string): The name of the component currently being validated.
 
-### The Metadata Specific Formatter
-Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+---
 
-### Reusability
-While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+#### When to Use
+
+The **Dry Run Formatter** is used in the following scenarios:
+
+1. When a notification involves the validation of a design through a dry run process.
+2. When you need to display errors detected during the dry run.
+3. When the event metadata includes details about configurable and annotation components.
+
+---
+
+### Deployment Summary Formatter
+
+The **Deployment Summary Formatter** is responsible for rendering notifications related to the deployment or undeployment of components in a design.
+
+**Path:** `ui/components/DesignLifeCycle/DeploymentSummary.js`
+
+---
+
+#### Key Components
+
+1. **DeploymentSummaryFormatter**:  
+   This component is used to display:
+   - **Event Description**: A brief description of the deployment event.
+   - **Errors**: Any errors encountered during the deployment process.
+   - **Component Details**: A list of components with their deployment status and metadata.
+
+**Props:**
+
+- **event** (object): Contains:
+  - **description**: A brief description of the deployment event.
+  - **action**: The type of action performed (e.g., `deploy`, `undeploy`).
+  - **severity**: The severity level of the event.
+  - **metadata**:
+    - **summary**: A detailed summary of the deployment process, including component details.
+    - **error**: Any errors encountered during the deployment process.
+    - **design_name**: The name of the design being deployed.
+    - **design_id**: The ID of the design being deployed.
+
+---
+
+#### When to Use
+
+The **Deployment Summary Formatter** should be used in the following scenarios:
+
+1. **Deployment or Undeployment Events**:  
+   When the `event.action` is either `deploy` or `undeploy` and the `event.metadata` includes `design_name`.
+2. When a notification involves the deployment or undeployment of a design.
+
+---
+
+### PropertyFormatters and PropertyLinkFormatters
+
+**Purpose:**  
+When an event does not match an event in `EventTypeFormatters`, **PropertyFormatters** and **PropertyLinkFormatters** are used to format and render specific metadata fields in a structured and visually appealing way.
+
+---
+
+#### Examples of Property Formatters
+
+1. **trace**: Converts large trace data into a downloadable file link.
+2. **ShortDescription**: Displays a short description of the event.
+3. **Error**: Uses the `ErrorMetadataFormatter` to display structured error details.
+
+---
+
+#### When to Use
+
+Use **PropertyFormatters** and **PropertyLinkFormatters** in the following scenarios:
+
+1. When an event does not have a specific `EventTypeFormatter` defined.
+2. When you need to render individual metadata fields in a structured and visually appealing way.
+3. When metadata includes fields like trace data, short descriptions, or error details that require specialized formatting.
+
+---
 
+### How to Add a New EventType Formatter(?)
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
```
created_at: 2025-04-21T17:30:36Z
author_association: CONTRIBUTOR
diff_hunk: @@ -40,182 +48,348 @@ The `NotificationCenter` component of Meshery UI Switching to Graphql subscripti
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+## Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+**How It Works**
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Initiating a Bulk Operation
 
-### Notification Filtering and Searching
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
 
-**Table of Contents**
+## Metadata Formatter
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+When an event is received from the server, it adheres to a fixed schema containing information that is valuable for presentation to the user. This information typically includes details such as the description, date, user_id, system_id, action, and acted-upon resources. Additionally, sometimes there may be a detailed traceback, a summary, or a comprehensive error log, all of which are dynamically generated data encapsulated within the metadata of the event. Presenting this structured data in a user-friendly manner is a crucial task because it contains valuable insights into ongoing operations.
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.  

In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.  

Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
```
created_at: 2025-04-21T17:34:53Z
author_association: CONTRIBUTOR
diff_hunk: @@ -21,6 +21,14 @@ list: include
  Your browser does not support the video tag
 </video>
 
+---
+
+### What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+> Want to understand how users interact with the Notification Center? [Learn more here]({{ site.baseurl }}/guides/infrastructure-management/notification-management/user-intent).
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion

> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).

```
created_at: 2025-04-21T17:55:07Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
## Types of Event Specific Notification Formatters
```
created_at: 2025-04-22T14:15:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Common Formatter
```
created_at: 2025-04-22T14:15:34Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+## Error Formatter
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Error Formatter
```
created_at: 2025-04-22T14:15:42Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+## Error Formatter
+
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+<a href="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png"><img alt="Error Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png" /></a>
 
-The `TypingFilter` component accepts the following props:
+**When to Use:**
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+## Model Registration Formatter
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Model Registration Formatter
```
created_at: 2025-04-22T14:15:58Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+## Error Formatter
+
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+<a href="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png"><img alt="Error Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png" /></a>
 
-The `TypingFilter` component accepts the following props:
+**When to Use:**
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+## Model Registration Formatter
 
+The `Model Registration Formatter` formats and displays model registration details, including components and relationships, in Meshery UI's Notification Center. It ensures structured representation of imported models and error handling during the import process.
 
-## Finite State Machine (FSM) for `TypingFilter` Component
+**Path:** `ui/components/NotificationCenter/formatters/model_registration.js`
 
-This section provides an overview of the Finite State Machine (FSM) implementation used to manage the state of the `TypingFilter` component. The FSM is responsible for handling user interactions, such as selecting filters, entering values, and clearing the filter, within the component. The FSM implementation within the `TypingFilter` component ensures that user interactions are correctly processed and managed, resulting in a smooth and intuitive filtering experience.
+**Components:**
 
-**Table of Contents**
+1. **UnsuccessfulEntityWithError**: This component is used to handle error cases during model import. It identifies the type and count of entities that failed to import.
 
-- [Overview](#overview)
-- [State Definitions](#state-definitions)
-- [Reducers](#reducers)
-- [State Transitions](#state-transitions)
-- [Initial State Handling](#initial-state-handling)
+   **Props:**
 
-### State Definitions
+   - `modelName` (string): The name of the model being imported.
+   - `error` (object): Contains details about the error encountered during import.
 
-The FSM code defines three sets of constants to represent important elements within the state management:
+2. **ModelImportedSection**: Displays the details of the imported model along with components, relationships, and any errors that occur.
 
-#### 1. `FILTERING_STATE`
+   **Props:**
 
-Defines the possible states that the `TypingFilter` component can be in. These states include:
-- `IDLE`: Represents the initial state when the component is not actively filtering.
-- `SELECTING_FILTER`: Indicates that the user is selecting a filter.
-- `SELECTING_VALUE`: Indicates that the user is entering a filter value.
+   - `modelDetails` (object) – Contains model import data.
 
-#### 2. `FILTER_EVENTS`
+<a href="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png"><img alt="Model Register Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png" /></a>
 
-Represents the events that trigger state transitions within the FSM. Some of the events include:
-- `START`: Initiates the filtering process.
-- `SELECT`: Indicates the selection of a filter.
-- `INPUT_CHANGE`: Represents a change in the filter input.
-- `CLEAR`: Clears the filter.
-- `EXIT`: Exits the filtering process.
+## Relationship Evaluation Formatter
 
-#### 3. `Delimiter`
+The **Relationship Evaluation Formatter** is responsible for rendering notifications related to the evaluation of relationships between components in a design. It provides a detailed breakdown of changes in components and relationships, such as additions, updates, and removals, during the evaluation process.
 
-Defines delimiters used to separate filter and value entries within the component. Delimiters include:
-- `FILTER`: Separates multiple filters.
-- `FILTER_VALUE`: Separates filters from their corresponding values.
+**Path:** `ui/components/NotificationCenter/formatters/relationship_evaluation.js`
 
-### Reducers
+#### Key Components
 
-The FSM implementation includes two key reducer functions:
+1. **RelationshipEvaluationEventFormatter**:  
+   The main formatter component that renders the event description and invokes the `RelationshipEvaluationTraceFormatter` to display detailed traces.
 
-#### 1. `commonReducer`
+**Props:**
 
-This common reducer function handles events that are common across all states. It includes logic to handle "CLEAR" and "EXIT" events, which reset the component's state and clear any entered values.
+- `event` (object): Contains:
+  - **description**: A description of the evaluation process.
+  - **metadata.trace**: Contains categorized changes in components and relationships:
+    - `componentsAdded` (Array)
+    - `componentsUpdated` (Array)
+    - `componentsRemoved` (Array)
+    - `relationshipsAdded` (Array)
+    - `relationshipsUpdated` (Array)
+    - `relationshipsRemoved` (Array)
 
-#### 2. `filterSelectionReducer`
+<a href="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png"><img alt="Relationship Evaluation Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png" /></a>
 
-The `filterSelectionReducer` is a specific reducer used to manage transitions between "SELECTING_FILTER" and "SELECTING_VALUE" states. It handles events related to selecting filters and entering values. The logic ensures that delimiters are appropriately added or removed when the user interacts with the filter.
+#### When to Use
 
-### State Transitions
+The **Relationship Evaluation Formatter** is specifically designed to handle notifications related to changes in components and their relationships during an evaluation process. Use this formatter in the following scenarios:
 
-State transitions are managed based on user actions and the current state of the component. For example, when the user selects a filter, the state transitions from "SELECTING_FILTER" to "SELECTING_VALUE." When the user inputs values or clears the filter, the state transitions are managed accordingly.
+1. When a notification involves the evaluation of relationships between components in a design.
+2. When you need to display categorized changes in components and relationships.
+3. When the event metadata includes a `trace` object containing detailed information about the changes in components and relationships.
 
-### Initial State Handling
+#### User Experience: Relationship Evaluation Notification
 
-The FSM implementation includes handling for the initial state, where it listens for the "START" event to transition from "IDLE" to "SELECTING_FILTER." This ensures that the filtering process is initiated when the user interacts with the component.
+1. **Evaluation Summary**:  
+   The notification starts with a summary of the evaluation process.  
+   Example:  
+   `"Relationship evaluation completed for design 'Deploy Meshery using Meshery-X' at version '0.0.11'"`  
+   This gives the user context about which design and version were evaluated.
 
-## Bulk Operations
+2. **Detailed Changes**:  
+   The notification breaks down the changes into categories:
 
-Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+   - **Components**:
+     - **Added**: New components introduced in the design.
+     - **Updated**: Existing components that were modified.
+     - **Removed**: Components that were deleted from the design.
+   - **Relationships**:
+     - **Added**: New relationships established between components.
+     - **Updated**: Existing relationships that were modified.
+     - **Removed**: Relationships that were deleted.
 
-**How It Works**
+3. **Component Details**:  
+   For each component, the notification displays:
 
-### Initiating a Bulk Operation
+   - **Kind**: The type of the component (e.g., `Deployment`, `Service`).
+   - **Name**: The name of the component.
+   - **Model and Version**: The model and version associated with the component.
 
-- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
-- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
-- Once initiated, the bulk operation begins processing the selected notifications.
+4. **Relationship Details**:  
+   For each relationship, the notification displays:
+   - **Type**: The type of relationship.
+   - **Source and Target**: The components involved in the relationship (e.g., `Pod` to `Pod`).
+   - **Model and Version**: The model and version associated with the relationship.
 
-### Further Enchacements
+## Dry Run Formatter
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Dry Run Formatter
```
created_at: 2025-04-22T14:16:11Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+## Error Formatter
+
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+<a href="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png"><img alt="Error Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png" /></a>
 
-The `TypingFilter` component accepts the following props:
+**When to Use:**
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+## Model Registration Formatter
 
+The `Model Registration Formatter` formats and displays model registration details, including components and relationships, in Meshery UI's Notification Center. It ensures structured representation of imported models and error handling during the import process.
 
-## Finite State Machine (FSM) for `TypingFilter` Component
+**Path:** `ui/components/NotificationCenter/formatters/model_registration.js`
 
-This section provides an overview of the Finite State Machine (FSM) implementation used to manage the state of the `TypingFilter` component. The FSM is responsible for handling user interactions, such as selecting filters, entering values, and clearing the filter, within the component. The FSM implementation within the `TypingFilter` component ensures that user interactions are correctly processed and managed, resulting in a smooth and intuitive filtering experience.
+**Components:**
 
-**Table of Contents**
+1. **UnsuccessfulEntityWithError**: This component is used to handle error cases during model import. It identifies the type and count of entities that failed to import.
 
-- [Overview](#overview)
-- [State Definitions](#state-definitions)
-- [Reducers](#reducers)
-- [State Transitions](#state-transitions)
-- [Initial State Handling](#initial-state-handling)
+   **Props:**
 
-### State Definitions
+   - `modelName` (string): The name of the model being imported.
+   - `error` (object): Contains details about the error encountered during import.
 
-The FSM code defines three sets of constants to represent important elements within the state management:
+2. **ModelImportedSection**: Displays the details of the imported model along with components, relationships, and any errors that occur.
 
-#### 1. `FILTERING_STATE`
+   **Props:**
 
-Defines the possible states that the `TypingFilter` component can be in. These states include:
-- `IDLE`: Represents the initial state when the component is not actively filtering.
-- `SELECTING_FILTER`: Indicates that the user is selecting a filter.
-- `SELECTING_VALUE`: Indicates that the user is entering a filter value.
+   - `modelDetails` (object) – Contains model import data.
 
-#### 2. `FILTER_EVENTS`
+<a href="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png"><img alt="Model Register Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png" /></a>
 
-Represents the events that trigger state transitions within the FSM. Some of the events include:
-- `START`: Initiates the filtering process.
-- `SELECT`: Indicates the selection of a filter.
-- `INPUT_CHANGE`: Represents a change in the filter input.
-- `CLEAR`: Clears the filter.
-- `EXIT`: Exits the filtering process.
+## Relationship Evaluation Formatter
 
-#### 3. `Delimiter`
+The **Relationship Evaluation Formatter** is responsible for rendering notifications related to the evaluation of relationships between components in a design. It provides a detailed breakdown of changes in components and relationships, such as additions, updates, and removals, during the evaluation process.
 
-Defines delimiters used to separate filter and value entries within the component. Delimiters include:
-- `FILTER`: Separates multiple filters.
-- `FILTER_VALUE`: Separates filters from their corresponding values.
+**Path:** `ui/components/NotificationCenter/formatters/relationship_evaluation.js`
 
-### Reducers
+#### Key Components
 
-The FSM implementation includes two key reducer functions:
+1. **RelationshipEvaluationEventFormatter**:  
+   The main formatter component that renders the event description and invokes the `RelationshipEvaluationTraceFormatter` to display detailed traces.
 
-#### 1. `commonReducer`
+**Props:**
 
-This common reducer function handles events that are common across all states. It includes logic to handle "CLEAR" and "EXIT" events, which reset the component's state and clear any entered values.
+- `event` (object): Contains:
+  - **description**: A description of the evaluation process.
+  - **metadata.trace**: Contains categorized changes in components and relationships:
+    - `componentsAdded` (Array)
+    - `componentsUpdated` (Array)
+    - `componentsRemoved` (Array)
+    - `relationshipsAdded` (Array)
+    - `relationshipsUpdated` (Array)
+    - `relationshipsRemoved` (Array)
 
-#### 2. `filterSelectionReducer`
+<a href="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png"><img alt="Relationship Evaluation Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/relationship-evaluation-formatter.png" /></a>
 
-The `filterSelectionReducer` is a specific reducer used to manage transitions between "SELECTING_FILTER" and "SELECTING_VALUE" states. It handles events related to selecting filters and entering values. The logic ensures that delimiters are appropriately added or removed when the user interacts with the filter.
+#### When to Use
 
-### State Transitions
+The **Relationship Evaluation Formatter** is specifically designed to handle notifications related to changes in components and their relationships during an evaluation process. Use this formatter in the following scenarios:
 
-State transitions are managed based on user actions and the current state of the component. For example, when the user selects a filter, the state transitions from "SELECTING_FILTER" to "SELECTING_VALUE." When the user inputs values or clears the filter, the state transitions are managed accordingly.
+1. When a notification involves the evaluation of relationships between components in a design.
+2. When you need to display categorized changes in components and relationships.
+3. When the event metadata includes a `trace` object containing detailed information about the changes in components and relationships.
 
-### Initial State Handling
+#### User Experience: Relationship Evaluation Notification
 
-The FSM implementation includes handling for the initial state, where it listens for the "START" event to transition from "IDLE" to "SELECTING_FILTER." This ensures that the filtering process is initiated when the user interacts with the component.
+1. **Evaluation Summary**:  
+   The notification starts with a summary of the evaluation process.  
+   Example:  
+   `"Relationship evaluation completed for design 'Deploy Meshery using Meshery-X' at version '0.0.11'"`  
+   This gives the user context about which design and version were evaluated.
 
-## Bulk Operations
+2. **Detailed Changes**:  
+   The notification breaks down the changes into categories:
 
-Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+   - **Components**:
+     - **Added**: New components introduced in the design.
+     - **Updated**: Existing components that were modified.
+     - **Removed**: Components that were deleted from the design.
+   - **Relationships**:
+     - **Added**: New relationships established between components.
+     - **Updated**: Existing relationships that were modified.
+     - **Removed**: Relationships that were deleted.
 
-**How It Works**
+3. **Component Details**:  
+   For each component, the notification displays:
 
-### Initiating a Bulk Operation
+   - **Kind**: The type of the component (e.g., `Deployment`, `Service`).
+   - **Name**: The name of the component.
+   - **Model and Version**: The model and version associated with the component.
 
-- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
-- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
-- Once initiated, the bulk operation begins processing the selected notifications.
+4. **Relationship Details**:  
+   For each relationship, the notification displays:
+   - **Type**: The type of relationship.
+   - **Source and Target**: The components involved in the relationship (e.g., `Pod` to `Pod`).
+   - **Model and Version**: The model and version associated with the relationship.
 
-### Further Enchacements
+## Dry Run Formatter
 
-To ensure a seamless user experience with bulk operations in the Notification Center, consider the following best practices:
+The **Dry Run Formatter** is responsible for rendering notifications related to the dry run validation of a design. A dry run simulates the deployment or undeployment of a design to identify potential errors without actually applying the changes.
 
-- Provide clear and concise messaging to inform users about the progress and outcome of the bulk operation.
-- Implement error handling to gracefully handle any issues that may arise during the operation and communicate errors to the user.
-- Consider offering a confirmation dialog before initiating a bulk operation to prevent accidental actions.
+**Path:** `ui/components/DesignLifeCycle/DryRun.js`
 
+#### Key Components
 
-## Metadata Formatter
+1. **FormatDryRunResponse**:  
+   The main formatter component that renders the dry run validation results. It displays the total number of errors.
 
-When an event is received from the server, it adheres to a fixed schema containing information that is valuable for presentation to the user. This information typically includes details such as the description, date, user_id, system_id, action, and acted-upon resources. Additionally, sometimes there may be a detailed traceback, a summary, or a comprehensive error log, all of which are dynamically generated data encapsulated within the metadata of the event. Presenting this structured data in a user-friendly manner is a crucial task because it contains valuable insights into ongoing operations.
+**Props:**
 
-To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+- **dryRunErrors** (array): An array of errors detected during the dry run. Each error includes:
+  - `type`: The type of error (e.g., `RequestError`, `ComponentError`).
+  - `fieldPath`: The specific field in the design where the error occurred.
+  - `message`: A detailed error message.
+- **configurableComponentsCount** (number): The number of configurable components in the design.
+- **annotationComponentsCount** (number): The number of annotation components in the design.
+- **validationMachine** (object): The state machine handling the dry run validation process.
+- **currentComponentName** (string): The name of the component currently being validated.
 
-1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
-2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
-     - Text strings are rendered using the BodySectionRenderer (more on this later).
-     - Arrays are rendered using the ArrayRenderer.
-     - Key-value pairs are rendered using the KeyValueRenderer.
-     - Nested objects are recursively rendered.
+<a href="{{ site.baseurl }}/assets/img/notification-center/dry-run-formatter.png"><img alt="Dry Run Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/dry-run-formatter.png" /></a>
 
-### BodySectionRenderer
-The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+#### When to Use
 
-### ArrayRenderer
-The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+The **Dry Run Formatter** is used in the following scenarios:
 
-### KeyValueRenderer
-Object properties with string values are considered key-value pairs and are rendered as such.
+1. When a notification involves the validation of a design through a dry run process.
+2. When you need to display errors detected during the dry run.
+3. When the event metadata includes details about configurable and annotation components.
 
-### The Metadata Specific Formatter
-Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+## Deployment Summary Formatter
 
-### Reusability
-While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+The **Deployment Summary Formatter** is responsible for rendering notifications related to the deployment or undeployment of components in a design.
+
+**Path:** `ui/components/DesignLifeCycle/DeploymentSummary.js`
+
+#### Key Components
+
+1. **DeploymentSummaryFormatter**:  
+   This component is used to display:
+   - **Event Description**: A brief description of the deployment event.
+   - **Errors**: Any errors encountered during the deployment process.
+   - **Component Details**: A list of components with their deployment status and metadata.
+
+**Props:**
 
+- **event** (object): Contains:
+  - **description**: A brief description of the deployment event.
+  - **action**: The type of action performed (e.g., `deploy`, `undeploy`).
+  - **severity**: The severity level of the event.
+  - **metadata**:
+    - **summary**: A detailed summary of the deployment process, including component details.
+    - **error**: Any errors encountered during the deployment process.
+    - **design_name**: The name of the design being deployed.
+    - **design_id**: The ID of the design being deployed.
+
+#### When to Use
+
+The **Deployment Summary Formatter** should be used in the following scenarios:
+
+1. **Deployment or Undeployment Events**:  
+   When the `event.action` is either `deploy` or `undeploy` and the `event.metadata` includes `design_name`.
+2. When a notification involves the deployment or undeployment of a design.
+
+## PropertyFormatters and PropertyLinkFormatters
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### PropertyFormatters and PropertyLinkFormatters
```
created_at: 2025-04-22T14:32:46Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,208 +14,366 @@ list: include
   <ol><li><a href="contributing-ui">Contributing to Meshery UI</a></li></ol>
 </div>
 
-## <a name="contributing-ui-notification-center">Contributing to Meshery UI - Notification Center</a>
+## Table of Contents
+
+- [What is the Notification Center?](#what-is-the-notification-center)
+- [Metadata Formatter](#metadata-formatter)
+- [How Notification Metadata is Rendered](#how-notification-metadata-is-rendered)
+- [Types of Event Specific Notification Formatters](#types-of-event-specific-notification-formatters)
+  - [Common Formatter](#common-formatter)
+  - [Error Formatter](#error-formatter)
+  - [Model Registration Formatter](#model-registration-formatter)
+  - [Relationship Evaluation Formatter](#relationship-evaluation-formatter)
+  - [Dry Run Formatter](#dry-run-formatter)
+  - [Deployment Summary Formatter](#deployment-summary-formatter)
+  - [PropertyFormatters and PropertyLinkFormatters](#propertyformatters-and-propertylinkformatters)
 
 <video style="width:min(100%,750px)" height="auto" autoplay muted loop>
   <source src="https://github.com/meshery/meshery/assets/65964225/345672de-3f61-4be0-b3c8-0e7480cc496c" type="video/mp4">
  Your browser does not support the video tag
 </video>
 
+## What is the Notification Center?
+
+The Notification Center is a dedicated panel in Meshery’s UI that helps you monitor, understand, and respond to events across your system. It acts as a central place where you can see important updates related to your infrastructure, workloads, and Meshery’s internal operations.
+
+> Want to understand how users interact with the Notification Center? [Learn more here](https://docs.meshery.io/guides/infrastructure-management/notification-management).
+
+---
+
 The `NotificationCenter` component of Meshery UI Switching to Graphql subscriptions and implementing robust filtering. Events are persisted in Meshery Server and state management on client is done using Redux Toolkit and RTK.
 
-#### User-facing Features
+### User-facing Features
 
 - Robust filtering support inspired by GitHub's notification filtering style.
   - Search is also included.
 - Proper hierarchial presentation of error details, including probable cause and suggested remeditation.
 - Support for notification status (notifications can be marked as read and unread)
-  - *Future: Notifications can be acknowledged or resolved.*
+  - _Future: Notifications can be acknowledged or resolved._
 - Event-based notification via Graphql subscription (provided by Meshery Server and any upstream components or externally managed systems, like Kubernetes)
 - Infinite scroll for pagination.
 
-#### State Management and Internal Details
+### State Management and Internal Details
 
 - The State on client is managed using `Redux Tooltik` and `Rtk-query`
 - Update and Delete operations are optimistically handled.
 - Network Request are cached and are invalidated when new events come or events are deleted/updated.
 - Due to need for infinite scroll and optimistic update the events are stored globally in Redux.
 
-### Notification Severities and Colors
+### Bulk Operations
+
+Bulk operations in the Notification Center allow users to perform actions like deleting multiple notifications or changing the status of multiple notifications in a batch. This documentation outlines the key features and functionality of bulk operations, including the restriction of performing only one bulk operation at a time, the disabling of buttons during ongoing operations, and the display of a loading icon to indicate ongoing activity.
+
+### Initiating a Bulk Operation
+
+- Users select the notifications they want to include in the bulk operation. This is typically done by checking checkboxes next to each notification.
+- After selecting notifications, users trigger the desired bulk operation (e.g., delete or change status) by clicking the corresponding action button.
+- Once initiated, the bulk operation begins processing the selected notifications.
+
+## Metadata Formatter
+
+When the server sends an event, it follows a consistent schema that contains metadata intended for user presentation. This metadata typically includes fields such as `description`, `date`, `user_id`, `system_id`, `action`, and the resources involved.
+
+In some cases, the metadata may also contain more detailed information—such as a traceback, a summary, or a complete error log—which is dynamically generated at runtime and encapsulated within the event.
+
+Presenting this structured information in a clear and accessible way is essential, as it provides valuable insights into system behavior and ongoing operations.
+
+To accomplish this task, we employ metadata formatters that transform structured data into visually appealing formats. There are currently two types of formatters in use:
+
+1. **Metadata Specific Formatters:** These formatters are specifically designed for particular types of metadata, such as Error and DryRunResponse. Metadata Specific Formatters are implemented as React components that take the metadata as input and render it within the component.
+2. **Dynamic Formatter:** Since metadata can vary significantly in structure, it is not practical to create a specific formatter for each kind. Dynamic formatters analyze the schema's structure and apply custom-defined rules for formatting:
+   - Text strings are rendered using the BodySectionRenderer (more on this later).
+   - Arrays are rendered using the ArrayRenderer.
+   - Key-value pairs are rendered using the KeyValueRenderer.
+   - Nested objects are recursively rendered.
+
+### BodySectionRenderer
+
+The BodySectionRenderer is responsible for formatting and rendering raw text strings into React components. During this process, it parses the string to replace external links with `<Link>` components and checks if the link matches predefined sites to render the link accordingly.
+
+### ArrayRenderer
+
+The ArrayRenderer is responsible for rendering an array of items in a recursive manner, presenting them as a bulletized list using the MetdataFormatter.
+
+### KeyValueRenderer
+
+Object properties with string values are considered key-value pairs and are rendered as such.
+
+### The Metadata Specific Formatter
+
+Certain metadata, such as Kubernetes responses and Errors, hold high importance and have dedicated renderers. These dedicated renderers can still utilize the dynamic formatter to format specific parts of the response, such as DryRunResponse.
+
+### Reusability
+
+While this system was initially developed for our events and notification center, the components it comprises are highly reusable and can be employed in other contexts where dynamic formatting of structured data is required.
+
+## How Notification Metadata is Rendered
+
+When a notification event is received from the server, it includes a `metadata` field containing structured, event-specific information. The purpose of formatters is to present this data in a clean, readable, and user-friendly format inside the expanded view of each notification.
+
+The core logic for rendering metadata is handled by the `FormattedMetadata` component in `metadata.js`, which follows this decision tree:
+
+1. **Event-Specific Formatter Check**  
+   If a formatter exists for the event's type (registered under `EventTypeFormatters`), that dedicated formatter is used to fully control how the metadata is displayed.
+
+2. **Fallback to Property-Based Formatting**  
+   If no event-specific formatter is found, the `FormattedMetadata` component falls back to the `FormatStructuredData` function (also in `metadata.js`).
+
+   - This function renders each key-value pair from the `metadata` using the mappings defined in:
+     - `PropertyFormatters` – for structured or specialized visual formats.
+     - `PropertyLinkFormatters` – for rendering clickable links (e.g., file paths, URLs).
 
-Notification severities and colors are defined in the constants file, `ui/components/NotificationCenter/constants.js`.
+### Key Files and Directories
 
-### Notification Filtering and Searching
+This section outlines the essential files and folders that you'll interact with when working on Notification Center metadata formatters.
 
-**Table of Contents**
+#### `NotificationCenter/` _(Root Directory)_
 
-- [Usage](#usage)
-- [Props](#props)
-- [Examples](#examples)
+- **index.js**: Contains the main context provider (`NotificationCenterProvider`), the drawer component (`NotificationCenterDrawer`), and orchestrates the overall structure.
+- **metadata.js**: Defines `PropertyFormatters`, `LinkFormatters`, `PropertyLinkFormatters`, and `EventTypeFormatters`. Contains the `FormattedMetadata` component which decides _how_ to format the metadata based on event type or specific properties.
+- **notification.js**: Defines how an individual notification is rendered.
 
-The Notfication Center includes a resusable component, `TypingFilter`, for sophisticated filtering and searching of notifications based on their attributes. It adheres to the GitHub-style syntax for filtering, offering a straight-forward and adaptable way to filter and search notification details. The `TypingFilter` component is a customizable React component that enables real-time filtering and selection based on user input.
+#### `formatters/` _(NotificationCenter/formatters)_
 
-The state for filtering is managed by a state machine created using a reducer. `TypingFilter` supports multiple filters, suggestions and completions.
+This directory houses reusable formatter components dedicated to specific types of metadata or event types.
 
-### Usage
+- **common.js**: Contains shared components like `TitleLink`, `DataToFileLink`, `EmptyState`.
+- **error.js**: Defines `ErrorMetadataFormatter` for displaying structured error details.
+- **model_registration.js**: Contains formatters for model import/registration events (`ModelImportMessages`, `ModelImportedSection`).
+- **pattern_dryrun.js**: Defines `DryRunResponseFormatter` which utilizes components from `DesignLifeCycle`.
+- **relationship_evaluation.js**: Defines `RelationshipEvaluationEventFormatter` responsible for rendering notifications related to the evaluation of relationships between components in a design.
 
-The `TypingFilter` component is designed to provide an interactive filtering experience in your application. Here's how you can use it:
+### Types of Event Specific Notification Formatters
+
+## Common Formatter
+
+The following reusable components standardize how notification links, empty states, and downloadable traces are displayed:
+
+1. **TitleLink**: Renders a styled title with an external link icon.  
+   Props:
+
+   - `href` (required): URL of the link.
+   - `children`: The link text.
+
+2. **EmptyState**: Displays a description when no specific data is available for an event.  
+   Props:
+
+   - `event.description` (optional): Text description of the event.
+
+3. **DataToFileLink**: Converts event data into a downloadable `.txt` file.  
+   Props:
+   - `data` (required): Can be a string or JSON object.
+
+## Error Formatter
+
+The `ErrorMetadataFormatter` is used for formatting error-related notifications in the Meshery UI Notification Center. It structures error details, probable causes, and suggested remediations in a readable format.
+
+- **Details**: A comprehensive explanation of the error, often broken into multiple points or steps.
+- **Probable Cause**: A list of potential reasons why the error occurred, helping the user understand the root cause.
+- **Suggested Remediation**: Actionable steps or recommendations to resolve the issue.
+- Inside the ellipse menu, the user can find the error code docs link for further explanation of the error.
+
+**Props:**
+
+- `metadata` (object): Contains error metadata fields such as:
+  - `LongDescription`: Provides details about the error.
+  - `ProbableCause`: Lists possible reasons for the error.
+  - `SuggestedRemediation`: Suggests solutions to fix the error.
+- `event` (object, optional): Contains the notification event data.
+
+**Path:** `ui/components/NotificationCenter/formatters/error.js`
+
+**Example:**
 
 ```javascript
-import React from 'react';
-import TypingFilter from './path-to-TypingFilter';
-
-function MyComponent() {
-  // Define a filter schema that describes the available filter options.
-  const filterSchema = {
-    // Define your filter categories here
-    // Example:
-    SEVERITY: {
-      value: "severity",
-      description: "Filter by severity",
-      values: ["Low", "Medium", "High"],
-      multiple : true // default
-    },
-    // Add more filter categories as needed
-  };
-
-  // Define a callback function to handle filter changes.
-  const handleFilterChange = (filteredData) => {
-    // Implement your logic to react to the filtered data.
-    // This function will be called when the user applies a filter. ( on presing enter in input)
-    console.log("Filtered data:", filteredData);
-  };
-
-  return (
-    <div>
-      <TypingFilter
-        filterSchema={filterSchema}
-        handleFilter={handleFilterChange}
-      />
-      {/* Your other components */}
-    </div>
-  );
-}
-
-export default MyComponent;
+<ErrorMetadataFormatter
+  metadata={
+    LongDescription: "An unexpected error occurred while deploying the mesh.",
+    ProbableCause: "Misconfigured Kubernetes cluster.",
+    SuggestedRemediation: "Check your kubeconfig file and retry deployment.",
+  }
+  event={ description: "Mesh deployment failed" }
+/>
 ```
 
-### Props
+<a href="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png"><img alt="Error Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/error-formatter.png" /></a>
 
-The `TypingFilter` component accepts the following props:
+**When to Use:**
 
-- `filterSchema` (object, required): An object that defines available filter options. Each property of this object represents a filter category with the following properties:
-  - `value` (string, required): The filter name used for filtering within the category.
-  - `description` (string, required): Description of the filter category.
-  - `type` (string, optional): The data type of the filter (e.g., "string", "number").
-  - `values` (array, optional): Possible values for the filter.
+The `ErrorMetadataFormatter` is used when dealing with structured error events that follow a pattern (description, cause, remediation). A new formatter should be created only if the error metadata deviates significantly from the `ErrorMetadataFormatter` metadata structure.
 
-- `handleFilter` (function, required): A callback function that is called when the user applies a filter. This function receives the filtered data as an argument.
+## Model Registration Formatter
 
+The `Model Registration Formatter` formats and displays model registration details, including components and relationships, in Meshery UI's Notification Center. It ensures structured representation of imported models and error handling during the import process.
 
-## Finite State Machine (FSM) for `TypingFilter` Component
+**Path:** `ui/components/NotificationCenter/formatters/model_registration.js`
 
-This section provides an overview of the Finite State Machine (FSM) implementation used to manage the state of the `TypingFilter` component. The FSM is responsible for handling user interactions, such as selecting filters, entering values, and clearing the filter, within the component. The FSM implementation within the `TypingFilter` component ensures that user interactions are correctly processed and managed, resulting in a smooth and intuitive filtering experience.
+**Components:**
 
-**Table of Contents**
+1. **UnsuccessfulEntityWithError**: This component is used to handle error cases during model import. It identifies the type and count of entities that failed to import.
 
-- [Overview](#overview)
-- [State Definitions](#state-definitions)
-- [Reducers](#reducers)
-- [State Transitions](#state-transitions)
-- [Initial State Handling](#initial-state-handling)
+   **Props:**
 
-### State Definitions
+   - `modelName` (string): The name of the model being imported.
+   - `error` (object): Contains details about the error encountered during import.
 
-The FSM code defines three sets of constants to represent important elements within the state management:
+2. **ModelImportedSection**: Displays the details of the imported model along with components, relationships, and any errors that occur.
 
-#### 1. `FILTERING_STATE`
+   **Props:**
 
-Defines the possible states that the `TypingFilter` component can be in. These states include:
-- `IDLE`: Represents the initial state when the component is not actively filtering.
-- `SELECTING_FILTER`: Indicates that the user is selecting a filter.
-- `SELECTING_VALUE`: Indicates that the user is entering a filter value.
+   - `modelDetails` (object) – Contains model import data.
 
-#### 2. `FILTER_EVENTS`
+<a href="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png"><img alt="Model Register Formatter" style="width:500px;height:auto;" src="{{ site.baseurl }}/assets/img/notification-center/model-register-formatter.png" /></a>
 
-Represents the events that trigger state transitions within the FSM. Some of the events include:
-- `START`: Initiates the filtering process.
-- `SELECT`: Indicates the selection of a filter.
-- `INPUT_CHANGE`: Represents a change in the filter input.
-- `CLEAR`: Clears the filter.
-- `EXIT`: Exits the filtering process.
+## Relationship Evaluation Formatter
path: docs/pages/project/contributing/contributing-ui-notification-center.md
user: login: zihanKuang
body: ```suggestion
### Relationship Evaluation Formatter
```
created_at: 2025-04-22T14:41:05Z
author_association: CONTRIBUTOR

PR comments:
user: login: github-actions[bot]
created_at: 2025-04-21T13:58:59Z
body: <!-- meshmap-snapshot: do not delete/edit this line -->
[<img src="false">](false) _[View in catalog](https://cloud.layer5.io/catalog/content/design/da342c7a-8020-40db-8579-7a2694e0902b), [Edit in playground](https://playground.meshery.io/extension/meshmap?mode=design&design=da342c7a-8020-40db-8579-7a2694e0902b) or learn how to [interpret Meshery Designs](https://cloud.layer5.io/academy/learning-paths/mastering-meshery/introduction-to-meshery?chapter=interpreting-meshery-designs)_
author_association: CONTRIBUTOR
user: login: l5io
created_at: 2025-04-21T14:04:17Z
body: 🚀 Preview for commit 00eededca61ab506da52545d78b26293b99a715a at: https://6806500781d35c2b9f4a98ff--meshery-docs-preview.netlify.app
author_association: MEMBER
user: login: FaheemOnHub
created_at: 2025-04-21T16:27:44Z
body: @zihanKuang Kindly provide feedback regarding the formatting of the markdown , also if you feel as a user content somewhere needs improvement do tell.
author_association: CONTRIBUTOR
user: login: l5io
created_at: 2025-04-21T17:51:04Z
body: 🚀 Preview for commit db1df78edf7cff76c1e639749d3a4e1484f8b6e9 at: https://68068567496a5e758bf96abc--meshery-docs-preview.netlify.app
author_association: MEMBER
user: login: l5io
created_at: 2025-04-21T18:02:42Z
body: 🚀 Preview for commit e43afaca22018958fc1a99baa941d9510c7a3b6c at: https://68068820afa6e5798b35827d--meshery-docs-preview.netlify.app
author_association: MEMBER
user: login: FaheemOnHub
created_at: 2025-04-22T12:04:35Z
body: @vishalvivekm Kindly review and merge
author_association: CONTRIBUTOR
user: login: l5io
created_at: 2025-04-22T12:10:50Z
body: 🚀 Preview for commit 2314fdf1e44917a3fbc7cc330f9185ef98d7b05a at: https://6807872a6e0bc25a1ee8f5ad--meshery-docs-preview.netlify.app
author_association: MEMBER
user: login: l5io
created_at: 2025-04-22T14:51:55Z
body: 🚀 Preview for commit f43ba6b54813f5d1df68e93664178a705555f0fd at: https://6807aced81e69c0883e46097--meshery-docs-preview.netlify.app
author_association: MEMBER