Skip to content

user workflow files

MD MUFTHAKHERUL ISLAM MIRAZ edited this page Jun 24, 2026 · 2 revisions

🔀 Workflow Files

At the heart of Siyarix is the WorkflowEngine, a powerful system that uses Directed Acyclic Graphs (DAGs) to execute complex, multi-step processes. Workflows allow you to define dependencies between tasks, ensuring that steps run in the correct order—and in parallel when they don't depend on each other!

Note

Workflow files are executed programmatically via the WorkflowEngine API or through the primary CLI command: siyarix playbook run. (There is no dedicated siyarix workflow run command).


📝 The Workflow Format

Workflows are written in clean, easy-to-read YAML. Here is an example of a standard network assessment:

name: network-assessment
description: Standard network security assessment
steps:
  - id: recon
    instruction: "scan subdomains of {{target}}"
    mode: integrated
    depends_on: [] # Runs immediately

  - id: port-scan
    instruction: "nmap -sV -p 1-1000 {{target}}"
    mode: registry
    depends_on: [recon] # Waits for recon

  - id: vuln-scan
    instruction: "run vulnerability scan on {{target}}"
    mode: integrated
    depends_on: [port-scan] # Waits for port-scan

  - id: report
    instruction: "generate report from findings"
    mode: integrated
    depends_on: [vuln-scan] # Waits for vuln-scan
    retries: 2             # Try up to 3 times total!
    timeout: 600           # Kill if it takes over 10 minutes

⚙️ Step Specification

Every step in a workflow is highly configurable. Here is what you can define:

Field Required? Default What It Does
id Yes A unique identifier for the step (e.g., recon).
instruction Yes The command or natural language instruction to execute.
mode No integrated The AI execution mode (registry, autonomous, or integrated).
depends_on No [] A list of step IDs that must finish before this step can start.
retries No 0 How many times to automatically retry if the step fails.
timeout No 300 The maximum time (in seconds) the step is allowed to run.
persist No true Should the results be saved to the offline database?

🚀 Execution

Executing a workflow from the command line is simple:

# 🏃 Run a workflow file directly
siyarix playbook run network-assessment.yaml

# 🎯 Inject custom variables at runtime
siyarix playbook run assessment.yml --var target=example.com

💻 Programmatic API

You can also build and run workflows dynamically in Python!

from siyarix.workflow import WorkflowEngine

engine = WorkflowEngine()

# Build the graph dynamically
workflow = engine.create_workflow(
    name="my-workflow",
    nodes=[
        {"id": "scan", "name": "Port Scan", "step_fn": "nmap", "args": {"target": "10.0.0.1"}},
    ],
    edges=[],
)

# Execute it!
await engine.run_workflow(workflow)

🚦 How It Works Under the Hood

Step States

Every step transitions through a strict lifecycle:

PENDING → RUNNING → COMPLETED
               ↓
            FAILED
               ↓
           SKIPPED

Dependency Resolution

Siyarix executes steps in topological order.

  • Steps with empty depends_on arrays run first.
  • Independent steps run simultaneously!
  • The engine uses an asyncio.Semaphore(4) to prevent overwhelming your system, bounding execution to 4 concurrent tasks by default.

Retries & Persistence

  • Retries: If a network glitch causes a step to fail, Siyarix automatically tries again based on your retries configuration (up to a default max of 3 attempts).
  • Persistence: Every output, finding, error, and timestamp is safely stored in the OfflineStore for later review.

Strict Validation

Before Siyarix runs a single command, it validates your entire workflow. It ensures all IDs are unique, dependencies actually exist, and prevents catastrophic circular dependencies!

Note

👋 Welcome to Siyarix! This is a personal passion project built by a single developer. It's currently under active development and growing fast. Expect rough edges, but lots of love! ❤️

🗺️ Siyarix Documentation Map

Welcome to the Siyarix Documentation Map! This page serves as your master compass for navigating the extensive documentation we have built for the platform.

Whether you are a brand new user, a seasoned security operator, or a developer looking to contribute to the core engine, you can find exactly what you need here.


🧭 Quick Navigation

Not sure where to start? Pick the path that best describes you:

🌱 For New Users

Just getting started? We highly recommend following these guides in order:

  1. Installation Guide — Get Siyarix running on your machine.
  2. Onboarding Wizard — Let our interactive wizard help you set up your API keys and environment.
  3. Setup & Configuration — A deeper dive into customizing your setup.
  4. Your First Run — A gentle walkthrough of your very first Siyarix command.

🛡️ For Security Operators

Ready to put Siyarix to work? Dive into our operational guides:

💻 For Developers & Contributors

Looking under the hood or wanting to write some code? Start here:


📂 The Complete Documentation Tree

If you prefer to browse the raw structure, here is a complete layout of the docs/ folder:

docs/
├── 🚀 getting-started/       # Installation, onboarding, and configuration
│   ├── installation.md       # Multi-platform install (pip, brew, winget, docker)
│   ├── onboarding.md         # The interactive 11-step setup wizard
│   ├── setup.md              # Managing API keys, credentials, and settings
│   ├── first-run.md          # A walkthrough of your first session
│   ├── configuration.md      # A deep-dive into advanced settings
│   └── troubleshooting.md    # Common issues and how to fix them instantly
│
├── 📖 user/                  # Daily operations and workflows
│   ├── cli-commands.md       # Reference for 50+ CLI commands across 12 groups
│   ├── interactive-chat.md   # Mastering the AI REPL and 54+ slash commands
│   ├── security-workflows.md # Recon, vulnerability assessment, incident response
│   ├── cloud-scanning.md     # Multi-cloud security scanning (under development)
│   ├── compliance.md         # Framework mapping (SOC 2, NIST, GDPR, PCI-DSS)
│   ├── threat-intelligence.md# Integrations with OTX, NVD, and MITRE ATT&CK
│   ├── playbooks.md          # Building automated YAML-based IR playbooks
│   ├── workflow-files.md     # DAG workflow reference (programmatic API)
│   ├── reporting.md          # Multi-format report generation
│   ├── offline-registry.md   # Running without AI (Offline/Registry execution mode)
│   └── ai-workflows.md       # Advanced AI-driven autonomous operations
│
├── 💻 developer/             # Building, testing, and extending Siyarix
│   ├── codebase-overview.md  # Full module structure mapping
│   ├── contribution-guide.md # How to submit PRs and our coding standards
│   ├── module-architecture.md# Component design and responsibilities
│   ├── testing.md            # Writing tests (pytest), coverage, and CI/CD
│   └── building.md           # Packaging, distribution, and Docker builds
│
├── 🏗️ architecture/          # System design and core internals
│   ├── overview.md           # High-level data flow and layered orchestration
│   ├── ai-agent-pipeline.md  # The AgentCore reasoning and execution pipeline
│   ├── provider-abstraction.md# How we unify 26 different AI providers
│   ├── execution-engine.md   # Plan-based step orchestration
│   ├── memory-and-state.md   # Knowledge graph, session persistence, and learning
│   ├── security-model.md     # The Permission Gate, DLP, audit logging, and OPSEC
│   └── intent-routing.md     # Semantic intent classification and routing
│
├── 🧠 ai/                    # Deep dive into the AI provider & agent systems
│   ├── routing.md            # Managing 26 providers, failovers, and circuit breakers
│   ├── persona-system.md     # Overview of our 10 security personas
│   ├── agent-reasoning.md    # The Observe-Reason-Act loop and tool call repair
│   ├── tool-execution.md     # The tool registry, capability graph, and parsers
│   ├── ensemble.md           # Parallel LLM voting strategies
│   ├── multi-wave.md         # Iterative goal execution with context carry-over
│   ├── prompt-architecture.md# System prompt design and management
│   └── safety.md             # Our rigorous 8-layer hallucination mitigation system
│
├── 🛡️ security/              # Safety, ethics, and threat models
│   ├── reporting.md          # How to safely report vulnerabilities to us
│   ├── threat-model.md       # System threat model and our mitigations
│   ├── operational-security.md# TOR routing, stealth modes, and OPSEC controls
│   ├── ethical-policy.md     # Mandatory rules of engagement for all users
│   └── abuse-prevention.md   # How we prevent misuse of the AI engine
│
└── ⚖️ legal/                 # Licensing and governance
    ├── agpl-guide.md         # A plain-English overview of the AGPL-3.0-or-later license
    ├── why-agpl.md           # The philosophy behind our license choice
    ├── trademark-policy.md   # Branding and trademark guidelines
    ├── responsible-ai.md     # Our framework for ethical AI usage
    ├── disclaimer.md         # Important legal disclaimers
    └── plugin-exception.md   # The license exception for building custom plugins

📖 Key Terminology

As you read through the documentation, you might encounter some specific terms. Here is a quick cheat sheet:

Term What It Means
Provider The backend AI engine powering Siyarix (e.g., OpenAI, Anthropic, Ollama).
Tool A traditional security executable installed on your system (e.g., nmap, nuclei).
Plan A step-by-step sequence of tool commands intelligently generated by the AI.
Workflow A hardcoded, predefined execution path (usually defined in YAML/JSON) that doesn't require AI generation.
Persona A specialized behavioral profile given to the AI (e.g., instructing it to act specifically as a "Network Recon Specialist").
Knowledge Graph Siyarix's internal memory where it stores findings (like IP addresses, open ports) to contextually inform future steps.

Need help finding something specific? Feel free to use the search bar at the top of the documentation site, or open a discussion on our GitHub!

Clone this wiki locally