Where Your AI Context Layer Should Be Allowed to Run
Some teams cannot adopt a tool until they can answer where the data lives and who can reach it.
For a context layer, that answer should be a setting, not a sales exception.
What this covers
- For regulated teams the adoption question is not only what a context layer stores but where it runs and who controls the data plane.
- Separating the control plane (licensing and the relationship with the vendor) from the data plane (the database, the content, identity) lets a team keep their data while still using a managed product.
- Self-hosting on your own infrastructure, with your own SSO, turns where does the data live from a sales exception into a deployment setting.
- Pathrule already stores team knowledge rather than source code; for teams that need the data on their own infrastructure, a self-hosted edition runs the same product against a database they own.
What a security review actually asks
- Where does the data physically live, and in whose account?
- Who can reach it, and through which identity provider?
- What leaves our network, and on what schedule?
- What happens to our data if the contract ends?
- Can we audit who saw and changed what?
The question under the questionnaire
Plenty of teams want AI coding support and cannot have it yet. Not because the tool is weak, but because they cannot answer a procurement question: where does our data live, and who can reach it.
For a context layer this is sharper than usual. The layer holds the decisions, conventions, and working habits a team writes down. That is not source code, but it is sensitive in its own way.
So the real adoption question is rarely whether the feature is good. It is where this is allowed to run, and whether you can prove it. A tool that can only answer that with a sales exception is a tool many teams quietly skip.
Separate the control plane from the data plane
The useful mental model is two planes. The control plane is the commercial relationship: who licenses the product, who bills, and who decides what you are entitled to. The data plane is the substance: the database, the content, the identities, and the backups.
These do not have to live in the same place. A team can be entirely comfortable with a vendor owning the control plane while insisting the data plane stays on infrastructure they own.
Most tools collapse the two. You either use the hosted product, data and all, or you do not use it. Keeping the planes separable is what makes a security-reviewed adoption possible without forking the product.
Data residency is a setting, not a favor
Where does the data live should have a boring answer: wherever you deploy it. For some teams that is a vendor cloud. For others it has to be their own VPC, their own region, and their own database.
When residency is a deployment setting, the security review changes character. Instead of negotiating an exception, the team is reviewing a configuration they control. That is a conversation that can actually close.
The same logic applies to identity. Enterprises do not want another account system; they want their own SSO. Access should route through their identity provider, so it follows the same lifecycle as everything else they run.
Self-hosting should not mean a weaker product
The failure mode of on-prem offerings is the cut-down fork: a stripped product that lags the hosted one and slowly rots. Teams end up paying more for less, and the vendor maintains two codebases badly.
The better shape is the same product pointed at infrastructure you own. The team features, shared memory, live activity, and the awareness of who is touching what, should run on your side, not be the price of self-hosting.
That is only possible if the architecture was built for it: one backend that can target a database you host, delivered as something you can run, rather than a special edition assembled for each deal.
Keep the knowledge, choose the ground it stands on
We start from a narrow boundary: Pathrule stores the knowledge a team writes down, the memories, rules, and skills, not the repository source code. That already takes the scariest item off the table for many reviews.
For teams that need more than a boundary, the next question is location. We are making it possible to run the full product on your own infrastructure, with your own SSO and your own database, so the data plane is yours while the licensing relationship stays with us.
If your team has been blocked on where this is allowed to run, that is exactly the conversation we want to have. The honest answer should be a setting you control. Reach us at [email protected], or read how we think about the boundary on the security page.