blackwall-forecast-action

GitHub Action that gates CI/CD payloads through BLACK_WALL before they apply. Drop it into any workflow that runs Terraform, database migrations, container deploys, or other high-stakes commands — every run is scored, the verdict is recorded as an Ed25519-signed receipt, and STOP-rated steps fail the workflow before damage lands.

Same forecast endpoint that powers the Eliza / OpenClaw / Hermes agent plugins — different threat model, different defaults. Where the agent plugins fail open (an outage must not break the agent), this action fails closed (an outage must not silently let production deploys through).

Free tier: ~100 forecasts/month, no card. Get a key at blackwalltier.com/dashboard/keys.

Quick start

# .github/workflows/terraform.yml
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -out=plan.tfplan
      - run: terraform show -json plan.tfplan > plan.json

      - name: BLACK_WALL forecast
        uses: bluetieroperations-create/blackwall-forecast-action@v0.1.0
        with:
          api-key: ${{ secrets.BLACKWALL_API_KEY }}
          action: terraform_apply
          inputs-file: plan.json
          mode: enforce               # 'observe' for first few runs to calibrate
          caution-action: block       # 'allow' to let CAUTION through with a warning

      - run: terraform apply plan.tfplan

If the forecast returns STOP, the forecast step fails — terraform apply never runs. If it returns CAUTION + caution-action: block, same outcome. GO and CAUTION-with-allow proceed.

Examples

Database migration gate

- name: Read migration file
  id: read
  run: echo "sql=$(cat migrations/0042_drop_users.sql | jq -Rs .)" >> "$GITHUB_OUTPUT"

- name: BLACK_WALL forecast
  uses: bluetieroperations-create/blackwall-forecast-action@v0.1.0
  with:
    api-key: ${{ secrets.BLACKWALL_API_KEY }}
    action: db_migrate
    inputs-json: '{"sql": ${{ steps.read.outputs.sql }}, "target_db": "prod"}'
    context: '{"environment": "production", "owner": "platform-team"}'

Catches things like DROP TABLE users without a backup, accidental cross-environment migrations, or destructive UPDATE without a WHERE clause.

Helm release gate

- name: Render helm values
  run: helm template ./chart --values values.prod.yaml > rendered.yaml

- name: BLACK_WALL forecast
  uses: bluetieroperations-create/blackwall-forecast-action@v0.1.0
  with:
    api-key: ${{ secrets.BLACKWALL_API_KEY }}
    action: helm_upgrade
    inputs-file: rendered.yaml
    context: '{"environment": "prod", "cluster": "us-east-prod-1"}'

Observe-only mode (no blocking, just scoring)

Recommended for the first few runs while you calibrate trust:

- name: BLACK_WALL forecast
  uses: bluetieroperations-create/blackwall-forecast-action@v0.1.0
  with:
    api-key: ${{ secrets.BLACKWALL_API_KEY }}
    action: terraform_apply
    inputs-file: plan.json
    mode: observe   # log + record, never fail the step

The step always passes; verdicts land in your BLACK_WALL dashboard so you can see what would have blocked.

Reading the outputs

- name: BLACK_WALL forecast
  id: bw
  uses: bluetieroperations-create/blackwall-forecast-action@v0.1.0
  with: { ... }

- name: Comment on PR with verdict
  if: github.event_name == 'pull_request'
  uses: peter-evans/create-or-update-comment@v4
  with:
    issue-number: ${{ github.event.pull_request.number }}
    body: |
      🛡️ **BLACK_WALL verdict:** `${{ steps.bw.outputs.recommendation }}` (risk ${{ steps.bw.outputs.risk-score }}/100)

      - reversibility: `${{ steps.bw.outputs.reversibility }}`
      - gate: `${{ steps.bw.outputs.gate }}`
      - receipt: [`${{ steps.bw.outputs.receipt-id }}`](https://blackwalltier.com/api/v1/receipts/verify)

Inputs

Input	Default	Notes
api-key	(required)	Your bw_live_... key. Store as a repo or org secret.
action	(required)	Free-form action classifier — e.g. terraform_apply, db_migrate, helm_upgrade, ecs_deploy. The model uses it to anchor risk patterns.
inputs-file	—	Path to a file containing the structural payload (Terraform JSON plan, migration SQL, helm template output, etc.). Mutually exclusive with inputs-json.
inputs-json	—	Inline JSON payload. Mutually exclusive with inputs-file.
context	{}	Extra context as JSON — {"environment":"prod","owner":"team"}. Merged with GitHub workflow context (repo, ref, sha, actor, workflow, event).
mode	enforce	observe (never fail the step) or enforce (fail on STOP).
caution-action	block	How to treat CAUTION verdicts in enforce mode: block (fail the step) or allow (continue with a warning).
fail-on-error	true	If the forecast API itself errors (network, 5xx), should the step fail? CI/CD threat model — true is the safer default. Flip to false to fail open.
max-input-bytes	32768	Truncate the structural payload over this size. Every byte costs tokens; default 32KB is a calibrated balance.
base-url	https://blackwalltier.com	Override for self-hosted/staging.

Outputs

Output	Example	Notes
recommendation	STOP	GO / CAUTION / STOP
risk-score	87	0–100
reversibility	IRREVERSIBLE	REVERSIBLE / RECOVERABLE / IRREVERSIBLE
gate	HUMAN_REQUIRED	AUTO / CONFIRM / HUMAN_REQUIRED
forecast-id	9edca6c0-...	UUID — pair with /admin/forecasts/<id> for the full record
receipt-id	4ce6ffd2-...	Ed25519-signed receipt. Verifiable offline against the published public key or via POST /api/v1/receipts/verify
red-flags-json	[{"severity":"critical","code":"SQL_NO_WHERE",...}]	Array of red flags
blocked	true	true if the step would have failed in enforce mode (STOP or CAUTION+block)

What it catches

The same 28 named failure modes the rest of the BLACK_WALL ecosystem checks for. Most relevant in CI/CD:

Code	What it means
SQL_NO_WHERE	Destructive SQL with no WHERE clause
IRREVERSIBLE_NO_BACKUP	Action is irreversible and no recovery path was declared
CROSS_ENVIRONMENT	Production target with a staging payload (or vice versa)
AMOUNT_OUT_OF_BAND	Numeric scale anomaly (10x the typical batch size, etc.)
INTENT_MISMATCH	The action diverges materially from the stated workflow purpose
STALE_CONTEXT	The plan/spec hasn't been re-validated against current state
MISSING_AUTH	Credentials in the wrong place, or a permission gap
RATE_ANOMALY	Throughput far outside normal pattern

Full catalog: https://blackwalltier.com/failure-modes

Why fail-closed for CI/CD?

The agent-plugin family (Eliza, OpenClaw, Hermes) fails open: a BLACK_WALL outage must never break a running agent. CI/CD is the opposite — an outage that silently lets production deploys through is exactly the failure mode an enterprise customer is trying to prevent. So fail-on-error: true is the default here.

Override with fail-on-error: false if you want the action to log a warning and continue when BLACK_WALL is unreachable.

Decision receipts

Every verdict comes with a cryptographically signed receipt. Anyone with the request body, the response body, and the published public key can verify offline that BLACK_WALL signed off on that exact decision — no need to trust our servers, our logs, or our database.

For your audit trail, store receipt-id alongside your deploy logs. The hosted verify endpoint is at POST https://blackwalltier.com/api/v1/receipts/verify.

Privacy

The forecast endpoint hashes the payload, the hash lands in the receipt envelope, and the original bytes are released when the response is sent. No raw inputs are written to long-term storage, debug logs, or model-training pipelines. Full details at blackwalltier.com/security.

Architecture

┌──────────────────────────────────────────────┐
│ BLACK_WALL HTTP API (stable, versioned)      │
└──────────────────────────────────────────────┘
              ▲
┌──────────────────────────────────────────────┐
│ blackwall-sdk  (Python client)               │
│   forecast()  observe()                       │
└──────────────────────────────────────────────┘
              ▲
┌──────────────────────────────────────────────┐
│ blackwall-forecast-action (this repo)        │
│   action.yml + run_forecast.py                │
└──────────────────────────────────────────────┘
              ▲
       GitHub Actions runner

When the API changes, the SDK absorbs it. When GitHub changes the Actions runner, only this thin wrapper needs an update. The receipts you've already stored stay verifiable forever against the published public key.

Links

• Site & docs: https://blackwalltier.com
• Free API key: https://blackwalltier.com/dashboard/keys
• Failure-mode taxonomy: https://blackwalltier.com/failure-modes
• Receipt verification: https://blackwalltier.com/api/v1/receipts/verify
• Security & privacy: https://blackwalltier.com/security
• DPA template: https://blackwalltier.com/legal/dpa
• Sibling integrations: blackwall-sdk · blackwall-mcp · blackwall-eliza-guardrail · blackwall-openclaw-plugin · blackwall-hermes-plugin

License

MIT