The reason behind a change lives in a merge request discussion
Code says what the software does. It almost never says why it does it that way. That reason lives in a merge request discussion, in the exchange where somebody proposed something else and the team settled it in three comments.
A new joiner picking up that module will ask the question out loud, or take again the detour the team decided to avoid eighteen months earlier. An AI that has read those discussions can answer by quoting the original exchange.
It is also one of the most disorderly sources in an engineering organisation. A decision can live in a private project shared by two people, in an internal project, or in a public repository, and those three cases cannot be handled the same way.
GitLab has three visibility levels, and only one describes a bounded audience
A GitLab project is private, internal or public. A private project has a member list, so it has an audience you can name. A public project is open to the whole internet. In between, an internal project is visible to every signed-in account on the instance, and since this version of the connector talks only to gitlab.com, that means every account on gitlab.com.
The connector treats internal and public the same way. As soon as a project is not private, it does not even look at its member list. Its issues and merge requests are filed in no department and wait for an administrator's decision.
That choice surprises people, because from a distance an internal project looks like a company project. That is exactly the trap. Internal does not mean internal to you, and a connector that treated it as your organisation would file into your departments content whose real audience has nothing to do with them.
A merge request's audience is not written on the merge request
Nothing on an issue says who is entitled to read it. Its project says so, and the project itself inherits from its group. The connector therefore adds two lists together, the project's direct members and the members of the group holding it, inherited along the group hierarchy above it.
A project sitting in someone's personal namespace inherits nothing, and its audience is limited to its direct members. A project sitting under a group, with parent groups above it, also takes in all of their members. That is how a merge request reviewed by three people can have a far wider audience.
Once the addition is done, the rule is strict. If all those people belong to a single department of your organisation, the project's issues are filed in that department. If they span two departments, nobody reads them until an administrator decides. If a single address matches nobody known in your organisation, the outcome is the same.
None of those lists is read halfway. When a page of members announces more results the connector cannot reach, or when a group refuses to expand into people, the whole project goes on hold. The connector never completes a permission list with an assumption. Every hold leaves a trace, and the decision that lifts it leaves another one, which is the work Kastel calls governing your knowledge.
Two lists read, everything else ignored
The connector calls only two endpoints per project. The rest of GitLab is not discarded afterwards, it is never called at all.
Visibility and member lists serve only to compute read access. They are not written into your Kastel, so a connected AI never receives the directory of your projects, only the text of the issues it is entitled to.
What engineering teams ask first
Does our code come into your Kastel?
No. The connector calls two lists per project, issues and merge requests, and keeps their title, description and comments. Code, branches, file diffs, the project wiki and repository files are not read, and there is no setting that makes them read.
Can a connected AI comment on, approve or close a merge request?
No. The transport in use exposes reads only. No create, update, delete or comment method exists in this connector, so the question is not settled at the level of your token's permissions, it is closed one level below.
If I remove someone from a group, when is that taken into account?
At the next reconciliation pass, not the same second. GitLab does not change an issue's date when its project's permissions change, so no change feed can report that removal. For that reason the connector recomputes the scope of every record it tracks, at a regular cadence.
Our token cannot see the members of some projects. What happens?
Nothing is guessed. When GitLab refuses to say who a project's members are, its issues wait for an administrator and the pass carries on with the other projects. A revoked token, on the other hand, stops the whole pass with an explicit error rather than suggesting everything went fine. The other sources in the connector catalogue apply the same discipline in the vocabulary of their own tool.
If we delete an issue, does it disappear from your Kastel?
No, not on its own. It remains in your Kastel with a gone-at-the-source note, readable by the people who were already reading it, until an administrator's erasure decision. That is how every Kastel connector behaves, and it is better known before you connect anything.
What this connector does not do
This version talks to gitlab.com only. A GitLab installed on your own infrastructure is not read by this connector as it stands, and adding it is decided deployment by deployment. If your GitLab is self-managed, that is the first thing to tell us, because the answer changes the conversation.
It does not work inside GitLab. No issue is opened, no merge request is commented on, approved or merged. A connected AI can tell you what a discussion holds, it cannot reply in your place.
Reading comments is not guaranteed to be exhaustive. When the pagination of a very long thread can no longer be followed, the connector stops where it is instead of failing the pass. The record therefore arrives with fewer comments, never with more, and that gap is not flagged in what the AI receives.
It does not understand your way of working. Labels, milestones, boards and time tracking are not read, so nothing your team built around GitLab to run itself comes into your Kastel. This connector keeps decision text, not your tooling. A source exposing two contradictory permission layers, such as Jira, raises a different problem, and its own page tells that story.
See what Kastel does with what it reads.
The product page shows how your Kastel files what comes in, who can query it, and what an external AI receives when it asks for something. It is the shortest starting point if you are seriously evaluating the question.
See the product
