Gatework Studio Developer Manual.

1. Framework overview

Gatework Studio is a Next.js-based admin framework for multi-tenant AI and knowledge applications. The codebase provides reusable structures for authentication, authorization, module routing, navigation, JSON forms, knowledge data, source management, chatbot configuration, and document processing.

The framework is licensed per project and acts as the starting point for custom software. Each project can extend the base architecture with its own modules, data models, integrations, and user interfaces.

2. Tech stack

3. Project structure

The codebase separates framework core, application routing, and domain modules. This structure should remain recognizable in client projects so custom work stays isolated and maintainable.

src/app       Next.js routes, layouts, and API routes
src/core      Auth, registry, navigation, layout, forms, actions, utilities
src/modules   Domain modules with pages, configs, and schemas
src/db        Drizzle schema and database-adjacent types
trigger       Trigger.dev tasks for pipeline workflows
docs          Technical and product documentation

4. Module system

Every visible module page consists of a page file and a config file. The config describes metadata such as title, description, icon, ordering, navigation visibility, permissions, and disabled state.

src/modules/<module>/pages/<page>/
  page.tsx
  config.ts

Pages use the shared module layout so titles, descriptions, and page structure remain consistent across the admin interface.

5. Registry, routing, and tenant context

Gatework Studio uses a central module registry as the source for routing, dashboard tiles, and sidebar navigation. Runtime file-system scans are avoided; module visibility is explicit and generated from module configuration.

• /modules redirects to the first allowed tenant or a no-access state.
• /[tenantId]/modules shows the tenant-scoped dashboard.
• /[tenantId]/modules/<route> loads a tenant-scoped module page.

6. Authentication and authorization

Clerk is the external authentication source. Roles and tenant access are not trusted from Clerk claims; they are resolved through the internal database model.

7. JSON form pattern

Many admin areas use JSON Schema Forms so structured data can be edited with relatively little custom UI code. The pattern supports single-record forms, multi-entry forms, server-side load/save/list/delete actions, optional AJV validation, and consistent toast feedback.

8. AI admin domains

9. Document pipeline

The document pipeline processes source content in stages. Website and form content can be normalized into documents, then prepared as chunks for retrieval workflows.

Sources -> Documents -> Document Chunks -> Retrieval / Chatbot Use

Hash values support traceability and help avoid unnecessary repeated processing. Trigger.dev tasks structure recurring processing steps.

10. Extension rules

• Create visible areas as modules with a page and config.
• Do not duplicate navigation or routing manually; route through the registry.
• Check tenant access server-side for protected operations.
• Do not derive roles from external auth claims.
• Use existing JSON form patterns for JSON-based admin data.
• Keep project customization isolated from the framework core where possible.