Questions about code intelligence, SocratiCode, and working with us.
Direct answers for engineering leaders, security teams, delivery partners, and developers. The technical product is documented separately from the Cloud beta and the partner model now being explored through design-partner conversations.
Code intelligence and SocratiCode
What the product does, how it reaches AI assistants, and where its evidence stops.
01
What is code intelligence?
Code intelligence is structured, searchable knowledge about a software system. It can combine source-code meaning, exact identifiers, file dependencies, symbol relationships, API specifications, database schemas, infrastructure definitions, and architecture documents so a person or AI assistant can find relevant evidence across a codebase.
It is context for investigation and decision-making, not an automatic guarantee that an answer is correct. Source, tests, configuration, and runtime behaviour remain authoritative.
02
What is SocratiCode?
SocratiCode is an open-source codebase context engine. It indexes code and selected project knowledge, combines semantic and exact search, and builds file and symbol relationships that an AI coding host can query through the Model Context Protocol.
The open-source engine runs locally or against infrastructure a team configures. SocratiCode Cloud is a separate private-beta route for organisations that want a managed service boundary.
Is SocratiCode another AI model or coding assistant?
No. SocratiCode sits between the codebase and the AI tool a team already uses. The assistant remains the conversational interface and model; SocratiCode gives it tools for finding code, tracing relationships, checking impact, and retrieving indexed project knowledge.
Because the context layer is separate, the same indexed project can be queried from more than one compatible assistant.
04
How does SocratiCode connect to AI coding tools?
SocratiCode exposes its search, graph, symbol, flow, status, and context tools through the Model Context Protocol, usually shortened to MCP. A compatible host starts or connects to the SocratiCode MCP server, then calls those tools when it needs evidence from the indexed project.
The host and model still have their own data-handling settings. Connecting through MCP does not make the assistant itself local or private.
It can index supported source files and build searchable chunks, file dependencies, and symbol relationships. Context artefacts can add non-code material such as database schemas, API specifications, infrastructure configuration, and architecture documents when a project configures them.
Coverage depends on the project, file types, ignore rules, parser support, configuration, and whether indexing completed. A file outside that coverage cannot be treated as searched.
06
What are SocratiCode context artifacts?
Context artifacts are project knowledge that matters to the codebase but is not ordinary source code. A project can declare database schemas, API specifications, infrastructure definitions, architecture documents, runbooks, and similar material, then index and search them through dedicated context tools.
Their index status and freshness still need to be checked. The original schema, specification, or document remains the authoritative source.
Yes. The graph visualisation tool can return a Mermaid diagram or generate a self-contained interactive HTML explorer. Interactive mode includes file and symbol views where the graph size permits them, search, a blast-radius overlay, and PNG export.
The visualisation shows relationships captured from the indexed source. It has the same static-analysis limits as the underlying graph and must not be presented as a complete runtime architecture.
How is SocratiCode different from grep or built-in code search?
Exact search is strong when the identifier or string is already known. Semantic search is useful when the question describes behaviour rather than its exact spelling. SocratiCode combines semantic and keyword results into one ranked result set, then lets the investigator open the source and use graph or symbol tools where relationships matter.
This expands the evidence an assistant can reach. It does not remove the need for precise search, source reading, or tests.
Can SocratiCode help understand legacy code without documentation?
Yes. Start with one business behaviour, confirm the relevant source is indexed, and use semantic and keyword search to find likely implementations. File dependencies, symbol relationships, and change-impact queries help trace the code that needs investigation. Existing schemas, API specifications, and architecture notes can be configured as searchable context artifacts.
SocratiCode supplies evidence to the assistant a team already uses. It does not recover undocumented business intent or prove runtime behaviour. Check the original source, configuration, contracts, and relevant tests, then preserve the verified findings in a handover note with source references.
What do dependency graphs, symbol impact, and call-flow analysis show?
File graphs show recorded imports and dependencies. Symbol tools show definitions, callers, callees, and transitive impact found in the indexed source. Flow analysis traces forward from an entry point through relationships the analyser can establish.
These views help narrow an investigation and expose likely blast radius before a change. They are maps of static evidence, not a complete model of production behaviour.
A search result does not prove a diagnosis, and no result does not prove absence. A graph edge does not prove a path runs in production, and a missing edge does not prove that no runtime path exists. Dynamic dispatch, reflection, generated code, configuration, external services, deployment state, and code outside the index can all change the real behaviour.
Material conclusions still need direct source review and the relevant tests, configuration, contracts, or runtime evidence.
How shared context, linked projects, working copies, and freshness behave in practice.
12
What does shared codebase context mean?
It means several authorised users can query one indexed representation of a repository instead of each session relying on whichever files happened to be opened. It does not mean a shared editor session, and it does not automatically include every developer's uncommitted files.
A useful shared index also needs explicit ownership, a known source revision, compatible embedding settings, and a way to verify that updates completed.
Can a team share one SocratiCode index without Cloud?
Yes. In the open-source operating pattern, team members keep their own checkouts and point SocratiCode at the same external Qdrant collection using a stable project identity. One designated writer updates the collection and reader processes query it.
Every process must use compatible Qdrant, embedding, dimensions, and indexed-representation settings. Readers also need the matching source revision before treating a result as current code.
Does a shared index include uncommitted working-copy changes?
Not automatically. A shared baseline represents the source indexed by its writer. A local SocratiCode process can index a developer's working copy, including relevant local changes, but those changes are a separate source state and should not be silently treated as part of the shared baseline.
Teams can use local and shared context side by side, provided the assistant and the people using it can distinguish which source state each result represents.
Each repository keeps its own index. A project can link sibling projects and ask search to include them, producing one ranked result set with a project label and file path on every result.
Every linked repository must already have a completed, current index with compatible embedding settings. Linking a project does not index it, update it, or grant access to it.
Does linking repositories create one cross-repository dependency graph?
No. Linked search can find relevant files across repositories, but it does not create dependency or call-graph edges between them. Graph and symbol analysis still runs inside each repository's indexed relationships.
A hand-off between repositories must be verified through the actual API or event contract, source, configuration, tests, or runtime evidence.
In the default open-source mode, a watcher handles later file changes while its SocratiCode process is running. Startup resume and deliberate update operations can catch up an existing index. Shared and linked setups still need an owner for each writer and a status check that confirms indexing completed.
A healthy process is not enough if it points at an incompatible or stale index. Check the project identity, source revision, effective index profile, and completion status before relying on results.
By default, a project shares one index across branches and the watcher updates that index to reflect the current branch state. Teams that need separate persistent indexes per branch can enable branch-aware mode, which gives each eligible branch its own collections, code graph, and context artifacts.
Branch-aware mode requires a path-derived project identity. An explicit stable project ID is deliberately not suffixed. Automated branch handling in a Cloud beta environment must be confirmed for that onboarding.
Separate the indexing path, assistant path, evidence boundary, and licence used for client work.
19
Does source code leave the machine when using SocratiCode?
It depends on the configuration. The default local indexing path uses local Ollama and local Qdrant. An external embedding provider receives source chunks, and a remote Qdrant service stores the indexed representation and metadata sent to it.
The AI assistant is a separate boundary. Its provider may receive prompts and SocratiCode tool results even when indexing is local. Review both paths before using sensitive source.
Yes. The documented local-only indexing path uses a native Ollama service for embeddings and managed local Qdrant for vector storage. It requires Node.js 18.17 or newer, Docker, and native Ollama.
Initial package, image, and model downloads still need network access. Local indexing also does not change the data path of the separate AI assistant.
Access is controlled by the environment and services through which the index is exposed. In an open-source shared setup, the team operating Qdrant and the MCP processes owns that access model. Linking a repository must not grant a user access to source they were not already authorised to inspect.
For the Cloud beta or a partner-delivered environment, identity, repository scope, audit requirements, and support access must be confirmed for that specific deployment.
Can SocratiCode be used in an authorised security review?
Yes, as a navigation and evidence-discovery aid within the approved scope. It can help locate reachable operations, policy checks, callers, callees, dependencies, configuration, and tests.
A semantically similar result is a lead, not a finding. A vulnerability conclusion still requires the exact source path, relevant conditions, and safe independent validation through the project's established process.
What does no search result or a missing graph edge mean?
It means the indexed evidence did not produce that result or relationship. The query may have missed the term, the index may be stale, the file type may be outside coverage, the relationship may be dynamic, or the relevant code may live outside the project.
Check index status and coverage, use a precise identifier where one is known, and inspect surrounding source before concluding that something is absent.
How is SocratiCode licensed for open-source use and client delivery?
The public SocratiCode engine is available under AGPL-3.0. An alternative commercial licence is also available for organisations that need rights outside the AGPL terms.
Providing a hosted, managed, or SaaS service to third parties is not granted by the standard commercial licence without a separate OEM or reseller agreement. A consultancy planning to deliver SocratiCode to clients should agree the applicable licence and service terms before delivery.
The partner-led direction, who it is for, and the commercial and service questions still being defined.
25
What is the partner-led direction for SocratiCode?
SocratiCode is exploring a model in which consultancies and implementation companies use or implement SocratiCode as part of work they deliver to their own clients. The aim is to complement direct Cloud conversations, not to remove the open-source product or immediately replace every existing Cloud offer.
The model is intended to be shaped through design partnerships rather than presented as a finished channel programme.
26
What kind of company could be a SocratiCode partner?
The current design-partner conversation is for consultancies, software delivery firms, platform specialists, security consultancies, and implementation teams that already work directly with client engineering organisations.
The strongest fit is a company with a real client use case and the ability to help define delivery responsibilities, support boundaries, contracting, and service levels from practical experience.
27
What does design partner mean here?
A design partner works with SocratiCode before the partnership model is standardised. The work is to test a real delivery scenario and define what each party needs to make it repeatable, supportable, and contractually clear.
It is not a public certification, a generic referral arrangement, or a promise that every commercial term is already settled.
28
What might a partner deliver to its client?
Possible partner responsibilities include discovery, deployment planning, configuration, implementation, integration with client workflows, adoption support, and first-line service management. The exact scope depends on the partner's expertise and the client's environment.
No standard responsibility split has been published. A design partnership must define the delivery boundary before either party makes commitments to a client.
29
What would SocratiCode provide to a partner?
The product, product-level expertise, licensing route, escalation path, and service evidence are the areas to define. Depending on the agreed deployment, the work may also need a clear boundary for maintenance, incident handling, updates, and support for the partner's delivery team.
Those are design topics, not published standard commitments. The exact obligations must be written into the partner and client-facing agreements.
30
Is there already a finished reseller or implementation-partner programme?
No. There is no standard public package with fixed margins, tiers, accreditation, territories, lead sharing, or support entitlements. The current step is to work with design partners and decide which of those mechanisms are actually required.
Any arrangement discussed now should be treated as a specific design-partner agreement, not as evidence of a general programme.
31
Would the partner or SocratiCode contract with the end client?
That is not fixed. A design partnership needs to decide who contracts with the client, who grants the software rights, who invoices, who acts as a data processor where applicable, and who owns each support obligation.
The answer may depend on the deployment and engagement, but it must be explicit before client delivery starts.
32
What would a SocratiCode partner pay for?
The partner commercial model has not been fixed. Open questions include software licensing, any managed-service component, product support, escalation coverage, enablement, and whether the commercial relationship is direct, resale, OEM, or another agreed structure.
Pricing and revenue allocation should follow the responsibilities and risk each party actually carries, not be invented before the service model is defined.
33
What would a partner service contract or SLA cover?
There is no published standard partner SLA yet. The design work should define the supported service, support hours, severity levels, response targets, escalation path, maintenance notice, incident communication, measurement, exclusions, and which party is accountable at each step.
These become commitments only when they are measurable and written into an executed agreement. Product features alone do not establish a service level.
34
How can a company discuss becoming a design partner?
Email SocratiCode with the type of client work you deliver, the deployment or governance problem you are trying to solve, and the role you expect to own. The first conversation is for fit and service-model discovery, not an application to a finished programme.
What is available now, what must be confirmed, and how direct Cloud plans differ from partner terms.
35
Is SocratiCode Cloud generally available?
No. SocratiCode Cloud is a private beta. Availability, deployment shape, data flow, controls, and support for a proposed environment are confirmed during onboarding.
The open-source engine is available to run directly. A public description of a planned Cloud capability is not proof that it is available in a particular beta environment.
How does the Cloud beta differ from the open-source product?
The open-source route gives a team the engine and tools to operate its own indexing, Qdrant, embedding provider, writer process, and access model. The Cloud beta is the route to discuss when a team or partner wants a managed service boundary rather than owning that operating pattern.
The exact managed responsibilities and controls must be confirmed for the proposed engagement.
The site describes managed Cloud, customer VPC, and air-gapped or on-premises routes. Because Cloud is a private beta, the availability and implementation of any one route must be confirmed for the specific onboarding or partner engagement.
For sensitive environments, ask for the exact source path, embedding provider, vector-store location, network boundary, subprocessors, retention, deletion, and support-access model rather than relying on a deployment label alone.
How should buyers assess Cloud governance and compliance claims?
Treat required controls as acceptance criteria for the proposed environment. If SSO, audit logging, data residency, a DPA, certification evidence, encryption ownership, or an incident process is mandatory, confirm its exact status and put the requirement into the contract.
A framework reference, plan name, or future roadmap is not a substitute for evidence that the required control exists in the environment being offered.
Does the Cloud beta include a dashboard, SSO, audit logs, or usage analytics?
The main site describes those as parts of the direct Cloud direction and plan structure. Because the service is a private beta, their exact availability, scope, retention, export behaviour, identity-provider support, and deployment compatibility must be confirmed for the environment being proposed.
If any control is required for procurement or client delivery, make it a written acceptance criterion rather than relying on the feature name alone.
40
Do the direct Cloud plans define partner pricing or service levels?
No. The Team, Business, and Enterprise cards on the main site describe the direct Cloud beta offer. They do not define partner economics, the partner's client price, revenue allocation, support ownership, or a partner SLA.
Those terms remain part of the design-partner work and must be agreed separately.
Setup and supported hosts
The common requirements, current host-specific routes, and the first result to verify.
41
What does the default open-source setup require?
The default setup requires Node.js 18.17 or newer with npx available and Docker running. SocratiCode manages local Qdrant and, by default, Ollama for embeddings. A native Ollama installation can be used instead where appropriate.
After installation, confirm the MCP server responds, complete one project index, and verify a search against a feature known to exist.
Install the SocratiCode Claude Code marketplace and plugin, start a new session, and confirm the bundled MCP server is connected. The plugin already supplies the server, so a second standalone SocratiCode MCP registration is unnecessary.
Add the SocratiCode Codex marketplace, install the plugin, and start a new task or CLI session in the project. Confirm the SocratiCode tools respond before indexing. The plugin bundles its MCP server, so do not add a second standalone registration.
Install the SocratiCode extension, open the intended workspace, and use Agent Chat to confirm the SocratiCode tools are available. Index the workspace, wait for completion, and verify a known feature through search.
Use the documented MCP installation route, open the target project in Cursor, and confirm the SocratiCode server and tools are available. Then complete an index and check a known feature through semantic search.
Register SocratiCode as an MCP server in Gemini CLI from the project environment, confirm the server responds, then index one project and verify a known result.
Add SocratiCode as a Continue MCP server, use Agent mode, and confirm the tools are available in the intended project. Complete indexing before relying on search results.
Configure the SocratiCode MCP server in Cline, confirm the connection in the target project, and complete a first index. Verify the integration by opening a returned source location for a feature known to exist.
Add SocratiCode to an OpenCode 1.x project as an MCP server, confirm the connection, and complete indexing. Verify the result by searching for a known function or feature and opening the returned source.
First confirm the MCP server responds. Run codebase_index for the intended project and check codebase_status until it reports completion. Then search for a function or feature known to exist, open one returned location, and confirm the path and source belong to the expected project.
A connected server without a completed index, or a search result from the wrong project identity, is not a successful setup.
For consultancies and implementation teams considering SocratiCode in client work, the next step is a direct conversation about delivery boundaries, support, contracts, and service levels.