Skip to content
BuildVouch
All guides

Repository edition · v1

Changes and deployment history

See what a PR changed, which reviews and checks GitHub recorded, and whether its merge commit belongs to a provider-reported deployment. Keep build success, code sync and live runtime verification separate.

Connect and import

An owner or editor first connects the selected repository in the application's Connection tab. The server credential needs read access to Contents, Pull requests, Checks and Deployments, in addition to Actions for the existing evidence connector. No repository writes or customer database access are required.

Open Changes & deployment and import page 1. Each page contains up to ten PRs, oldest first. Continue to the next page shown after import. New PRs are appended at the end; refresh the last page to find them. Refresh an earlier page to reconcile changed reviews, checks or merge status on its PRs. Every successful fetch appends an observation; it never overwrites history. This is an explicit, bounded backfill, not a continuously running scheduler.

The PR title identifies its stated purpose. Expand a PR to see changed files, migration filenames, head/merge commits, reviews and GitHub check runs. Use its source link for the full rationale, discussion and diff. BuildVouch does not import raw descriptions, patches, logs or customer records.

Know what is actually proved

GitHub deployment success is a provider report, not a probe of the running app. Commit ancestry links each fetched merged PR to the latest successful-status production deployment returned by GitHub. A failed or pending latest deployment leaves inclusion Unknown; BuildVouch does not silently fall back to an older success. Rebase/rewritten ancestry can remain Unknown. Even an ancestor may have been subsequently reverted: inclusion means commit history, not proof the feature still works.

Lovable does not necessarily create GitHub deployment records. In that case the provider state is Unknown. The app adapter reports Lovable sync, deployment, runtime and migrations separately, always marked independently unverified. Those reports cannot create a PASS verdict or release approval. Migration reports compare names and SHA-256 checksums; equal counts are insufficient.

Coverage and freshness

  • One history page fetches at most ten PRs. A full ten-item page offers a continuation; an end-of-list observation does not prove all previous pages were imported.
  • File and review lists are bounded to their first 100 entries and labelled partial when that bound is reached. Checks expose their fetched count coverage. Legacy commit statuses and checks of the merge commit are excluded.
  • GitHub deployment coverage is the latest production deployment only. Older deploys enter the archive when observed by later syncs; deployments that predate collection have not been exhaustively backfilled.
  • Source failures keep previous observations available. Old data is labelled with its observation date. Refresh observations older than 24 hours before making release decisions.
  • The timeline loads 50 observations at a time. Load older observations to inspect earlier snapshots, including superseded PR metadata and adapter reports.
  • Source deletion, unavailable private repositories and history rewrites limit what can be recovered. No claim of a complete universal history is made.

Adapter API

POST /api/v1/products/{id}/observations with a product-bound evidence:write token. Use scripts/submit-observation.mjs observation.json from the trusted server or CI. The JSON contract is in /api/openapi.json. Reuse the same request key and identical payload for retries; conflicting reuse is rejected.

GET /api/v1/products/{id}/timeline requires product read access. Use the returned next_before as the next before query parameter. POST /api/v1/products/{id}/history accepts { "page": 1 } and requires a human owner/editor session plus the server's selected-repository configuration.

See the app adapter guide for the Mission Control screen and product-specific controls.

Deployment identity

BuildVouch records a deployment passport rather than one ambiguous “deployed by” label:

  • Initiated by is the person or service that requested the provider deployment.
  • Approved by lists environment or release reviewers when that source exposes them.
  • Executed by is the human or automation principal that performed or finalized the provider deployment.
  • Verified by remains separate and is created only by a later independent verification event.

The identity is stored with the exact repository, commit SHA, environment, provider deployment ID and timestamps in the immutable observation. A GitHub deployment creator or status creator is labelled as GitHub API identity. An app adapter may report the same roles, but those identity claims remain independently unverified. A commit author, PR reviewer, PR merger, BuildVouch token owner and deployment executor are not interchangeable.

Legacy observations without identity fields remain readable and show Unknown. They are never backfilled by guessing.