How it works

One call to set up. Then every PR follows the same path.

Onboarding takes one call and about a day. After that, a PR runs left to right into the Officer's decision; a rejected PR loops back to the author, and the Officer re-reviews only the new diff.

Onboarding · one call, about a day

01

Install.

Install the PSCO GitHub App on the organization and select the in-scope repos. It is the same step that produced the quote.

02

Kickoff.

One 60-minute call. PSCO drafts the Security & Compliance Model from the repo scan and your architecture; you approve version 1.

03

Protect.

Add branch protection: one required approval from the @psco-officers team (via CODEOWNERS) and the psco/approved status check. PSCO verifies the setting.

04

Review.

Primary and backup Officers are assigned and introduced. The first PR is reviewed the same day.

The review flow

Every PR gets a human decision; only approved PRs merge.

Eight steps, one decision, one loop. The author pushes new commits, the approval is dismissed, and only the new diff is re-reviewed.

Flow diagram: PR opened or updated, your AI reviewers comment, PSCO triage sets risk tier and packet, Officer reviews against the model, meets the model? Yes: Approved Review plus psco/approved, customer or automation merges, attestation and Evidence Pack. No: changes requested, author fixes, loops back with only the new diff re-reviewed. High-risk tier goes to Deep Review by a senior Officer.

Triage

Within seconds of the PR event, PSCO builds a review packet: files touched mapped to the model's risk tiers, required-check status, findings already posted by your AI reviewers, forbidden-pattern hits, diff size, and a plain-language summary. The packet sets the tier.

The Officer's work

Confirm the packet against the diff, check the model's required gates, read the sensitive hunks, decide. Officers never rewrite code; findings go back as Request Changes citing the model clause they violate.

Queue and SLA

Officers work a shared queue ordered by SLA deadline and tier. Your primary Officer gets first claim; the backup takes over after 30 minutes idle. The PR shows the Officer's name within minutes of opening.

Risk tiers · set by the packet, recorded in the attestation
AttestBot dependency bumps, docs and tests-only changesAbout a minute
StandardRoutine code outside sensitive pathsTwo to four minutes
DeepSensitive paths, migrations, new trust boundaries, PRs over 1,000 changed linesFifteen to thirty minutes, senior Officer

The Security & Compliance Model

One rulebook for the robot and the human.

A versioned document, kept as psco.model.yaml plus a short prose companion, that encodes what the Officer checks on every PR. You own it; changes require your sign-off and are recorded as a new version. Feed the same file to your AI reviewers and both layers check the same rules.

  • 01System description, data classification, trust boundaries, and which frameworks are in scope
  • 02Sensitive paths mapped to risk tiers (auth, crypto, payments, PII handlers, infrastructure, CI, migrations, CODEOWNERS, the model itself)
  • 03Required checks that must be green before approval (CI, tests, SAST, secrets scan, dependency audit)
  • 04Forbidden patterns (hard-coded secrets, disabled TLS verification, raw SQL, eval, debug flags, logging of sensitive fields)
  • 05Dependency and license policy, and how bot-authored dependency PRs are handled
  • 06Change types that always get a Deep Review, and the exception process
  • 07Merge policy after approval: who may merge, and whether auto-merge is permitted
psco.model.yamlv3 · customer-owned · approved by owner@acme
# psco.model.yaml · v3 · acme/platform
meta:
  version: 3
  frameworks: [soc2, iso27001]
scope:
  repos: [acme/platform, acme/infra]
  attest_paths: ["**/__tests__/**", "**/*.test.ts"]
  bot_authors_attest: true
sensitive_paths:
  "auth/**": deep
  "infra/**": deep
  "payments/**": deep
  "**/migrations/**": deep
  ".github/workflows/**": deep
forbidden:
  - id: hardcoded_secret
  - id: tls_verify_off
  - id: raw_sql_interpolation
required_checks: [ci/build, tests, sast/semgrep, secrets-scan]
always_deep: [new_trust_boundary, schema_migration, changed_lines_over: 1000]
merge_policy:
  who_may_merge: [team:platform-leads]
  auto_merge_allowed: true
  psco_merges: never

The attestation

What gets signed.

A GitHub review in state Approve from the Officer's named account, psco/approved set to success for that commit SHA, and an attestation comment. New commits dismiss both and trigger an incremental re-review. Every decision also writes a signed attestation record; the dashboard, the monthly Evidence Pack and the GRC pushes all derive from it.

infra/deploy/rotate_keys.py · #482 · commit 2 · a3f9c1eonly the new diff re-reviewed
4141def rotate_key(kms, key_id):42- resp = requests.post(KMS_URL, json={"key": key_id}, verify=False)42+ resp = requests.post(KMS_URL, json={"key": key_id}, verify=CA_BUNDLE)4343 audit.log("rotate", key_id=key_id)

jane-okafor-psco approved these changes

psco/approved

Pinned CA bundle in place. Required checks green. Read infra/deploy in full. Meets Security & Compliance Model v3. attestation · officer PSCO-0147 · tier deep · 2026-11-09 14:30 ET · signed

  • Pull requestRepository, number, title, author, URL
  • CommitHead SHA decided, base SHA, previous decided SHA on re-review
  • OfficerPublic ID, display name, GitHub login; backup Officer ID
  • DecisionApproved or changes requested, tier, service level
  • ModelVersion and content hash in force at decision
  • ChecksRequired-checks snapshot and the AI reviewers detected
  • TimestampsOpened, triaged, claimed, decided, SLA deadline and whether it was met
  • IntegrityPacket hash, canonical record, SHA-256 digest, Ed25519 signature and key id

The three steps, again

Connect.

Install the PSCO GitHub App, pick the repos in scope, and see your price from your actual PR volume.

Install PSCO · permissions requested
Repository metadataRead
Pull requestsRead
Contents · ChecksNot until you start

Model.

On one kickoff call we build your Security & Compliance Model: what matters in your codebase, which paths are sensitive, which checks must be green.

psco.model.yamlv1 · customer-owned
frameworks: [soc2, iso27001]
sensitive_paths:
  auth/**: deep
  infra/**: deep
required_checks: [ci, tests, sast, secrets]
forbidden: [hardcoded_secret, tls_verify_off]

Approve.

A named Officer reviews every PR against your model, in near real time, and signs it on GitHub. Merge it yourself or let your automation merge it.

psco/approved — Officer PSCO-0147 · model v3
New commit → approval dismissed → only the new diff re-reviewed
Auto-merge keyed to the check. PSCO never merges.

The Evidence Pack

Evidence your auditor can sample without you assembling anything.

Every attestation record in the dashboard. A monthly Evidence Pack (CSV and PDF) laid out for change-management sampling. Read-only auditor access. Pushes to Vanta, Drata and Secureframe tests. An annual Officer Dossier covering background checks, US residency, qualifications and training.

Dashboard

Queue and history of every PR with Officer, tier, decision and timings; SLA attainment; usage against the quoted volume.

Evidence Pack

Monthly CSV and PDF: one row per decided PR, in the order and format auditors sample from.

Auditor access

Read-only invite scoped to attestations, approved model versions and Evidence Packs. Nothing else.

Officer Dossier

Annual letter per Officer: qualifications, background check dates, US residency, training.

See your exact price before you talk to anyone.

Connect GitHub, pick the repos in scope, and get a quote from your real PR history in two minutes.