Hi @sarahgabsi-py - yes, this is a reasonable fit for a chatbot knowledge base, with a couple of important caveats on file types and on what "roles" means here.

File types

Graphify ingests a folder and builds one queryable knowledge graph. Of the formats you listed:

• Markdown (.md, .mdx, .txt, .rst, .html) - fully supported
• PDF - supported (install with pip install graphifyy[pdf])
• JSON - supported (parsed structurally)
• CSV - not recognized directly today. The closest paths are converting to .xlsx (supported via graphifyy[office]) or to markdown first. If first-class CSV matters to you it is worth opening an issue - it is a small extractor to add.

So for a docs-style knowledge base of markdown + PDF + JSON you are well covered; CSV needs a conversion step for now.

How it works for a chatbot

The typical pattern: point graphify at your corpus, it produces graph.json (entities + relationships) plus a report, and your chatbot queries the graph for context instead of doing flat text search. It gives the bot structured retrieval - "what relates to X", "what does this policy reference" - rather than raw chunks. You query it with graphify query "..." or via the MCP server (graphifyy[mcp]) if your bot framework speaks MCP.

Per-role subfolders (client / admin / manager)

The part to be clear about: graphify has no built-in access control or role-based permissions. It will not enforce that a "client" cannot see "admin" content. What you can do is one of:

1. Separate graphs per role - keep docs/client/, docs/admin/, docs/manager/ and run graphify on each folder independently, producing one graph.json per role. Your chatbot loads only the graph matching the logged-in user's role. This is the clean approach and gives real isolation, because admin content never enters the client graph.
2. One graph, filter at query time - build a single graph over everything and have your app restrict which nodes the bot may surface. Simpler to build, but the access boundary lives entirely in your application code, not in graphify.

For a customer-care product where clients must not see internal/admin material I would strongly recommend approach #1 (separate graphs) - isolation by construction beats filtering you have to get right every time.

Happy to point you at the query/MCP setup once you decide on the structure.