Skip to main content
Pandorian integrates into your existing SDLC to enforce guidelines continuously and automatically. This guide covers PR scanning, CI/CD integration, repository policy, and notifications.

Source Control & Pull Request Scanning

The fastest way to enforce guidelines is through automatic PR scanning via your source control integration. Pandorian supports GitHub, GitLab, and Azure DevOps.

How PR Scanning Works

Once you connect your source control manager during initial setup, PR scanning is automatically triggered on every new PR or push to an existing PR. What happens during a PR scan:
  1. Developer opens or updates a pull request.
  2. Pandorian scans only the modified files against guidelines.
  3. Violations appear as inline comments on specific lines and as a summary comment on the PR (if opted in)
  4. The PR check appears in your source control’s status checks (configurable as required or optional)

PR Actions

Rescan: Re-trigger a scan for an existing PR with the current set of active guidelines applied to it. Useful after updating guidelines or resolving earlier violations. Archive: Archive individual findings that are no longer relevant — archived violations are excluded from future Jira ticket creation and reporting views. Skip CI Check: Manually skip the CI check for a specific PR. The scan will still run, but results will not block the PR build associated with it.

Blocking vs. Monitoring Mode

Blocking Mode (recommended for production): Pipeline fails if violations are found, preventing non-compliant code from being deployed. Set exit code 1 when violations > 0. Monitoring Mode (useful for gradual rollout): Pipeline continues regardless of violations. Scan results are logged for visibility. Set exit code 0 and log violations without blocking.

Guidelines as Code

High-velocity teams can manage guidelines directly within their code repositories, treating engineering standards as living documentation that evolves alongside the codebase. If your team already uses internal markdown files or AI coding assistant skills, you can sync those same files to Pandorian — ensuring the rules your AI uses to write code are the exact same rules Pandorian uses to validate it.

How It Works

  1. Designate a repository and base directory (e.g., /docs/guidelines) in the Integrations tab
  2. Pandorian monitors that directory for .md files
  3. Any merge to the main branch triggers an update — guidelines are immediately enforced across all associated repositories

File Structure & Metadata

Each Markdown file must contain a YAML frontmatter block with a pandorian-metadata section:
AttributeTypeDescription
idstringUnique identifier (e.g., scala-expert)
language_idsstringTarget languages (e.g., scala, python)
titlestringClear, actionable rule name
blockbooleantrue to block on violation; false defaults to monitor
categorystringArea of focus (e.g., security, performance)
is_activebooleanWhether this guideline is currently enforced
tagslistStrings for filtering and organization

Supported Categories

Architecture, Code Quality & Maintainability, Reliability & Resilience, Performance & Scalability, Security, Data & Storage, Infrastructure & Environments, Observability

Supported Languages

c, cobol, cpp, csharp, dockerfile, elixir, go, haskell, java, javascript, kotlin, lua, perl, php, python, ruby, rust, scala, swift, terraform, typescript

Implementation Example

Create a file named scala-expert.md in your guidelines directory:
---
pandorian-metadata:
  id: scala-expert
  language_ids: [scala]
  title: Scala Functional Programming Expert
  block: true
  category: Architecture
  is_active: true
  tags: [scala, functional-programming, cats, fs2]
---

# Scala Functional Programming Standards

You are an elite Scala developer. When writing or reviewing code, ensure:
- **Immutability First**: Always use `val` over `var` and prefer immutable collections.
- **Referential Transparency**: Effects must be properly tracked in the type system using `IO`.
- **Resource Management**: Use `Resource` for anything requiring cleanup.

### Prohibited Patterns
- Never use `null`. Use `Option` instead.
- Avoid `Thread.sleep`; use `IO.sleep` for non-blocking delays.

Configuration Steps

  1. Navigate to Integrations → Connections → Source Control in the Pandorian platform
  2. Select the repository containing your .md files
  3. Provide the top-level directory path (e.g., /docs/guidelines)
  4. Save to trigger an initial import

Policy as Code

Policy as Code lets you configure repository-level settings as code, so Pandorian knows which guidelines to run and when to block pull requests — without managing these rules outside your codebase. The policy is defined in a .Pandorian/.policy file inside the repo and is applied on every full and PR scan.

Repository Policy Schema

# Guidelines to apply — only guidelines tagged with the specified tag will run
repository_guidelines_tags:
  - guideline_tag: string

# Exclusions — skip files or directories from analysis using glob patterns
# Useful for vendor code, generated files, or any paths that shouldn't be scanned
exclusions:
  - type: glob
    value: string
    case_sensitive: bool

# Inclusions — apply a specific guideline only to a specific path inside the repository
# Uses glob patterns to scope guideline enforcement to relevant directories or file types
inclusions:
  - guideline_tag: string
    path_pattern:
      - type: glob
        value: string
        case_sensitive: bool

Comprehensive Configuration Example

# Guidelines Configuration
repository_guidelines_tags:
  - guideline_tag: v2

# Exclusion Rules
exclusions:
  # Exclude vendor directories
  - type: glob
    value: "vendor/**"
    case_sensitive: true

  # Exclude generated protobuf files
  - type: glob
    value: "**/*.pb.go"
    case_sensitive: true

  # Exclude test files
  - type: glob
    value: "**/*_test.go"
    case_sensitive: true

  # Exclude node_modules
  - type: glob
    value: "node_modules/**"
    case_sensitive: true

# Inclusion Rules
inclusions:
  # Apply security guidelines only to the auth service path
  - guideline_tag: security
    path_pattern:
      - type: glob
        value: "src/auth/**"
        case_sensitive: true

  # Apply data guidelines only to migration files
  - guideline_tag: data-storage
    path_pattern:
      - type: glob
        value: "db/migrations/**"
        case_sensitive: true

Scan Policies

Scan Policies let you define exactly where and how guidelines run — which paths to ignore, and which guideline groups to scope to specific files or directories. Repo-level overrides take precedence over org-level defaults. Navigate to Scan Policies in the Pandorian dashboard to configure.

Organization Policy

Organization-level policy applies across all repositories by default. Ignored Paths: Paths that should never be scanned, applied to all guidelines. Use this to exclude vendor code, generated files, test fixtures, or any directory that shouldn’t be subject to enforcement. Click Ignore a path to add an exclusion. Guideline Scoping: Restrict a guideline group to specific paths only. Rather than running all guidelines across the entire codebase, scoping rules let you target enforcement by tag — for example, applying security guidelines only to the auth service, or data guidelines only to migration files. Click Add scoping rule to configure.

Repository Overrides

Repository overrides let you customize scan policy for a specific repository, overriding the organization defaults. This is useful when a particular repo has different conventions, third-party code that should be excluded, or guidelines that only apply in that context. Click Add repository override to configure.

Dynamic Context Providers

Dynamic Context Providers connect external data sources directly to your guidelines, ensuring they evaluate code against real-time context — approved libraries, internal API routes, active feature flags — rather than static hardcoded lists.

Configuring a Provider

When creating or editing a guideline, add a provider with:
  • Title: Descriptive name (e.g., “Approved Config Flags”)
  • Command: The exact command Pandorian executes to fetch data (e.g., a curl to your internal API)
  • Grep: Optional regex to filter the command output to only the relevant data
  • Timeout: Maximum seconds to wait for the external source before timing out

Slack Integration

Setting Up Slack Notifications

  1. Navigate to Settings → Integrations
  2. Click Connect Slack
  3. Authorize Pandorian to access your Slack workspace
  4. Choose the notification channel
  5. Configure alerts for scan completed or scan failed events
Each alert includes a direct link to the scan results in the Pandorian dashboard.

Jira Integration

Connect Pandorian to Jira to create issues directly from scan results, turning violations into actionable tickets without leaving the dashboard.

Setting Up Jira

  1. Navigate to Integrations → Jira in the Pandorian dashboard
  2. Click Connect and sign in via Atlassian
  3. Once authorized, the integration status shows Configured
  4. Under Configuration, select your default Jira board and click Save

Creating a Jira Issue from a Guideline

From the Guidelines page, click the Violations badge on any guideline. Click Create Issue — Pandorian generates a ticket draft containing all current open violations for that guideline in bulk. The Create Jira Issue form is pre-populated with:
FieldDetails
SummaryPre-filled; editable
DescriptionAuto-generated from guideline details, violation count, category, and repo context; editable
Issue TypeDefaults to Task; editable
PriorityOptional; editable
AssigneeOptional; editable
LabelsOptional; comma-separated
A Ticket Preview panel shows the rendered output before submission.
Tip: Archive irrelevant violations before creating a ticket — archived violations are excluded from the generated issue.

Ticket History & Lifecycle

A Tickets page in Pandorian shows all issues opened, so you can track escalations without leaving the dashboard. Pandorian does not automatically close, update, or comment on tickets — lifecycle is managed within Jira.