Axiomo transforms pull requests into structured artifacts called Signals. Each Signal answers the questions reviewers actually need answered - who submitted this, what are they trying to do, what's the risk, and where should I focus?
Quick Start
Option 1: Scan a PR manually
- Paste any public GitHub PR URL into the form on the homepage
- Wait for analysis (usually 10-30 seconds)
- Review the Signal - structured information about risk, contributors, and focus areas
No signup required for public repositories. Sign in with GitHub to save your history and analyze private repos.
Option 2: Install the GitHub App
Get Signals automatically on every pull request:
- Install the Axiomo GitHub App on your organization or personal account
- Choose which repositories to enable
- Every new PR will automatically get an Axiomo Signal as a check run and a PR comment
The GitHub App posts a summary comment and creates a check run with the conclusion (success, neutral, or failure) mapped from the review recommendation.
Signal Anatomy
Every Signal contains these sections:
PR Metadata
Basic information: repository, PR number, title, author, branches, and timestamps.
Risk Assessment
A computed risk level (low, medium, high, or critical) with explicit drivers explaining why. See Risk Scoring below.
Contributor Context
Who submitted this PR and what's their track record? Trust level, account age, prior contributions. See Contributor Trust below.
Intent
An AI-drafted summary of what the PR is trying to accomplish, extracted from the PR description, commit messages, and diff analysis. Includes:
- Goal -What the change aims to achieve
- Non-goals -What it explicitly doesn't do
- Acceptance criteria -How to verify it works
- Confidence -How certain the AI is about the extraction
Evidence Signals
What automated checks exist and their status. See Evidence below.
Supply Chain
Does this PR modify dependencies, lockfiles, CI configuration, or build scripts? These changes warrant extra scrutiny.
Focus Files
The 3-5 files that matter most for review, ranked by importance. Filters out noise like lockfiles and generated code.
Triage
How much effort will this review take? Estimated review time, staleness risk, and recommendations.
Review Recommendation
Suggested action (approve, comment, request changes, or needs discussion) with rationale.
Risk Scoring
Risk is computed as a score from 0 to 1, mapped to levels:
- Low (0-0.3) - Routine changes, low scrutiny needed
- Medium (0.3-0.6) - Normal review, some attention required
- High (0.6-0.8) - Careful review recommended
- Critical (0.8-1.0) - High-stakes change, thorough review essential
Risk Drivers
Every risk score has explicit drivers you can inspect:
- new_contributor -First-time contributor to this repository
- young_account -GitHub account less than 90 days old
- large_diff -Many files or lines changed
- touches_auth -Modifies authentication or authorization code
- touches_payments -Modifies payment or billing code
- modifies_ci -Changes CI/CD configuration
- modifies_dependencies -Adds or modifies dependencies
- sensitive_path -Touches paths marked as sensitive
- cross_team -Contributor from a different team (private repos)
Each driver shows its weight and which files triggered it.
Contributor Trust
Trust levels indicate how much history we have with a contributor:
Trust Levels
- New -Limited history or unknown track record. Higher scrutiny recommended.
- Low -Some history but insufficient for confidence. Standard review process.
- Established -Consistent positive track record. Can be trusted for routine changes.
- Trusted -Strong history with high approval rate. Focus on design rather than implementation.
- Maintainer -Has write access to the repository.
Public Signals
For all PRs (including open source), we analyze:
- Account age -How long the GitHub account has existed
- First contribution -Is this their first PR to this repo?
- Prior PRs -How many PRs have they submitted before?
- Merged PRs -How many were actually merged? (strongest signal)
Internal Signals (Private Repos)
For private repositories with history access, we also consider:
- Tenure -Days since first commit to the organization
- Approval rate -Percentage of PRs approved without major revision
- Review cycles -Average rounds of review before approval
- Reverts caused -PRs that were later reverted (negative signal)
- Areas of expertise -Paths where they have significant merged history
Familiarity Context
Trust level is separate from familiarity. An established contributor touching code they've never worked with before still warrants extra review for those specific files.
"Established contributor (47 PRs, 92% approval rate). However, this is their first time modifying src/services/webhooks/."
Evidence Signals
Evidence signals show what automated verification exists:
Signal Status
- Pass -Check completed successfully
- Fail -Check failed
- Pending -Check is still running
- Unavailable -Check doesn't exist or couldn't be retrieved
Common Signals
- ci_status -Overall CI pipeline result
- tests -Test suite execution
- linting -Code style and static analysis
- security_scan -Security vulnerability scanning
- coverage -Code coverage thresholds
Completeness Score
The evidence completeness score (0-100%) indicates how much verification exists versus what we'd expect. A PR with no CI at all has low completeness; one with comprehensive checks has high completeness.
Supply Chain Analysis
Supply chain changes are flagged because they can have outsized impact:
- Modifies dependencies -package.json, requirements.txt, Cargo.toml, etc.
- Modifies lockfile -package-lock.json, poetry.lock, etc.
- Modifies CI config -GitHub Actions, CircleCI, Jenkins, etc.
- Modifies build scripts -Makefiles, build.gradle, webpack config, etc.
Supply chain risk levels:
- None -No supply chain files touched
- Low -Minor changes (lockfile updates)
- Elevated -New dependencies or CI changes
- High -Multiple supply chain categories affected
Focus Files
Not all files deserve equal attention. Focus files are ranked by priority:
- Critical -Security-sensitive, authentication, payments
- High -Core business logic, API contracts
- Medium -Regular application code
- Low -Tests, documentation, configuration
Noise files (lockfiles, generated code, vendor directories) are filtered out automatically.
Triage Guidance
Triage helps you plan your review:
Review Effort
- Trivial -Quick glance, few minutes
- Low -5-15 minutes
- Medium -15-30 minutes
- High -30-60 minutes
- Extensive -Over an hour, consider splitting
Staleness Risk
Is this PR likely to be abandoned?
- None -Recent activity
- Low -Some delay but active
- Medium -Contributor hasn't responded in a while
- High -Extended silence
- Likely abandoned -No activity for extended period
Privacy
Axiomo only accesses data you authorize:
- For public repos: We read publicly available PR data
- For private repos: We request read-only access to repository contents
- We never store your source code - only computed metadata
- Signals can be deleted at any time
See our Privacy Policy for details.