Table of Contents

Adding or editing context files

Important

The DataMiner Assistant app is an upcoming feature that is not yet available in current DataMiner versions. The information below provides a preview of what will be available in a future release and may be subject to change.

Context files provide background information, rules, and logic about specific DataMiner concepts. These files help the Assistant reason about the system and provide accurate answers. Only Skyline Communications employees can add or edit context files at this stage. The instructions below are for internal use only.

💡 TIPS TO TAKE FLIGHT
If you are looking for information about adding context specific to your organization, which will be possible once the Assistant becomes available, you might be looking for custom user context.
Skye

How to contribute to the context files

There are two ways to contribute to the context files:

  • Via GitHub:

    1. Fork the private DataMinerAssistant repository.

      You can find the existing context files in the Context folder.

    2. Make your changes. If you want to add a new context file, make sure to follow the template below.

      Tip

      See Contributing guide: Adding a new page.

    3. Create a pull request to submit your changes.

  • Via Team Documentation: Send an overview of changes or your new markdown file directly to Team Documentation, following the template below. They will review your contribution for language, structure, and clarity before merging it into the repository.

Best practices

  • Follow the structure of the template and maintain consistent formatting.

  • Avoid complex language and unnecessary information.

  • Be clear. If the content is confusing, the Assistant may misinterpret it.

  • Avoid duplicate information.

  • Keep sections short and structured. Lists and tables help.

  • Avoid including too many examples. This may limit the Assistant's flexibility in reasoning.

  • Avoid including speculative or incomplete information.

Context file template

Below is a template you can use to write a new context file. Replace the placeholders with information relevant to your DataMiner topic. Examples are included in comments to illustrate the expected structure. Make sure to remove these examples before submitting your context file.

# <Concept name>

<!-- Example: # Alarms -->

## Background information

<Provide an overview of the concept.>

<!-- Example: In DataMiner, an alarm is a notification indicating a condition or event requiring attention. Alarms are triggered by predefined thresholds, user-defined conditions, or background processes.-->

### <Subtopic 1>

<!-- Example: ### Clearable alarms-->

<Describe key details for the subtopic.>

<!-- Example:
- When an alarm is clearable, the issue has been resolved but the alarm record still remains open.
- `Status = Clearable`
-->

### <Subtopic 2>

<!-- Example: ### Masked alarms-->

<Describe key details for the subtopic.>

<!-- Example:
- A masked alarm is an alarm that a user has deliberately suppressed for a period of time or until it is unmasked or cleared.
- `Comments` field: Provides more information about the masked alarm, e.g. who masked it, when was it masked, and how long will it remain masked. For example: `Element masked by <name> @ 2025-08-28 08:43:38 until unmasking`
-->

### <Subtopic 3>

<!-- Example: ### Interpretation guidelines-->

<Describe key details for the subtopic.>

<!-- Example:
- The age of an active alarm (how long it has been active) does not reflect its seriousness.
- Severity levels `Normal` and `Suggestion` are not considered alarms.
- An alarm is resolved when `Status = Cleared`.
- (...)
-->

## Rules

### General rules

<Provide general rules for interpreting, using, or reporting this concept.>

<!-- Example:
- Always use values from the provided dataset; NEVER invent names, parameters, severities, or numbers.
- Validate whether all element, parameter, time, and service names exist in the dataset before including them.
- (...)
-->

### (Optional) Counting rules

<Provide rules for counting, filtering, or interpreting items.>

<!-- Example:
- Active alarms:
  - `Is active = 1`.
  - `Status ∈ {Open, Clearable, Mask}`.
  - `Severity ∈ {Warning, Minor, Major, Critical, Notice, Error, Timeout}`.
- Masked alarms:
  - `Is active = 1`
  - `Status = Mask`.
  - `Severity ∈ {Warning, Minor, Major, Critical, Notice, Error, Timeout}`
- (...)
-->

### (Optional) Formatting rules

<Include formatting rules.>

<!-- Example:
- When generating a table of alarms, always include these columns, if available:
  - `#`
  - `Element name`
  - `Parameter description`
  - `Value`
  - `Severity`
  - `Root time`
  - `Status`
- (...)
-->

## (Optional) Situations and response rules

Each situation is **mutually exclusive**. Only follow the one that matches the user request most closely.

### Situation: <Situation name>

<!-- Example: ### Situation: Active alarms needing attention -->

**Trigger**: <Describe when this situation applies.>

<!-- Example: **Trigger**: When the user asks what active alarms need attention. -->

**Instructions**:

- <Step 1 of the response instructions.>
- <Step 2 of the response instructions.>
- <Include formatting rules, charts, or tables if relevant.>

<!-- Example:
- Respond with a to-do list of active alarms that should be addressed first.
- Ask whether the user would like specific resolution steps for these alarms.
- Use **bold** for element and parameter names.
-->
Note

The Situations and response rules section is optional. Only include it if you want the Assistant to handle certain questions in a specific way. If no situations are defined, the Assistant will respond to user questions as it deems appropriate based on the available context.

Improve this page