Workflow Phases

When building sophisticated workflows in GLiK, especially for regulatory use cases like MiCA compliance, it’s helpful to design your application in terms of phases. This approach improves clarity, modularity, and reusability—especially for learners and enterprise teams managing complex orchestration.

The following guide walks through the major workflow phases of the Compliance Copilot – MiCA Reporting template. Each phase corresponds to a key milestone in the MiCA reporting process.

What “Workflow” Means

The word “workflow” is used in three different contexts within GLIK:

  1. Workflow (App Type) — A specific GLIK execution model designed for automating logic using a block-based interface. It’s one of the four foundational app types alongside Chatbot, Agent, and Advanced Chat.

  2. Workflow (Architecture) — A broader concept referring to the high-level orchestration of tasks, inputs, tools, and decisions across GLIK apps. This includes how agents interact, how memory is passed, and how execution flows are triggered across systems.

  3. Workflow (Editor View) — The visual interface where you arrange blocks and nodes (like Variable Assigners, Tool Nodes, LLM Blocks, etc.) to construct executable logic paths. This is where low-code users build and configure the logic of any GLIK app, even outside the Workflow App Type.

In short: the Workflow App Type is one way to execute workflows — but “workflow” as a term also describes how logic flows and systems connect across all App Types.

🔎 Phase 1: Trigger & Metadata Preparation

This phase initiates the MiCA reporting workflow and prepares essential input variables.

  • Trigger: Begins manually or via internal partner API

  • Document Parsing (Optional): Extracts key metadata (e.g., issuer, asset type, jurisdiction) using document extractors

  • Normalization: Input variables are cleaned and mapped using tools like Parameter Extractor, Variable Assigner, and Code

📦 Output: A normalized input profile ready for validation.

♻️ Phase 2: Disclosure Section Validator Loop

This is the core loop of the MiCA workflow, validating each disclosure section independently.

  • Generate Section Template: Initializes a reporting frame for the current section

  • Load Compliance Thresholds: Retrieves jurisdictional or internal policy thresholds

  • Validate Thresholds and Fields: Performs rule-based checks for missing data or violations

  • Evaluate Disclosure Quality: Uses an LLM to assess clarity and completeness

  • Summarize (Optional): Produces a natural-language explanation of compliance status

🔁 Output: Each section passes through consistent, auditable validation logic.

📊 Phase 3: Report Aggregation & Assembly

Once all sections are validated, they’re combined into a unified compliance package.

  • Aggregate Sections: Merge per-section results

  • Generate Audit Package: Format the aggregated report into .json, .csv, or .pdf outputs using templates or LLMs

📦 Output: A fully assembled MiCA-compliant report.

✉️ Phase 4: Submission & Attestation

Final tasks for exporting or attesting the completed report.

  • Optional Review: Assign human review or escalation agent for final sign-off

  • Compose Audit Log: Log all decisions using Compose Approval Log

  • Submit/Export: Route to API, archive, or internal system

✅ Output: Finalized submission with structured audit trail, ready for regulators or compliance systems.

PreviousCompliance Copilot – MiCA ReportingNextBlock-by-Block Guide

Last updated

Was this helpful?