# Input Logic & Routing Behavior

This page explains how dynamic input variables like `user_region`, `submission_type`, and `user_role` influence policy selection, compliance logic, and escalation behavior within the Global Control Copilot template.

These inputs are extracted via orchestration blocks (e.g., `Parameter Extractor`) and are used to route submissions through jurisdiction-specific logic paths.

***

## 1. Input Sources (Where Values Come From)

| Variable                            | Source Block         | Description                                                       |
| ----------------------------------- | -------------------- | ----------------------------------------------------------------- |
| `sys.files`                         | User Upload          | Contains raw disclosure content (risk, governance, jurisdiction). |
| `user_region`                       | Parameter Extractor  | Set by upstream chat metadata, dropdown, or auto-detected.        |
| `submission_type`                   | Parameter Extractor  | Declared by user form or inferred from workflow setup.            |
| `user_role`                         | Parameter Extractor  | May be prefilled from session or input during form submission.    |
| `risk_exposure`, `checklist_status` | Doc Extractor or LLM | Parsed from `sys.files`, then normalized via enrichment.          |

***

## 2. `user_region`: Determines Policy Source

| Value    | Effect                                                                               |
| -------- | ------------------------------------------------------------------------------------ |
| `EU`     | Loads MiCA policy. Enforces thresholds like €1M exposure, 5-day deadline, etc.       |
| `US`     | Loads SOX-based policy logic. Checks for signoffs and SEC-relevant fields.           |
| `APAC`   | Loads fallback or local templates. Often less rigid in checklist validation.         |
| `Global` | Uses internal generic fallback policy. Used for simulation or pre-alignment testing. |

***

## 3. `submission_type`: Determines Logic Branches

| Value              | Validations Triggered                                         |
| ------------------ | ------------------------------------------------------------- |
| `Disclosure`       | Requires risk, liquidity, governance sections.                |
| `Attestation`      | Requires signatures, audit metadata, compliance officer role. |
| `Exception Report` | Auto-escalates unless a valid policy override is present.     |
| `Incident`         | Evaluates breach detail, event log, and downstream impact.    |

***

## 4. `user_role`: Affects Prompt Tone & Escalation Rules

| Value                | Behavior Adjustments                                              |
| -------------------- | ----------------------------------------------------------------- |
| `Finance Manager`    | Triggers capital/risk validation logic.                           |
| `Legal Counsel`      | Expects attestation chain, stricter audit validation.             |
| `Product Ops`        | Focus on procedural policy routing; may tolerate soft violations. |
| `External Submitter` | Triggers early flagging, stricter trust boundaries.               |

***

## 5. Combined Example

If the submission is from:

* `user_region = EU`
* `submission_type = Disclosure`
* `user_role = Finance Manager`

Then:

* MiCA logic is loaded (via `Knowledge Retrieval`)
* Risk exposure and liquidity sections are required
* Checklist omission triggers escalation
* Summary tone addresses internal financial policy compliance

***

## 6. Required Blocks to Support This

To enable this dynamic behavior, the template must include:

* `Parameter Extractor` → to set `user_region`, `submission_type`, `user_role`
* `Knowledge Retrieval` → to fetch the correct policy content
* `Variable Assigner` → to inject threshold values (e.g., exposure limits)
* `Doc Extractor` or `LLM` → to parse the uploaded file and pull out key sections
* `IF/ELSE` → to branch based on compliance
* `Agent` and `LLM` → to escalate or summarize
* `Save Point` → to log and export session metadata

***

## 7. Code Block Example: Variable Payload

The following is a sample of how these input variables might appear inside the orchestration memory or test payload. This structure is useful for debugging, test configuration, or SDK integration when simulating different jurisdictional conditions.

```yaml
# Example Input Variable Payload
user_region: EU
submission_type: Disclosure
user_role: Finance Manager

# Derived values from parsed file (via LLM or Doc Extractor)
risk_exposure: 4200000
checklist_status: Complete
submission_date: 2025-05-24
policy_reference: MiCA
issuer_name: TokenBridge Capital Ltd.
```

This structure allows downstream logic blocks to reason based on both user-declared context (`user_region`, `submission_type`, `user_role`) and parsed content from uploaded files (`risk_exposure`, `issuer_name`, etc.).

For testing or debugging, these fields can be passed directly into a Variable Assigner block or used as fixed test cases during QA.

***

## 8. Example LLM Prompt Template (Dynamic Inputs)

This is a sample prompt used inside the **LLM reasoning block** to evaluate whether the uploaded compliance submission meets applicable policy requirements. It demonstrates how the system references both declared context variables and parsed data.

```txt
You are a compliance reasoning agent reviewing a policy disclosure report.

Jurisdiction: {{user_region}}  
Submission Type: {{submission_type}}  
User Role: {{user_role}}  
Policy Framework: {{policy_reference}}  

Evaluate the submission based on the following extracted details:

- Issuer: {{issuer_name}}  
- Reported Risk Exposure: €{{risk_exposure}}  
- Capital Buffer Checklist: {{checklist_status}}  
- Submission Date: {{submission_date}}

Determine whether the submission:
1. Meets the policy thresholds based on the loaded policy ({{policy_reference}})
2. Contains all required sections for the submission type ({{submission_type}})
3. Requires escalation based on missing, incomplete, or delayed information

If the submission is compliant, generate a brief summary of why.  
If not, identify the violations and recommend next steps.
```

This pattern ensures consistent reasoning across jurisdictions and allows developers to structure prompt logic around contextual input variables without hardcoding static policy rules.

***

## 9. Escalation Logic Conditions (Examples)

The Global Control Copilot uses conditional logic blocks (like `IF/ELSE`) to evaluate whether a submission meets policy thresholds or requires escalation to a human reviewer. These conditions are derived from both user-declared inputs and parsed values.

Here are example escalation triggers based on variable conditions:

***

#### 🔍 Conditional Logic Triggers

| Condition                                                              | Explanation               | Escalation Action                |
| ---------------------------------------------------------------------- | ------------------------- | -------------------------------- |
| `risk_exposure > 1000000` and `user_region == "EU"`                    | MiCA limit exceeded       | Escalate to compliance analyst   |
| `checklist_status != "Complete"` and `submission_type == "Disclosure"` | Required section missing  | Trigger user guidance + escalate |
| `submission_date > deadline_by_policy`                                 | Late submission           | Flag and route to manual review  |
| `user_role == "External Submitter"` and `attestation_missing == true`  | Trust boundary exceeded   | Auto-escalation with warning     |
| `submission_type == "Exception Report"` and `override_reason == null`  | No justification provided | Block auto-approval and escalate |

***

#### 🧠 Memory Variables Involved

* `risk_exposure` (float)
* `checklist_status` (enum: `Complete`, `Incomplete`, `Missing`)
* `submission_date` (date)
* `user_region`, `user_role`, `submission_type` (string)
* `attestation_missing` (boolean)
* `override_reason` (string/null)

***

#### ✨ Escalation Outputs

When triggered, these conditions typically route the workflow to:

* An `Agent` block (e.g., assigned to a compliance reviewer)
* An `LLM` block to generate a detailed explanation for the user
* A `Save Point` block for logging the flagged session

***

## 10. Auto-Approval Logic Conditions (Examples)

While escalation rules define when to stop and escalate, **auto-approval rules** help define a “clean pass” scenario — where no manual review is needed.

| Condition                                                              | Explanation                 | Auto-Approval Action                     |
| ---------------------------------------------------------------------- | --------------------------- | ---------------------------------------- |
| `risk_exposure <= 1000000` and `user_region == "EU"`                   | MiCA threshold respected    | Allow approval summary generation        |
| `checklist_status == "Complete"` and `submission_type == "Disclosure"` | Disclosure fully filled     | Proceed to HTTP API export               |
| `attestation_verified == true` and `submission_type == "Attestation"`  | External review confirmed   | Mark submission valid without escalation |
| `override_reason != null` and `submission_type == "Exception Report"`  | Justified exception present | Log with reasoning and approve           |
| `submission_date <= policy_deadline`                                   | On-time report              | Skip delay flag, proceed to approval     |

These conditions trigger an `LLM` → `HTTP Request` → `Save Point` path.

***

## 11. Block-Level Wiring Map (Execution Flow Summary)

Below is a high-level description of how these logic conditions are implemented using GLIK Studio blocks:

#### 🔁 Decision Flow in Orchestration

1. **File Upload** (`sys.files`)
   * Ingested at start node or through chat form
2. **Parameter Extractor Block**
   * Sets: `user_region`, `submission_type`, `user_role`
3. **Doc Extractor / LLM Parser Block**
   * Parses `risk_exposure`, `checklist_status`, `attestation_verified`, `submission_date`
4. **IF/ELSE Block — “Is Submission Compliant?”**
   * Evaluates combined conditions:

     ```yaml
     if:
       risk_exposure <= threshold_by_region
       and checklist_status == "Complete"
       and submission_date <= policy_deadline
     ```
5. **IF path → Auto-Approval Track**
   * `LLM Block`: generate approval summary
   * `HTTP Request`: post to compliance API
   * `Save Point`: log session summary
6. **ELSE path → Escalation Track**
   * `Agent Block`: escalate for review
   * `LLM Block`: explain rejection or missing elements
   * `Save Point`: export violation metadata


---

# 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://docs.glik.ai/templates/compliance-advisors/global-control-copilot-cross-jurisdiction-policy-interpreter/input-logic-and-routing-behavior.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.