Guru knows a card ages, and it says so
Guru exists so that a company's knowledge stays verified. A card has an owner, someone responsible for reviewing it, and a state saying whether it still holds or whether it is due for another look. That is why support teams and sales teams file their answers there instead of leaving them in a folder of documents.
An AI plugged into that base has no reason to guess that state. It reads a text, it answers, and it answers the same way whether the card was reviewed yesterday or abandoned three years ago. On a knowledge base, that is the point everything else depends on, and connecting more sources does not settle it.
The verification state arrives with the card
The connector does not rank your cards by freshness and hides none of them. It does something simpler, and something you can check in how the product behaves. A card's text is written into your Kastel together with the name of its collection, the verification state as Guru returns it, and its last modification date. The AI receiving the card therefore receives, in the same movement, what it needs to know what the card is worth.
The connector does not know the labels of your states either. It passes along the value Guru hands it, with no threshold, no score and no ranking invented on our side. A card due for another round of verification says so in Guru's own terms, and your internal convention stays the reference.
What does not come in, on the other hand, is the people. A card's owner, its collaborators and whoever verified it are never read. The verification state enters your Kastel without the name of the person answering for it, and that is the same call we make on the other knowledge sources, from the Confluence connector to ClickUp documents.
Read access is rebuilt backwards, collection by collection
Guru puts permissions on the collection holding a card rather than on the card. And its interface does not say who is allowed to read a collection. It says the reverse, group by group, which collections that group can open. The information has to be turned around to get the only thing that matters here, namely the list of people who can read each collection.
The connector redoes that work on every pass. It walks the groups to the last one, the collections of each group, the members of each group, then the grants given to individuals directly. Every list is followed to its final page. The collection then takes the department its readers share, and the card takes the scope of its collection.
Rebuilding the map rather than remembering it has a direct consequence. Removing someone from a group in Guru removes their access on the next pass, with nobody on our side having to remember it, and it is also the only way to catch a reshare, since changing a group's membership does not move the date of the cards concerned.
Doubt always closes the door. A member list that comes back incomplete puts the collections it touches on hold. An incident whose blast radius cannot be bounded, a truncated list of groups for instance, puts every collection on hold. And an audience spread across more than one department is never resolved by picking the most likely one, it waits for an administrator's decision.
What a card lets in
The connector reads one thing inside a card, its body, and it cleans that body before writing it.
Cleaning the text has a precise reason. A support card often holds an access link to a tool, a client's address or a colleague's mention. Those three things are replaced by a neutral marker before the card is written, including when the address was encoded in the page's markup rather than written out in the clear.
The questions a knowledge base raises
Here are four precise objections, with the answer the connector allows us to give, and nothing more.
Can an AI answer me from a card that is out of date?
Yes, if that card is still live in Guru and the person the AI is working for is allowed to read its collection. The connector does not judge the content of a card. What it does is pass along the verification state and the last modification date with the text, so that the answer can take them into account instead of assuming.
Who decides that a collection belongs to a given department?
Your permissions in Guru, and nothing else. A collection's department is the one its readers share, once groups have been expanded into real people. There is no Kastel setting that opens a collection to a department, and a collection whose readers span two departments waits for an administrator instead of being assigned by default.
What happens when a collection's audience could not be established?
The cards in that collection enter your Kastel and are read by nobody. They are assigned to no department, they show up in no answer, and they wait for an administrator to decide. A permission map that cannot be rebuilt produces that outcome for all of your collections at once, which shows immediately and is fixed in Guru.
Can an AI create or correct a card in Guru?
No. The connector exposes no method to create, edit or archive anything, and it talks to a single server, Guru's own. A plugged-in AI can tell you what a card holds and flag that it is due for another look. Correcting it stays a human gesture, in Guru.
What the Guru connector does not do
It verifies nothing on your behalf. A card's state is the one Guru gives, passed along as is. If your cards are not kept up to date in Guru, your Kastel will faithfully pass along cards that are not, with the marker that goes with them. No review and no quality scoring happen on our side.
It cannot be finer than a collection. Guru exposes no per-card audience, so two cards in the same collection have exactly the same readership in your Kastel. A sensitive card filed in a widely open collection will be readable by the whole department that collection belongs to, and the only place to fix that is Guru.
Cleaning the text loses useful information. A link to an internal procedure becomes a neutral marker, so an AI reading the card will not be able to hand that link back to you. We prefer that loss to letting addresses and access links out into a shared context, and it is a debatable call that we write down rather than keep quiet.
It does not erase a card you archive. An archived card stops coming in from the next pass onwards, and the copy already absorbed is marked as gone at the source, then kept. It stays readable by the same people as before until an administrator erases it. That is the point to know when a card is withdrawn because it had become wrong, since archiving it is not enough to make it disappear from your Kastel.
See what your Kastel makes of knowledge you have already written.
The product page shows how your Kastel is built, what it keeps from the sources you connect, and what an AI receives from it depending on the person it is working for.
See the product
