When an AI coding tool analyses your repository, what exactly does it send to the cloud? For most tools, the answer is: your source code. The model has to see the code to reason about it. That is the implicit contract.
For teams in regulated industries, financial services, healthcare, defence, legal, that contract is unacceptable. Source code is intellectual property. It may contain regulated data. It may not leave the network perimeter without explicit compliance review.
Spiderbrain's source-free brain model breaks this contract. The graph is shared; the source is not.
What a source-free brain contains
A Spiderbrain brain is a graph, not a code archive. Each node in the graph represents a file or function. Each edge represents a relationship (import, call, inheritance). The properties on each node are structural:
- Degree centrality
- Community membership
- Blast radius (pre-computed)
- Spikescore (structural significance rank)
- Tag membership
What is deliberately excluded from the serialised brain: file content, function bodies, variable names beyond graph structure, string literals, comments.
The result is a graph that encodes the architecture of your codebase without encoding its content. You can share it, store it in the cloud, and query it via API, and the recipient cannot reconstruct your source from it.
The SHA-256 commitment scheme
Each node in the brain is identified by a SHA-256 hash of its canonical path (not its content). This means:
- File identity is preserved (you can ask "what is the blast radius of
auth/session.js?") - File content is not disclosed (the hash is not reversible)
- Structural queries work normally (graph traversal follows edges by hash, not by name)
For the subset of queries that require names (e.g., "show me the community members of the auth cluster"), the API returns hashed identifiers by default. Display names are optionally resolved client-side, from the local copy of the codebase.
On-premise deployment
For teams that cannot share any external artifact, not even the source-free graph, Spiderbrain supports fully on-premise deployment. The brain is built locally, queried locally, and never leaves the network perimeter.
The same /api/score and /api/brains endpoints are available in the on-premise deployment. The intelligence layer runs locally. The only external call is optional: the AI enrichment layer (semantic clustering, intent extraction) can be disabled or routed through an internal model endpoint.
What compliance teams actually care about
In practice, compliance reviews of code intelligence tools focus on:
- Data classification: does the tool process data classified as confidential or restricted?
- Data residency: does the tool send data outside approved geographic regions?
- Retention: does the tool retain processed data? For how long?
- Access controls: who at the vendor can access the processed data?
The source-free brain model provides clean answers to all four:
- No source code is processed by external systems, only the structural graph
- The graph can be stored in any region; source never leaves the local environment
- Graphs are versioned by commit hash; retention policy is controlled by the customer
- No vendor-side access to source; graph is a derived, non-reversible artifact
The tradeoff
Source-free analysis is structurally complete but semantically limited. The brain knows that auth/session.js imports crypto/hmac.js and has 18 callers. It does not know that auth/session.js implements JWT validation, that semantic knowledge requires reading the source.
For structural use cases (blast radius, community detection, dependency traversal, context selection), source-free is complete. For semantic use cases (intent extraction, documentation generation, code explanation), source-free requires a local pass, running the semantic layer against the local copy of the source before querying the cloud graph.
This is the right architecture for regulated industries: structural intelligence in the cloud, semantic intelligence on-premise.