# Input Combinations & Workflow Outcomes

This page documents how different combinations of `user_region`, `submission_type`, and `user_role` affect the internal logic, escalation rules, policy loading, and summary tone of the **Global Control Copilot – Cross-Jurisdiction Policy Interpreter** template.

These input-driven workflows are designed to route compliance submissions through highly contextual decision paths, driven by both upstream metadata and parsed file content.

This guide is intended to be the **authoritative reference** for engineers and template builders. It anticipates all major decision-making branches and ensures you have everything needed to implement or extend the template — no need to search elsewhere.

***

### 🧩 1. Why Inputs Matter

The Global Control Copilot is built for reuse across multiple jurisdictions, policy types, and team roles. These three inputs drive that adaptability:

| Input Variable    | Controls                                                                |
| ----------------- | ----------------------------------------------------------------------- |
| `user_region`     | Which policy schema (e.g., MiCA, SOX, GDPR) is loaded                   |
| `submission_type` | What content is expected (e.g., checklist, audit trail, risk report)    |
| `user_role`       | How strictly the submission is evaluated and how LLM feedback is framed |

***

### 📋 2. Input Combination Matrix (Quick Reference)

| Region | Type             | Role               | Policy Loaded           | Escalation Trigger                | Approval Condition                        |
| ------ | ---------------- | ------------------ | ----------------------- | --------------------------------- | ----------------------------------------- |
| EU     | Disclosure       | Finance Manager    | MiCA                    | Exposure > €1M, checklist missing | Risk exposure ≤ €1M, checklist = Complete |
| US     | Attestation      | Legal Counsel      | SOX                     | Missing CFO signoff, late filing  | Attestation = True, within 45-day window  |
| APAC   | Exception Report | Product Ops        | Fallback Policy         | Missing override\_reason          | Justified override present                |
| Global | Incident         | External Submitter | Internal Control Matrix | Missing timestamp/logs            | 72h disclosure, audit trail present       |

***

### ✅ 3. Full Examples

***

#### **Example A: EU + Disclosure + Finance Manager**

```yaml
user_region: EU  
submission_type: Disclosure  
user_role: Finance Manager
```

**Workflow Behavior:**

* Loads **MiCA** thresholds
* Requires: risk statement, governance section, liquidity summary
* Enforces €1M exposure cap
* Triggers escalation if checklist is missing
* Generates approval summary only if all fields complete and exposure ≤ €1M
* LLM tone is professional and internal-facing (for finance operations)

***

#### **Example B: US + Attestation + Legal Counsel**

```yaml
user_region: US  
submission_type: Attestation  
user_role: Legal Counsel
```

**Workflow Behavior:**

* Loads **SOX** rules via Knowledge Retrieval
* Requires: signed attestation block, audit trail
* Auto-approval only if CFO or legal signoff is validated
* Escalation triggered if signoff is blank or filing delayed > 45 days
* Summary tone framed toward legal compliance, references SEC expectations

***

#### **Example C: APAC + Exception Report + Product Ops**

```yaml
user_region: APAC  
submission_type: Exception Report  
user_role: Product Ops
```

**Workflow Behavior:**

* Loads fallback policy or internal guidelines
* Expects `override_reason` or policy justification section
* Escalates if override is empty or missing
* Approves only if justification is declared and matches expected structure
* LLM provides softer tone, explaining internal exception policy

***

#### **Example D: Global + Incident + External Submitter**

```yaml
user_region: Global  
submission_type: Incident  
user_role: External Submitter
```

**Workflow Behavior:**

* Loads internal control matrix (default fallback)
* Requires: incident timestamp, log of actions taken, DPO contact
* Auto-escalates on missing fields
* Summary warns user about trust boundary and flags for review
* Save Point logs all fields for audit trail

***

### 🔍 4. How These Inputs Are Used in Orchestration

Each input is extracted or set using a `Parameter Extractor` block early in the workflow. They're then referenced in:

* `Knowledge Retrieval` → Loads the correct policy based on `user_region`
* `Variable Assigner` → Sets thresholds like `risk_exposure_limit`, `deadline_days`
* `IF/ELSE` → Evaluates whether submission meets policy standards
* `LLM` → Tailors tone and reasoning based on `user_role`
* `Save Point` → Records input values and outcomes for traceability

***

### ⚠️ 5. Input Validation & Defaults

* If a required variable is **missing or malformed**, the workflow defaults to **safe mode**, typically escalating the submission
* Example guard:

  ```yaml
  if risk_exposure_limit == null:
    escalate = true
  ```
* You can enforce stricter checks using custom validation logic before policy evaluation begins

***

### 🛠️ 6. Best Practices for Builders

* Always set default values for `user_region`, `submission_type`, and `user_role` to prevent orphaned sessions
* Use descriptive labels in the chat UI or input form to guide the user clearly
* Avoid hardcoding policy thresholds — always reference memory or retrieval logic
* Tag Save Point logs with input variables for observability and debugging