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:
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.
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.
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
, andCode
📦 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.
Last updated
Was this helpful?