Code intelligence, explained

Code intelligence that maps, remembers, and maintains.

See dependencies, recover past decisions, and turn breaking API changes into verified drafts ready for human review.

How the parts work togetherRepository in. Evidence out.
Your repositoryCode, history, contracts, and tests
Code graphMaps what connects

Current structure

MemoryAdds what the team learned

Past context

API maintenanceActs when evidence is complete

Verified change

What your team receivesGrounded answers or a reviewable draft
Start with a real engineering question

A vendor removes a field your service still sends. What happens next?

Synaptic uses each capability for a different part of the answer. No layer has to pretend it knows more than it does.

  1. The graph finds the blast radius.

    It follows the API call through wrappers, callers, owners, and tests.

  2. Memory adds the missing context.

    It surfaces the earlier decision, incident, or failed fix tied to that code.

  3. The API system prepares the update.

    It changes only approved files, runs the required checks, and opens a draft when the result is conclusive.

The graph shows what depends on what.

Think of it as a live map of the repository. It connects code and runtime boundaries so a person or coding agent can inspect impact without reading every file.

Synapticrepository graph / source-linkedfind node...min degree  0all communities
KnowledgeGraphload_graph()query_graphExtractionResultNodeIdGraphDatato_html_string()predict_impactsynaptic-serversynaptic
A real source-linked graph view. Nodes represent code and resources; edges explain how they are connected.
Ask“If I change this function, what could break?”
  1. Build the map

    Synaptic extracts symbols, calls, imports, data, resources, and API usage into one portable graph.

    A current model of the repository
  2. Follow the connections

    A query can move from one function to its callers, tests, tables, services, and cross-language handoffs.

    A bounded change-impact path
  3. Return the evidence

    Answers retain relationship type, file location, confidence, and known blind spots instead of hiding uncertainty.

    A source-linked explanation
Learn how graph queries work

Memory keeps the reason, not just the diff.

Git can show what changed. Synaptic memory can return the decision, incident, procedure, failed attempt, or verified result that explains why the change matters.

Example memory answer
QuestionWhy does token refresh retry only once?
Keep the single retry. A second retry amplified an outage by creating duplicate refresh traffic. The rollback and follow-up test both passed.
Incident 184ADR-012Commit 6f21a9

Illustrative answer format. Every production result points back to the evidence stored for that repository.

  1. Collect durable evidence

    Commits, decisions, procedures, reviews, incidents, CI runs, and verified outcomes become immutable records with source links.

  2. Attach it to the right revision

    File and symbol anchors keep an old decision connected to the code version it described, even after renames and rebuilds.

  3. Retrieve only what applies

    Search can filter by symbol, path, outcome, confidence, lifecycle, owner, and recency. Superseded records stay auditable but out of normal answers.

The graph
Current relationships that can be rebuilt from the repository.
Repository memory
Source-cited observations that survive graph rebuilds and keep their original revision.
Not chat history
Memory is repository evidence with identity, policy, lifecycle, and verification fields.

The API system turns a vendor change into a reviewable update.

It watches only the providers you configure. When a breaking event applies to your installed version and observed usage, Synaptic can prepare and verify a bounded repair.

A breaking API change, from signal to draft
  1. Discover

    Find installed SDKs, contracts, and observed external calls.

  2. Detect

    Read configured vendor sources for a grounded breaking change.

  3. Locate

    Use the graph to find affected calls, wrappers, owners, and tests.

  4. Repair

    Ask an agent for a bounded patch inside an isolated worktree.

  5. Verify

    Run policy, build, test, and graph checks with network access blocked.

  6. Open a draft

    Publish one reviewable GitHub pull request or GitLab merge request.

For the removed field, Synaptic can prove:

The installed SDK is affected, three call sites use the operation, one wrapper owns the behavior, and two tests cover the path.

Conclusive resultA small patch, complete verification evidence, and one draft PR or MR.

What Synaptic automates

  • Scheduled provider, version, and usage checks
  • Graph-based impact analysis
  • A bounded repair attempt in an isolated worktree
  • Configured build, test, policy, and graph checks
  • Creation or update of one draft change request

What stays under your control

  • Which providers and repositories are enabled
  • Allowed files, commands, reviewers, and risk limits
  • Whether an inconclusive event receives manual review
  • Normal CI, branch protection, approval, and merge
Read the API maintenance procedure

Use the same evidence where your team already works.

The capabilities stay consistent, but each surface receives only the access it needs.

Synaptic Cloud
Search graph and memory, inspect coverage, set policy, dispatch runs, and follow a result to its draft.
VS Code and JetBrains
Query local source, work with repository memory, and confirm source-changing API operations beside the code.
GitHub and GitLab CI
Run scheduled or manual maintenance with repair credentials separated from the final publish job.
CLI, REST, and MCP
Give people, scripts, and coding agents the same compact, source-linked answers.

Start with the question your codebase cannot answer today.

Build the graph first. Add durable memory as your team works. Enable API maintenance when your coverage and policy are ready.