Deterministic merge checks

The Veriom architecture-check command turns the workspace change policy into a native GitHub, GitLab, or Bitbucket job result. It audits the full pull-request or merge-request commit, waits for the durable scanner and architecture workflow, then retrieves the persisted architecture comparison for that repository. The installer vendors a reviewed copy into your repository, so a registry outage or unpublished package cannot change the gate that protects a merge.

./actions/install-architecture-check.sh github /path/to/repository
./actions/install-architecture-check.sh gitlab /path/to/repository
./actions/install-architecture-check.sh bitbucket /path/to/repository

The action fails closed if the returned gate belongs to another concurrent audit. It never asks an agent whether a pull request should merge.

GitHub

Create a workspace API token with audits:read and audits:write, save it as VERIOM_API_TOKEN, and add the workspace and repository UUIDs as GitHub variables.

name: Veriom architecture gate

on:
  pull_request:

permissions:
  contents: read

jobs:
  architecture:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the pull-request commit
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Evaluate the Veriom architecture gate
        uses: ./.github/actions/veriom-architecture-check
        with:
          api-token: ${{ secrets.VERIOM_API_TOKEN }}
          workspace-id: ${{ vars.VERIOM_WORKSPACE_ID }}
          repository-id: ${{ vars.VERIOM_REPOSITORY_ID }}
          commit-sha: ${{ github.event.pull_request.head.sha }}

Gate outcomes

The job summary includes source coverage, the policy reasons, change consequences, owner hints, affected graph paths, and an explainable impact score. The score is decomposed into repository criticality, reachability, data sensitivity, trust-boundary exposure, and uncertainty; every component retains graph and evidence references. Configure the required check in the repository's branch protection after its first run.

GitLab

Connect the GitLab account, explicitly add the project to audit scope, and save a token with audits:read and audits:write as a masked, protected VERIOM_API_TOKEN CI/CD variable. Add the workspace and Veriom repository UUIDs as VERIOM_WORKSPACE_ID and VERIOM_REPOSITORY_ID.

veriom:architecture:
  image: node:22-alpine
  stage: test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  variables:
    VERIOM_COMMIT_SHA: $CI_COMMIT_SHA
  script:
    - node .veriom/architecture-check.cjs
  allow_failure: false

GitLab turns the job exit code into merge-request pipeline status. The Veriom token can start and read audits; it cannot push commits, approve a merge request, or change branch rules.

Bitbucket

Connect the Bitbucket workspace, explicitly select the repository, and add the three VERIOM_* values as secured repository variables.

image: node:22-alpine

pipelines:
  pull-requests:
    "**":
      - step:
          name: Veriom architecture gate
          script:
            - export VERIOM_COMMIT_SHA="$BITBUCKET_COMMIT"
            - node .veriom/architecture-check.cjs

Bitbucket publishes the step result to the pull request. As with GitHub and GitLab, the command compares the persisted audit ID before enforcing the gate, so a concurrent run cannot silently substitute another result.

CLI inputs

The provider-neutral command accepts VERIOM_API_TOKEN, VERIOM_WORKSPACE_ID, VERIOM_REPOSITORY_ID, and the CI provider's full commit SHA. Optional variables are VERIOM_API_URL, VERIOM_DEEP_REVIEW, VERIOM_TIMEOUT_SECONDS, VERIOM_POLL_INTERVAL_SECONDS, and VERIOM_FAIL_ON.