Spend more review effort on a particular change#
A database migration deserves a different investigation from a copy change. Deep Review gives you a separate credit budget and runtime limit for work that needs more investigation.
Open a pull request in Proofline, choose Run deep review, and add a focus. For a migration, that might be: “Check whether the previous application version can still write to this table after the migration.” The run records the current pull request head and keeps the focus it started with. Returning to the same deep review opens that recorded run.
An administrator sets the budget before anyone starts. You can keep Deep Review manual or request it automatically for changes to paths such as migrations/**. Automatic risk escalation is another opt-in control. Repository settings can restrict the organization policy.
Configure and run a deep review.
Put the design document beside the code#
Suppose a billing change follows a design document in Confluence. The pull request diff explains the edit, while the document explains the behavior the team intended.
You can now pin that page to services/billing/** in the repository's Guidance settings. Reviews that touch those paths can read the page. The same workflow supports Notion pages and Google Docs.
First connect the document service and name the spaces, roots, or folders Proofline may read. Then choose a page and the repository paths it applies to. You control both the allowed source and the part of the code that makes it relevant.
Document context can help a reviewer check an implementation against its requirements. Claims about the running environment still need infrastructure evidence.
Pin a document to repository paths.
Issue trackers have connection pages too. Jira Cloud and Linear provide referenced issues; Asana provides linked tasks from allowed projects. A review uses one tracker connection, with Jira preferred over Linear and Asana. Provider availability depends on the deployment's configuration.
Connect an issue tracker or document service.
Record which repositories belong together#
An API schema and its client may live in separate repositories. Repository clusters let an administrator record that relationship with explicit roles: the schema repository is a provider, and the client is a consumer. Repositories that change together without a direction can be peers.
Create a cluster from Organization → Repository clusters, choose its members, and save it. Where suggestions are available, Proofline proposes a group from source configuration and links to its reasons. You review the draft before saving it.
Each saved change has a revision. You can inspect the history, change the membership, or archive the cluster while keeping earlier revisions.
Download the audit trail#
Organization administrators can export the available audit trail from Audit history as NDJSON, one JSON event per line. The export includes security and workflow events beyond the human activity shown in the list. The list's filters do not narrow the download.
Use it when you need to investigate access changes or retain a copy for an audit. The browser downloads a file after the export finishes; if a read fails, Proofline discards the partial file so you can start again.