> ## Documentation Index
> Fetch the complete documentation index at: https://docs.h3aven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

A process is composted by steps. The only important definitions of a process are its `name` and `iconName`.

Each step has its corresponding data parameters.

It is possible to configure a step with no approval order.
If the order needs to be followed, configure the `orderedPolicies` variable. Otherwise, just use the variable \`policyNames

It is possible to configure a step that has dependence on other(s), both approval and reproval dependencies.
For aproval dependencies, you will set variable `stepIdsDependencies` which is and array of step ids as strings.
For reproval dependencies, you will set variable `stepIdsReprovalDependencies` which is and array of step ids as strings.

Ex:

* It is only possible to measure step B, case by step A, this measure approved by all participants. In this case, step B has dependence on step A
* It is only possible to measure step C, if steps A and B are approved by their respective participants. In this case, step A depends on step A and B.
* It is only possible to measure at step E, in case step D is reproved (a reproval of a participant is enough) In this case, step E is dependent on reproval of step D.
* It is only possible to measure at step E, in the case of step D and C, there are reprovadas (just one reproval of a participant in each step) In this case, step E is dependent on the reproval of steps D and C.

The variable `stepIdsDependencies` is an array of ids of other steps, defined when there is a dependence on reproval
A variable `stepIdsReprovalDependencies` is an array of ids of the other steps, defined when there is a reproval dependency

## Deadlines

Each step can have a deadline. The deadline is usually in days. But can also be in hours or weeks.

Checking if a step is delayed only makes sense when analysing the `action` table on the `measurements` object.

### Deadline Types and Units

Deadlines can be configured in different time units:

* **Hours**: For urgent or time-sensitive steps requiring quick action
* **Days**: Most common unit for standard business processes
* **Weeks**: For long-term processes with extended timelines

### Deadline Scenarios

#### 1. Single Policy Group Deadline

If a step has only one policy group and a user from that group performs a WRITE\_DATA action, the step becomes delayed when the deadline period expires without any APPROVAL or REJECTION action from the same group.

**Example**: Step A with policyName "P1", deadline of 24 hours

* User from P1 writes data at 10:00 AM
* Step is delayed if no approval/rejection occurs by 10:00 AM next day

#### 2. Multiple Policy Groups Deadline (Sequential)

If, for example, there's a measurement for Process 1 with steps A with policyNames "P1" and "P2", with a defined deadline of 2 days, and user P1 has already measured step 1 on measurement X, the step is delayed when 48 hours have passed after the WRITE\_ACTION of step 1 on measurement X and no other action by users form group P2 has taken place. Either be it an approval or rejection action.

#### 3. Multiple Policy Groups Deadline (Parallel)

For steps requiring actions from multiple policy groups without ordered dependencies, the deadline applies to the entire step completion. The step becomes delayed when:

* All required policy groups must complete their actions within the deadline period
* Delay occurs if any group fails to act within the deadline timeframe

**Example**: Step B with policyNames "P1", "P2", "P3", deadline of 3 days

* WRITE\_DATA occurs at Day 0
* Step is delayed if any group (P1, P2, or P3) hasn't approved/rejected by Day 3

#### 4. Ordered Policy Groups Deadline

When `orderedPolicies` is configured, each policy group has its own deadline window:

* First group (orderedPolicies\[0]) has full deadline period
* Subsequent groups have remaining time from previous actions
* Step becomes delayed when any ordered group misses their action window

**Example**: Step C with orderedPolicies \["P1", "P2"], deadline of 4 days

* P1 must act within 4 days of WRITE\_DATA
* P2 must act within remaining time after P1's action
* If P1 acts on Day 2, P2 has 2 days remaining

#### 5. Dependency-Based Deadlines

Steps with dependencies inherit deadline pressure from parent steps:

**Approval Dependencies**: A step cannot be measured until all dependent steps are approved

* Deadline pressure cascades to dependent steps
* If parent step is delayed, dependent steps may become time-critical

**Reproval Dependencies**: Steps that activate only when other steps are reproved

* Deadlines apply from the moment the reproval dependency is satisfied
* New deadline window starts when reproval occurs

#### 6. Rolling Deadline Extensions

In complex workflows, deadlines can effectively extend through step dependencies:

* Each step maintains its own deadline
* But effective completion time depends on dependency chain
* System tracks both individual step deadlines and overall process timeline

#### 7. Escalation Deadlines

Steps can have escalation rules where delays trigger:

* Automatic notifications to supervisors
* Escalation to higher authority groups
* Process suspension or intervention requirements

### Deadline Calculation Logic

Deadlines are calculated from the timestamp of the most recent WRITE\_DATA action on that step within a measurement. The system checks for delays by:

1. Finding the latest WRITE\_DATA action for the step in the measurement
2. Adding the deadline duration to that timestamp
3. Checking if required APPROVAL/REJECTION actions occurred before deadline expiration
4. For multiple policy groups, ensuring all required groups have acted

### Deadline Monitoring

The system continuously monitors:

* Individual step deadline compliance
* Policy group action completion
* Dependency chain status
* Overall process timeline health

Delay status affects:

* Step accessibility (delayed steps may block dependent steps)
* Process reporting and analytics
* Escalation workflows
* Compliance tracking

## Relationship Graph (bullets)

* Step.process -> Process (Step N — 1 Process) \[fk: processId -> id] (onDelete: Cascade)
* Data.step -> Step (Data N — 1 Step) \[fk: stepId -> id]
* Parameter.step -> Step (Parameter N — 1 Step) \[fk: stepId -> id] (optional) (onDelete: SetNull)
* OptionItem.parameter -> Parameter (OptionItem N — 1 Parameter) \[fk: parameterId -> id] (optional)
* AdvancedOptions.parameter -> Parameter (AdvancedOptions 1 — 1 Parameter) \[fk: parameterId -> id] (optional) (unique: parameterId)

### Measurement

Measurement.process → Process (Measurement N — 1 Process) \[fk: processId → id]
Measurement.actions → Action (Measurement 1 — N Action) \[fk: measurementId → id]

### Action

Action.step → Step (Action N — 1 Step) \[fk: stepId → id] (onDelete: Cascade)
Action.measurement → Measurement (Action N — 1 Measurement) \[fk: measurementId → id] (optional)

## Cardinality Summary (one line per pair)

* Process ↔ Step: Process 1 — N Step
* Step ↔ Data: Step 1 — N Data
* Step ↔ Parameter: Step 1 — N Parameter (optional on Parameter)
* Parameter ↔ Data: Parameter 1 — N Data (optional on Data)
* Parameter ↔ OptionItem: Parameter 1 — N OptionItem (optional on OptionItem)
* Parameter ↔ AdvancedOptions: Parameter 1 — 1 AdvancedOptions (optional on both sides; parameterId unique)
* Parameter ↔ Parameter: self 1 — N (optional child fk) \[relation: "listParameters"]
* Measurement	↔	Action	1 — N (optional)	Action.measurementId is nullable

# Measurement

## Relationship Graph

The `Measurement` is an object of the class `Process`

Process is how the measurement works, the measurement holds the actual operational data.

Measurements are composed of actions.

There are 3 types of actions:

* WRITE\_DATA: used when writing some data on the process.
* APPROVAL: used when a user is required to approve some WRITE\_DATA action in a measurement
* REJECTION: used when a user is required to approve some WRITE\_DATA action in a measurement