REPOSITORY INTELLIGENCE / EARLY ACCESS

Your code has a structure.
Your changes have consequences.

Map the architecture behind your repository, discover how pending pull requests intersect, and follow the evidence before you merge.

Open your workspace Explore the architecture ↓

Personal email welcome · Static analysis without an AI key

LIVING CODE ARCHITECTURESELECT A MODULE

CONCEPTUAL DEMO · NOT YOUR REPOSITORY

1–10 of 10 entities · 12 visible edges

Accessible 2D fallback · WebGL unavailable or reduced motion enabled. Selection details include relationships beyond the current page.

Violet / changesAmber / shared riskGreen / verification evidence

Understand the code. See the interaction. Verify the change.Repository understanding → integration hypotheses → reproducible evidence

A SYSTEM VIEW, FROM SOURCE TO DECISION

Less guesswork.
More context.

Keep the structure, the change and its evidence together. Every repository view starts from a pinned revision.

Inside the product

session-service / mainILLUSTRATIVE PRODUCT PREVIEW

INDEXED SCOPE▾ sessionsapi.pystore.py▾ clientlogin.py▾ teststest_session.py

SOURCE / SHARED CONTRACT

def create_session(user):
    return {"token": issue(user)}

# client/login.py
response = create_session(user)
token = response["token"]

One return key. Two pending changes.

A contract candidate needs review before a test can establish a failure.

HYPOTHESIS

Revision-pinned source Python module-path matches Evidence before conclusions

ONE REPOSITORY. THREE PERSPECTIVES.

Your code isn’t a collection of isolated changes.

Keep architecture, pending work and verification in the same conversation.

Read the system

Browse commit-pinned source. Find files and Python symbols. Ask a question with retrieved source evidence.

Trace the dependency

Inspect Python import relationships and shared contracts. Know what the graph resolves—and what it leaves out.

Inspect the interaction

Select PRs, rank shared evidence and compare reviewed tests across exact Git states.

THE REVIEW LOOP

Five moves toward
an informed merge.

A clear path through unfamiliar code and interconnected work.

01

Understand

Index an authorized branch. Browse files, declarations and module-path matches.

02

Discover

Select 2–10 synchronized PRs. Look for shared files and contract changes.

03

Inspect

Read source references and exact revisions. Risk is a heuristic, not a probability.

04

Verify

A separate runner compares baseline, individual and repeated combined states.

05

Decide

Review the evidence. Unavailable infrastructure never counts as a verified defect.

THE STRUCTURE BEHIND THE SOURCE

Follow a relationship.
Open the evidence.

Files connect to their Python declarations and matching internal imports. Select a node, inspect incoming and outgoing relationships, then open its pinned source.

Dynamic imports, aliases and calls remain unresolved. The graph shows the indexed subset and explicit bounds.

Explore the architecture

ILLUSTRATIVE / SUPPORTED RELATIONSHIPS

Exact Git revisionbranch → commit SHA

FilesBounded source index

ImportsPython module-path matches

DeclarationsAST functions & classes

Contracts are hypotheses. Tests establish supported behavior.

THE BUG BETWEEN TWO GREEN CHECKS

Both changes make sense.
Together, the contract breaks.

One PR renames a return key. Another adds a caller that expects the old key. Separate tests can pass while the combined behavior fails.

Intervexa surfaces the shared assumption, then distinguishes a hypothesis from a repeatable failure. Explore this labeled source example.

Follow the verification protocol →

def create_session():
    return {"token": "abc"}

def original_client():
    return create_session()  # no token lookup

PASS · original behavior

Illustrative source. Controlled local Git fixtures test this class of interaction; this preview does not execute code or report a customer finding.

A CLAIM NEEDS A CHAIN OF EVIDENCE

Pin it. Inspect it.
Try to disprove it.

Source paths and revisions accompany static hypotheses. A separate runner compares baseline, individual changes and repeated combined states. A missing environment is an infrastructure problem, never a verified bug.

Inspect the security boundaries →

01 / Authorized GitHub installation

02 / Exact branch and PR revisions

03 / Python AST and bounded retrieval

04 / Ranked, unverified hypotheses

05 / Reviewed test · separate runner

06 / Logs, artifacts and human review

Next.js → FastAPI → database queue → GitHub → optional provider / isolated runner

ADD A SYSTEM VIEW TO HUMAN REVIEW

Keep the judgment. Extend the evidence.

Review question	Manual PR review	With Intervexa
What changed?	Read an individual diff	Pinned source, symbols and PR files
What else depends on it?	Trace assumptions across files	Bounded import map and shared contracts
Will pending changes interact?	Compare separate PRs by hand	Rank evidence from selected PRs
Is the failure real?	Construct and test combined states	Reviewed baseline/individual/combined comparison

Your source has boundaries.

Workspace authorization, exact origin and CSRF checks, ephemeral provider keys and a separate execution host. No compliance certification is claimed.

Security details →

Bring the key. Choose the cost.

Static workflows run without paid inference. Optional AI and embeddings require your key and explicit consent. Provider and infrastructure costs remain separate.

Pricing & usage →

Useful scope, explicit limits.

Python AST analysis, text retrieval, GitHub App access and optional Python stdlib unittest execution. Private execution and universal language support are unavailable.

Supported scope →

BUILT AROUND DEVELOPERS, NOT COMPANY DOMAINS

A workspace for the way you build.

Solo developers

Recover context between client projects and inspect shared assumptions before shipping.

Open-source contributors

Learn unfamiliar codebases, trace module dependencies and review incoming changes.

Startup teams

Bring pending work into one evidence workflow. Current workspaces have one owner; invitations are not implemented.

Students

Build a mental model of unfamiliar Python code. Read declarations alongside the source instead of guessing from a diagram.

Freelancers

Recover the structure of a client project and inspect pending changes before switching contexts.

YOUR GUIDE TO INTERVEXA

From your first repository to a confident review.

Intervexa helps you understand an unfamiliar codebase and examine how pending pull requests may affect each other. Explore real source in 3D, follow dependencies, and inspect evidence before deciding what to merge.

Open your workspace See every feature

Sign in

Create a workspace with your personal email, or use Google or GitHub sign-in. Sign-in identifies you; repository access is a separate permission.

Connect your GitHub repository

Open Repositories → Install GitHub App. Choose your account and Only select repositories. Select the repositories you want to share, then save. Authorize GitHub account when prompted and click Discover repositories.

Build your code map

Open a repository → Explore codebase → Load authorized branches. Choose a branch and click Index branch for the first map, or Refresh pinned index to update it. Drag to orbit, zoom, select a module, or expand to fullscreen.

Find the source

Use Files to read indexed code, Search to find filenames, symbols and identifiers, and Dependencies to inspect Python module-path matches. Every result points to the indexed commit.

Review interacting changes

Return to the repository, sync open pull requests, select 2–10 PRs and start analysis. Interaction explorer shows candidate relationships when changes overlap. Review the evidence and contract changes in Findings.

Verify before you merge

Static findings are hypotheses. Experimental verification requires a separately configured isolated runner and a reviewed test. Compare baseline, individual PRs and repeated combined runs; inspect Test results before making a decision.

WHAT EACH PART DOES

One workspace. A clear purpose for every screen.

Feature	Use it for
Overview	Your connected code atlas, recent analyses, readiness and shortcuts to the next action.
Repositories	Connect selected GitHub repositories, discover access, sync PRs and choose work to analyze. To add another repository, configure the existing GitHub App installation and discover again.
Files & source search	Read bounded, revision-pinned source and find filenames, Python symbols and text identifiers without an AI key.
3D Architecture & Dependencies	Explore files and Python module-path import relationships. Select nodes for details. A keyboard-accessible 2D view supports reduced motion or unavailable WebGL.
Coverage	See what was indexed, parsing issues and omissions. The map represents the selected scope, not every dependency in the project.
Interaction explorer	Inspect shared-file and changed-identifier relationships between analyzed PRs. This is separate from the repository architecture map.
Analysis history & Findings	Track queued/completed/failed analyses, open recorded revisions and inspect potential signature or response-key interactions. Risk scores prioritize review; they are not measured probabilities.
Test results	Inspect actual execution evidence when an isolated runner is configured. An unconfigured runner cannot verify a defect.
Repository Q&A & semantic search	Optional source-grounded questions using your supported provider key; optional OpenAI embeddings require explicit consent and may incur provider charges. Static analysis and lexical search remain available without a key.
Usage & limits	Inspect processing limits and workspace usage before starting more work.
Settings	Manage profile, workspace appearance, provider preferences, security/audit information, export and confirmed account deletion.

Why is a screen empty?

A repository map needs a saved index. An interaction map needs analyzed overlapping PRs; zero open PRs or no candidate overlap can produce an empty result. Findings and test results appear only after the corresponding work runs.

Start with your repository →

What can it establish?

Current static contract analysis focuses on Python. Source indexing is limited to 60 files, 50 KB per file and 500 KB total. Dynamic calls and general cross-language dependencies are unresolved. AI citations are checked, but an answer still needs human review.

Read the supported scope →

How do I run it?

Use the hosted workspace in your browser; no local installation is needed. Free hosting can take longer to wake after inactivity. Deployment operators can follow Docs for local setup and backend/runner configuration. Email recovery and a production isolated runner are currently unavailable.

Setup and operation guide →

EARLY ACCESS / NO CHECKOUT

Start with static evidence.
Add intelligence on your terms.

There is no subscription or billing system. Optional AI is billed by your provider; execution needs a separate supported runner.

Full usage & infrastructure details →

Repository exploration60 files · 500 KB source / index

PR interaction analysis2–10 selected PRs · bounded pairs

Source search & 3D architectureNo AI key required

AI explanation & embeddingsOptional · your key & consent

VerificationSeparate isolated runner required

Create your workspace

Before you connect.

Do I need an AI subscription?

No. Static analysis and lexical source search need no AI key. Paid provider operations are optional.

Does a risk score mean a confirmed bug?

No. It is a transparent heuristic used to prioritize review. Experimental evidence determines reproduction.

What happens when execution is unavailable?

You can explore code and inspect hypotheses. Verification stays unavailable until a separate supported runner is configured.

Which repositories and languages are supported?

Authorized GitHub repositories can be indexed within the configured bounds. Python supports AST declarations and contract analysis; selected other text files support search, not a resolved dependency graph.

How is GitHub access authorized?

Sign-in identifies you. A separate GitHub App installation grants access only to selected repositories, and the server checks workspace ownership.

How is a defect verified?

The reviewed test must pass on the baseline and individual changes and expose the same supported assertion failure on repeated combined states. Static hypotheses and infrastructure errors cannot satisfy this protocol.

How is source data handled?

Bounded source is pinned to a commit and retained under repository policy. Optional AI operations require explicit consent. Provider keys stay in request-scoped memory.

All frequently asked questions →

YOUR NEXT REVIEW, IN CONTEXT

Understand what you’re
about to change.

Create your workspace Read the documentation →

BUILD WITH US

What would make your next review clearer?

Tell us about your workflow, share feedback, or request early access. Don’t include credentials or confidential source.