Permissions and data handling

GitHub permissions

The app requests these permissions to read repository context, publish review feedback and checks, and verify organization ownership at sign-in. It commits to your repository only when you press a button that says so: Create test PR during setup, which puts a one-line test change on a branch of its own (impeccable/…) and opens a pull request you can close, and the buttons that add or update a setup file, such as the preview workflow, which open a pull request on a branch of its own. It never commits to your default branch or to a branch of yours, and it never merges. Where your organization has not granted write access, those buttons open the file in GitHub’s editor, prefilled, for you to commit.

Repository contents

Read and write, the write used only for the pull requests you ask for

Pull requests

Read and write

Checks

Read and write

Issues

Read-only

Repository metadata

Read-only, included automatically by GitHub

Organization members

Read-only, to verify organization ownership

Email addresses

Read-only, with your authorization at sign-in, to save your primary verified address for account communications

Requested permissions are not a record of your installation’s grants. Your approved permissions and selected repositories are managed in GitHub. Existing installations need an owner to approve permission updates; changing the app’s request does not grant them automatically.

Review the GitHub App and your installed GitHub Apps. For an organization, open its GitHub Settings → GitHub Apps → Configure. Sign in to Impeccable again after approving an update.

AI processing

Repository files, diffs, pull-request context and preview media are sent to the model providers configured for a review as needed. Customer content is sent only to the AI providers listed in the Terms of Service, Section 6, under each provider's published commercial API terms, which state it is not used to train their models. Each may keep it for a limited abuse-monitoring period, and its terms set where it is processed.

A review can store a snapshot of your source, and its output can quote your code. How long each is kept is under storage and retention.

Product analytics

We use PostHog, in its United States region, to see how the website and workspace are used: page views, clicks, heatmaps and JavaScript errors, that you joined the waitlist (never your address), and session recordings once you are signed in. Its requests go through our own domain, which passes on your network address so PostHog can estimate location. The operator console is not recorded.

On workspace pages, recordings show our interface and the text of reviews and persona visits. Some of that names your account, repositories, files and pull requests: every event and recording carries the page address, which includes the account and repository, and some buttons and review text name a repository or app. Everything else is configured to be masked: account, repository and app names in headings, links and navigation; pull request titles and authors; file paths, routes and preview addresses; commit ids; where a persona went and what it typed; every form field; and link targets, tooltips and other attribute values, except what lays out and styles the page, including the fonts a design page loads. Code blocks are left out, and network requests are not recorded. A click there names only which of our buttons or links it was, never its words or where it leads. A workspace page we have not classified is masked entirely.

The service also sends PostHog records of what it did: installs, repositories added or removed (as counts), sign-ins, terms acceptances, the onboarding steps (such as how many apps you chose, and which kind of preview access you saved, never the key itself), and reviews started, posted, skipped or failed, with the account and repository names involved, never pull request text, code or findings. Error reports carry the error message and where in our code it happened. When a workspace page gives up waiting or a request fails, it reports which part of the page, a short reason, the status code and how long it waited, never what the page showed.

Session recordings are deleted after 30 days. Other analytics events are kept for up to seven years, the fixed retention on our PostHog plan. Email privacy@renaissance-geek.ai to have the analytics data linked to you deleted.

Storage and retention

We store review metadata and findings, the votes readers leave on findings (a thumb, an optional note, the GitHub login of a reader signed in to Impeccable, and a keyed hash of their network address for rate limiting), derived design profiles and personas, account and permission information, billing state, preview details and encrypted preview credentials. Review files can include source snapshots, screenshots, crops, audio and raw model responses.

Private source snapshots and review-state JSON are never served through media URLs. Uploaded site previews use a separate access gate. How review images, recordings and audio are served is described under review media.

Run files

Expire after 90 days, including source snapshots stored with a run.

Uploaded static previews

Expire after 30 days.

Design caches and persona portraits

Kept while the installation is active, and deleted when you uninstall.

Database history and backups

The database is backed up every twelve hours, and those copies are kept for two days; daily backups are kept for 35 days and monthly backups for twelve months. Something deleted from the database stays in these until they expire.

Review records after uninstall

Run metadata, findings, scores, derived design profiles and personas stay in the database after uninstall until you ask us to delete them. Deleted within 30 days of a request to privacy@renaissance-geek.ai.

Recovery copy

Stored review files are also copied to a second storage bucket for recovery. The copy has the same expiry rules, and uninstalling deletes from both.

Deleting our stored files cannot retract GitHub copies, public caches or downloads.

Review media

GitHub displays the images in a pull request comment or check through its own image proxy, which fetches them without any login. For that reason the images Impeccable posts to GitHub are served without a sign-in, with a long cache lifetime, until the file is deleted under the retention rules above. Anyone who has such a link can open it. A review image’s link carries an unguessable run identifier. A persona portrait’s link is built from the repository’s name and the persona, so treat portraits as visible to anyone who can see your pull requests.

What GitHub shows, and so what is public by link: finding crops; the annotated captures attached to the check (desktop and mobile, the visible screen and the full page, with findings highlighted); the clean desktop capture and its before-change counterpart in the Before/After overview; persona session cards and the stills of a simulated visitor’s session (a recap shows one of them); and persona portraits, with the smaller copy a session card is drawn from.

Everything else is served only to signed-in members of your workspace: clean mobile and tablet captures, the pieces a tall page is cut into, after-action images, motion frames, audio, screenshots attached to a pull request, and every file that is not an image. That includes the tiny copy of each persona portrait that your workspace’s lists show.

Removing access

You can remove a repository from Impeccable in your workspace, on its Repositories page. Removal deletes its preview connection, the sign-in details stored for that preview, the tunnel opened for your CI and the builds your CI uploaded. It keeps the design profile, the personas, the review settings and the exclusions for 90 days so that connecting the repository again can restore them, and deletes them at the end of those 90 days or as soon as you choose to start fresh. Past reviews and their findings are kept either way; they are hidden while the repository is removed and shown again if you connect it. Removal does not uninstall the app: GitHub goes on listing the repository for it until you change that in GitHub.

You can also change repository access or uninstall the app in GitHub. Uninstalling removes access and starts a limited cleanup attempt, and deletes anything a repository removal was keeping; it does not establish complete erasure of previously collected data.

Deletion needs verification across the affected stores, including any incomplete cleanup and copies held by service providers or in backups. There is no verified universal deletion deadline for the closed beta.