Custom Policies

Custom Policy Authoring

Policies define what each gate checks. ADCG ships with sensible defaults, but real governance requires policies tailored to your organization's requirements.

Policy Structure

A policy is a versioned document containing rules organized by gate:

{
  "policyId": "pol_custom_v1",
  "version": "1.0.0",
  "name": "Production Release Policy",
  "gates": {
    "3": {
      "combinator": "all",
      "rules": [
        { "metric": "complexity-score", "operator": "lte", "value": 15 },
        { "metric": "lint-errors", "operator": "eq", "value": 0 }
      ]
    },
    "5": {
      "combinator": "all",
      "rules": [
        { "metric": "test-count", "operator": "gte", "value": 1 },
        { "metric": "test-pass-rate", "operator": "eq", "value": 100 }
      ]
    },
    "6": {
      "combinator": "all",
      "rules": [
        { "metric": "line-coverage", "operator": "gte", "value": 80 },
        { "metric": "branch-coverage", "operator": "gte", "value": 70 }
      ]
    }
  }
}

Creating a Policy

curl -X POST https://api.adcg.dev/v1/policies \
  -H "Authorization: Bearer $ADCG_API_KEY" \
  -H "X-Tenant-ID: $ADCG_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d @policy.json

Nested Combinators

For complex logic, nest combinators up to the depth limit (default: 3):

{
  "combinator": "all",
  "rules": [
    { "metric": "vuln-critical", "operator": "eq", "value": 0 },
    {
      "combinator": "any",
      "rules": [
        { "metric": "vuln-high", "operator": "eq", "value": 0 },
        { "metric": "vuln-high-waiver", "operator": "eq", "value": true }
      ]
    }
  ]
}

This reads: "Zero critical vulnerabilities AND (zero high vulnerabilities OR a high-vulnerability waiver is present)."

Testing Policies

Before deploying a policy, test it against historical runs:

curl -X POST https://api.adcg.dev/v1/policies/{policyId}/test \
  -H "Authorization: Bearer $ADCG_API_KEY" \
  -H "X-Tenant-ID: $ADCG_TENANT_ID" \
  -d '{ "runIds": ["run_abc", "run_def", "run_ghi"] }'

The response shows what each run's verdict would have been under the new policy — without affecting actual results.

Approval Chains

Policy changes can require multi-party approval before activation:

1. Author creates or modifies a policy → status becomes pending_approval
2. Reviewers (configured per tenant) receive notification
3. Each reviewer approves or rejects with a reason
4. Once all required approvals are collected → policy becomes active
5. Previous policy version is archived (not deleted)

This prevents a single person from weakening governance rules without oversight.

Versioning

Every policy change creates a new version. Old versions are immutable and archived. Runs reference the exact policy version used, so audit trails always point to the specific rules that were evaluated.