# Cooling Period

The cooling period is the defined time window during which A.M.M.Q executes quant trading. It exists to ensure:

·      Real execution occurs (not instant settlement)

·      Liquidity and market operations have time to run

·      Outcomes reflect a structured cycle rather than a click-to-profit mechanic

Longer tiers have longer cycles because larger capital scales typically require more stable execution windows.

#### No early exit rule

The Quant Index is round-based. Once a participant enters a round, the position is part of the system’s liquidity continuity.

Allowing unrestricted early exits can create:

·      Sudden liquidity drops

·      Chain disruption for subsequent participants

·      Unstable cycle rhythm

Therefore the system requires round completion before maturity actions occur.

#### Transfer at maturity

After the cooling period ends, the position reaches maturity and must be transferred to the next participant. This “relay” structure is designed to:

·      Keep positions flowing rather than stagnant

·      Maintain continuous market participation

·      Prevent permanent occupancy of high-advantage positions

#### Cap mechanism

Each Quant Index position operates under a value cap. If the cap is reached:

·      The system triggers a reset process

·      Cycles restart under the defined rules

The cap mechanism exists to prevent:

·      Unbounded “snowball” expansion

·      Permanent early-participant dominance

·      Structural imbalance that blocks new participation

#### Decomposition / reset mechanism

Decomposition Reset is the system’s sustainability reset cycle. Mechanically, it functions as:

·      A season-like restart

·      A reduction of structural advantage accumulation

·      A return to a new cycle baseline under the rules

It is designed to preserve long-term viability by preventing the system from locking into irreversible advantage distribution.

#### Random value-increase mechanism (constrained)

Each round outcome is generated within a defined range (tier-dependent). The mechanism is described as random within bounds, but constrained by system rules to keep outcomes manageable and discourage fixed-return expectations.

**Design principles**

·      Outcomes are not discretionary manual overrides.

·      Outcomes are not unlimited compounding engines.

·      Outcomes remain within tier-based ranges.

·      Outcomes are constrained by lifecycle control layers.

**The three constraint layers**

1. Cooling period constraint\
   Ensures outcomes are produced only after execution time, supporting “trade-first, settle-later” operation.
2. Cap constraint\
   Prevents indefinite expansion beyond the value ceiling.
3. Decomposition/reset constraint\
   Prevents permanent advantage accumulation and allows the system to continue sustainably across cycles.

**Illustrative outcome engine (high-level)**

The exact production algorithm may be implementation-specific. The following is an illustrative high-level logic model:

1\.        Confirm maturity and execution completion.

2\.        Determine tier-based outcome bounds (min/max).

3\.        Evaluate system state flags (cap reached, decomposition state, abnormal execution state).

4\.        Generate a candidate outcome using a bounded distribution.

5\.        Validate candidate outcome against constraints and safety rules.

6\.        Finalise outcome and enable transfer.

**Illustrative pseudocode (non-binding)**

if round\_not\_completed:\
  outcome = null\
\
else:\
  bounds = tier\_min\_max(tier)\
  candidate = random\_draw(bounds, distribution="bounded")\
\
  if cap\_reached(position) or decomposition\_triggered:\
    candidate = adjust\_or\_reset(candidate)\
\
  if system\_health\_flagged:\
    candidate = apply\_safety\_constraints(candidate)\
\
  outcome = clamp(candidate, bounds)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://uniko.gitbook.io/uniko-whitepaper/uniko-quant-index/cooling-period.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.