ChangeProof

A pull request approval badge is not historical proof that the revision which merged was reviewed.

ChangeProof answers an auditor’s Jira change list with source-linked evidence of approval, review, merged revision and deployment. It is a focused Forge app for teams using Jira/Jira Service Management, Bitbucket Cloud and Bitbucket Pipelines.

The problem

A reviewer asks for specific changes. Jira holds the change decision, Bitbucket holds the pull request and review, and Pipelines holds the deployment record. A person has to reconstruct the relationship. A current approval flag cannot establish which source revision was reviewed, and missing history cannot honestly be turned into a pass.

The workflow

Paste the requested Jira keys. ChangeProof collects the available configured source facts and accounts for every key: Evidenced, Policy exception, Cannot determine, Outside configured scope, Source unavailable, or Not found or not visible.

Open a change to compare the captured approved source with the recorded merged source parent. A separate comparison follows the merge revision to its deployment record. The interface distinguishes exact equality, bounded ancestry and missing evidence. Its verdict comes from the control engine, not from comparing shortened hash strings by eye.

Download the selected sample as readable HTML, JSON and CSV with a SHA-256 manifest. The report leads with the requested-key summary and the actual policy, including any check not required by that policy. Authorized users can attach a live pack to a restricted Jira audit work item. Missing keys and gaps stay in the delivered request.

How it is built

Atlassian Forge hosts the global Jira workbench, issue panel, resolvers, scheduled reconciliation, signed Bitbucket webhook receiver and app storage. Jira/JSM provide issue visibility, approval histories and audit-work attachments. Bitbucket Cloud provides PR, commit and pipeline/deployment records. Public setup, privacy and support documentation are hosted in Confluence.

The app verifies the webhook body signature, repository identity and body-contained decision semantics, deduplicates replayed bodies, resolves shortened commit references through the source API, and checks merge parents. Unknown or incomplete facts do not pass. Jira visibility and reviewer access are checked separately. Credentials use encrypted Forge secret storage.

Normalized signed review/removal/merge facts remain with repository evidence until disconnect; short-lived ingestion records expire after 180 days or are removed after successful retention. Retained facts preserve their original observation time and ambiguity. Already deleted historical events cannot be reconstructed. Disconnect removes app evidence and credentials; it does not delete the original source records or downloaded/attached copies.

What works today

A separate unlicensed judge app installs on a test Jira site and provides a prefilled, entirely synthetic demonstration without source credentials. Its examples include the difference between an approved source revision and the revision that merged.

A real two-account integration fixture has produced live Evidenced, with a completed JSM approval, captured PR review, recorded merge parent and a successful echo-only Production fixture deployment. Its disclosed policy allows author merges: C1 is Not required; C2–C6 are Supported. This is not a claim of six Supported checks under strict three-identity separation, or a customer production deployment.

The current test suite covers authorization, hidden-key export, signed-capture semantics, replay, ambiguity, revision relationships, resumable collection and erasure. Retention tests simulate 200 days and deletion of short-lived records while preserving valid historical revision support. These software tests are not customer validation.

Challenges and lessons

Real webhook payloads used shortened revisions while source APIs returned full hashes. Prefix similarity was insufficient: we retained the raw captured reference, the recorded API mapping and the derived relationship separately. Missing deployment dates required explicitly identified pipeline bounds. Long requested samples required checkpointed evidence reuse instead of repeating deployment queries for every key.

The product does not send evidence to an AI service or use an LLM to decide controls. Codex assisted implementation, regression tests and release checks. Fable provided skeptical product and code reviews; its findings were verified against source behavior.

Boundaries and judge access

One configured Bitbucket Cloud repository per installation; Pipelines deployment environments only; read-only resource-token and signed-webhook setup for live evidence. Historical capture starts after setup. Missing identities, histories or unsupported revision relationships remain unresolved. File hashes establish pack integrity, not independent source authentication or regulatory compliance.

Start with the public Confluence guide. It includes the actual judge installation link, login/site-admin prerequisites, the prefilled workflow and optional live configuration. Demo requires no token. No customer data or credentials are needed to evaluate it.

A second real integration fixture was approved by the independent reviewer, changed by a later commit, merged while Bitbucket still showed Approved, and deployed by an echo-only Production pipeline. Read-only source records run through the release engine produce a reviewed-revision Policy exception. Direct app UI resolution/export of this new fixture remains pending; this source-backed verification is kept distinct from a user-facing walkthrough.

Outside onboarding and audit-practitioner validation are still pending. A private narrated review cut is prepared; the final public video is not yet published.

Built With

• atlassian-forge
• bitbucket
• javascript
• jira
• jira-service-management
• react