Most AI projects I get called into are stuck in the same place. Someone built something genuinely impressive in a weekend. Then two questions come up in a review — can it show a user something they shouldn’t see, and what happens the first time it acts on its own — and the project quietly stops for three months. Closing that gap is the work.
Running system, public source, passing tests. Inspect it before you talk to me.
// Permissions are applied to the corpus first.
// Similarity is only ever scored on what this user may read.
snapshot = _chunks
.Where(c => c.IsVisibleTo(roles))
.ToList();
return snapshot
.Select(c => new {
Chunk = c,
Score = VectorMath.CosineSimilarity(queryEmbedding, c.Embedding)
})Where projects stop
Neither is about the model. Both are engineering problems with known answers, and both are usually left until someone senior asks.
Most retrieval systems fetch the closest matches, then filter the results by permission. The filter runs after the search. Even when the text is removed, ranking, result counts and citations still carry information about documents the user was never cleared to know existed. The fix is to apply the permission filter to the corpus before similarity is scored — which changes the query, not the prompt.
A system that only answers questions is straightforward to ship. One that updates a record, sends a message or approves a request needs a shadow mode where it proposes and a human disposes, guardrails on the actions it can take at all, and an evaluation set that tells you whether it is getting better or just getting faster.
Proof
Two systems you can open right now. No form, no demo request.
policy.compcodesolutions.com
Sign in as three different employees and ask the same question. You get correctly different answers, because access control is enforced when the search runs rather than by filtering results afterwards. The retrieval code, the visibility rule and the test that proves an employee cannot reach a supervisor-only document are all public.
ai.regression.compcodesolutions.com
Browser tests that survive a redesign. Selectors are resolved by intent rather than by brittle CSS paths, so a renamed class does not turn into a morning of red builds. Runs in CI and reports what actually broke instead of what merely moved.
Engagements
Fixed scope, written down before anything begins. If the honest answer is that you don’t need one of these, I will tell you.
Where to start, and what will stop you. A review of the systems, the data and the permissions model, ending in a written recommendation you can act on without me.
Details →Retrieval over your real documents, with permissions that match your org chart and are enforced at the query rather than in the results.
Details →Automated browser coverage in CI for a product that changes often, built so a redesign doesn’t invalidate the suite.
Details →A scoped assistant inside a product you already ship — with guardrails, a shadow mode, and an evaluation set so you can see whether it is working.
Details →Who you are working with
CompCode Solutions is a registered practice in Bengaluru. It is deliberately small: you work directly with the person doing the engineering, there is no account manager in the middle, and nothing is handed to someone more junior after the contract is signed.
The background is fifteen years of enterprise software — Wells Fargo, Moody’s, HCL — and the last several years on AI systems that reach real users rather than stopping at a prototype. That mix is the whole point: the interesting problems in production AI are permissions, failure modes and evaluation, and those are ordinary engineering problems that reward having shipped things before.
If an engagement is not a good fit, saying so early costs both of us one call and saves you a quarter.
Writing
A twenty-five minute call. Bring the thing that isn’t working. If it isn’t worth paying for, I’ll say so on the call.