MergeWhyInstall GitHub App →
Back to Docs

Concepts

What MergeWhy is, what a Decision Evidence Record is, and how the tamper-evidence chain, evidence vault, and frameworks fit together.

What MergeWhy is

MergeWhy is a compliance evidence platform. It watches every pull request you merge, captures the full change context (review, approval, ticket, CI, deploy), seals it with a cryptographic signature, and anchors the chain head to the public Sigstore Rekor transparency log. Auditors verify the evidence on a public log instead of trusting your database or ours.

Engineers do not change their workflow. There is no extra CI step, no required label, no commit-message format. MergeWhy reads what already exists in GitHub, GitLab, Bitbucket, or Azure DevOps and turns it into auditor-ready evidence at merge time.

The Decision Evidence Record (DER)

The atomic unit of MergeWhy is the Decision Evidence Record— one DER per pull request. A DER captures every signal an auditor cares about for a single change:

  • PR intent— title, description, ticket links (Jira, Linear, GitHub Issues), commit messages
  • Review and SoD— reviewers, approval count, author-also-approved detection (segregation of duties violations)
  • CI evidence— check runs, test pass/fail counts, coverage delta, security scan severity counts
  • Deployment attestation— which commit reached which environment, when, and by whom
  • Compliance evaluation— per-control PASS / FAIL / WARNING for every enabled framework, with the specific reason for each
  • Cryptographic seal— SHA-256 hash of the entire evidence bundle plus an Ed25519 signature, sealed at merge time

Every DER is browseable at /dashboard/records. The detail view shows the evidence checklist, gap list, AI documentation analysis, files changed, and a per-tab view of Compliance, Vault & Attestations, and Timeline.

The evidence vault

At merge time, MergeWhy compiles the entire evidence package and seals it. The vault stores a SHA-256 fingerprint plus an Ed25519 signature. Any byte changed after seal time breaks the signature; even MergeWhy itself cannot silently rewrite a sealed record.

Sealed vaults are browseable at /dashboard/vault. Each card shows the seal hash, the time of seal, review and approval counts, the linked ticket, and an evidence score. Auditors can verify any vault by recomputing the hash from the captured contents.

Tamper-evidence chain and Sigstore Rekor

Beyond per-record sealing, MergeWhy maintains a chained audit log. Every audit-log row is fingerprinted with SHA-256 and linked to the row before it, like git. Verification recomputes each fingerprint and detects rows that were altered, deleted, reordered, or never written. The verification panel lives at /dashboard/audit-log.

For independently-verifiable proof, the chain head is anchored to the public Sigstore Rekor transparency log on demand. Once anchored, the Rekor entry is permanent and auditor-checkable without any access to MergeWhy. This is the single biggest difference between MergeWhy and cloud-posture compliance tools: the proof is on a public log, not in a vendor database.

Tip

See a real anchored entry from production: Rekor entry #1398873504. Independent of MergeWhy. You can verify it with the Rekor CLI today.

Continuous Control Monitoring

Continuous Control Monitoring (CCM) is Gartner’s name for the practice of evaluating compliance controls on every relevant event rather than on a periodic schedule. Most tools labelled “CCM” actually poll your cloud configuration on a 24-hour cron and re-check SOC 2 controls daily. That is periodic monitoring with a continuous label.

MergeWhy is per-event by construction. Every merged pull request triggers a fresh evaluation of every enabled framework against that change’s evidence (review, approval, ticket, CI, deploy). A SOC 2 control like CC8.1 (Change Authorization) is checked not once a day but once per change — which is what the control text actually requires.

We surface this as a control uptime %— the share of evaluations in a window where the control passed. Auditors recognise the shape (it is the same arithmetic as service uptime) and SOX testers can sample the failures directly. View per-control uptime on any framework page under /dashboard/readiness and the per-framework drill-downs.

Evidence score (0-100)

Each DER receives a numeric evidence score derived from auditor-aligned weights (AICPA TSC CC8.1, PCAOB AS 1105, AS 2201). The factors:

  • 25 pts — Authorization & approval (auditor priority #1)
  • 25 pts — CI/CD evidence (system-generated, high reliability)
  • 15 pts — Ticket linkage (audit-trail traceability)
  • 10 pts — Separation of duties (binary pass/fail control)
  • 10 pts — Description quality (management representation)
  • 10 pts — Evidence completeness (corroborating sources)
  • 5 pts — AI documentation assessment (bonus)

Scores below your configured threshold trigger a failing GitHub Check on the PR — engineers see the gap before merge.

Gaps

When a DER is missing required evidence, MergeWhy raises a typed gap with severity. Common gap types:

  • MISSING_DESCRIPTION — PR has no body
  • MISSING_TICKET — no Jira/Linear/GitHub issue linked
  • MISSING_REVIEW — no code review
  • MISSING_APPROVAL — no approving review
  • SELF_APPROVED_MERGE — author also approved (CRITICAL, SoD violation)
  • FAILED_CI_CHECKS — merged with failing CI (compliance violation)
  • NO_TESTING_EVIDENCE — no CI test results captured
  • MISSING_SECURITY_SCAN — no security scan ran

Compliance frameworks

MergeWhy evaluates each DER against every enabled framework. Per-control results carry the auditor-facing reason, the citation, and the rationale. Currently supported (Growth and Enterprise plans include all of them):

  • SOC 2 Type II (Trust Services Criteria)
  • SOX ITGC (PCAOB AS 2201, COBIT mapping)
  • SOX 404
  • FedRAMP Low / Moderate / High (built on NIST 800-53)
  • CMMC L1 / L2 / L3 (with SPRS scoring)
  • NIST 800-53
  • HIPAA Security Rule
  • ISO 27001:2022
  • ISO 27701 (Privacy Information Management — GDPR alignment)
  • PCI-DSS
  • DORA
  • GDPR Article 32

Enable the frameworks you need at Settings → Compliance. Each control can be customized: minimum reviewer count, minimum description length, whether self-approval is allowed, how many approvers are required for sensitive files, etc.

Frameworks evaluate two layers

For frameworks like SOC 2 and HIPAA, MergeWhy evaluates two layers of evidence:

  • DER evidence— per-change controls (CC8.1 change management, segregation of duties, code review). Always available.
  • Organizational evidence— org-wide controls (CC6.1 MFA enforcement, CC6.7/CC6.8 encryption, CC7.2 audit logging). Sourced from connected cloud integrations (AWS, GCP, Azure, Linear, Jira, Slack, Google Workspace).

Connect cloud integrations at Settings → Integrationsto unlock the org-evidence layer. Without them, frameworks evaluate the DER layer only.

Audit bundle and OSCAL export

When the auditor shows up, generate a complete evidence package with one click at /dashboard/audit-bundle. Presets cover SOC 2 Type II, SOX ITGC, CMMC Level 2, and FedRAMP. The bundle is a ZIP containing per-control evidence mapping, an executive summary, sealed vault hashes for verification, and a CSV control matrix.

For FedRAMP and federal customers, MergeWhy also generates OSCAL 1.1.2 machine-readable packages (System Security Plan, Assessment Results, POA&M) at /dashboard/oscal. FedRAMP 20x requires OSCAL submissions starting September 2026.

SOX audit sampling

For SOX ITGC, auditors sample 25-60 changes per audit period using stratified random sampling per PCAOB AS 2315. MergeWhy implements the methodology directly at /dashboard/sox-sampling: pick a period, pick a sample size, and the engine produces a reproducible stratified sample with full evidence attached to each sampled change. Same seed reproduces the same sample.

Compensating controls and waivers

When a control fails for a documented business reason, an Owner can either apply a compensating control (a substitute control the auditor accepts in place of the failing one) or grant a waiver with justification and expiry date. Both operations are written to the immutable audit log and surfaced in the evidence package the auditor receives.

Where to go from here

Build vs Buy