> ## Documentation Index > Fetch the complete documentation index at: https://docs.kentron.ai/llms.txt > Use this file to discover all available pages before exploring further. # What Kentron Core provides > The shared services every other section runs on — identity, organizations and workspaces, the receipt store, the runtime and its job queue, browser sync, keys and tokens. Core is the platform the other six sections run on. Your account, the organization that owns your data, the workspaces that scope connections, the database that holds every receipt, the runtime that carries out background work, and the sync layer that keeps the browser current all live here. Come to this tab to set up an account or an organization, to understand how a run is actually executed, or to configure, deploy and operate Receipt yourself. New to Kentron? Start with [What Kentron is](/introduction). **Four Core surfaces look functional but are not wired up in this release.** Plan entitlements gate nothing — every feature check resolves to allowed, on every plan; what genuinely differs is the seat count, the metered usage budget and the one-time signup credit. The organization **Security** page — **Domains**, **Single Sign-On**, **Directory Provisioning** — is a placeholder with disabled buttons and no implementation behind it. The organization **Analytics & Insights** page's three extraction toggles are disabled and cannot be turned on. Two-factor authentication is verified at sign-in for an account that already has it enrolled, but no screen enrols one, and passkeys exist only as unused interface strings. [Getting help](/core/getting-help) keeps the Core list; the enforcement matrix on [what Guard enforces](/guard/overview) covers the surfaces other tabs own. ## How to read this tab The groups follow the order you meet them: get an account and an organization, then the architecture behind a run, then the interfaces you can build against, then everything you need to configure, host and operate a deployment. Signing up and signing in, organizations and workspaces, members and roles, seats and billing. The five runtime roles and the service gateway, receipts and streams, jobs, and the Factory engine. The runtime's HTTP, SSE and WebSocket surface, the TypeScript SDK, and authoring an agent. Every environment variable the platform reads, what it defaults to, and what breaks without it. Local development, self-hosting, migrations, the integration provider, deploying, health checks. What works today, what is not available yet, and where to report a problem. Each card opens the first page of its group. The rest of the tab follows from there: * **Accounts and organizations** — [organizations and workspaces](/core/organizations-and-workspaces) tells the two tenancy layers apart; [members and roles](/core/members-and-roles) covers invitations, seats and what each role may do; [billing and plans](/core/billing-and-plans) covers the three things a plan actually changes. * **Architecture** — [receipts and streams](/core/receipts-and-streams) is the hash-chained record every table is rebuilt from; [jobs and durable execution](/core/jobs-and-durable-execution) is how background work survives a worker dying; [the Factory engine](/core/factory-engine) is how an objective becomes a task graph running inside a disposable computer. * **APIs and SDK** — [the TypeScript SDK](/core/typescript-sdk) is the action contract a receipt-native agent is written against; [authoring an agent](/core/authoring-agents) scaffolds, runs and traces one from a checkout. * **Run it yourself** — [local development troubleshooting](/core/local-development-troubleshooting) for a change that did not take effect; [self-hosting](/core/self-hosting) for the build-time switch that changes identity, billing and telemetry; [Postgres, migrations and the sync publication](/core/database-and-migrations) for the store itself; [running the integration provider](/core/integrations-provider) for the service Receipt Connect cannot work without; [deploying](/core/deploying) for the two topologies and the release guards; [health and observability](/core/health-and-observability) for the probes, logs and traces. ## The shared services Each row is one service Core provides and the parts of the product that depend on it. When something in another tab behaves in a way you did not expect, this table usually points at the Core page that explains it. | Service | What it is | Who depends on it | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | Accounts and sessions | Email and password accounts, up to ten sessions side by side in one browser and each revocable on its own, and organization membership with owner, admin and member roles | Chat, files, settings, usage and billing screens; the Slack and Teams install claim pages; the CLI's browser sign-in | | Organizations and workspaces | An organization owns members, plan and policy, and each person can create up to ten of them. A workspace is the authorization boundary for connections; every organization gets a **Default** workspace that cannot be deleted | The MCP Gateway and Workspaces pages, the runtime's Connect routes, the Slack app, `receipt workspace` | | Receipt store | Hash-chained receipt streams in one Postgres database, addressed by `ZERO_UPSTREAM_DB`. The streams are the source of truth; every table the rest of the product reads is a projection derived from them | Chat turns, gateway `/connect/call` actions, Factory runs, policy and skill changes, the Agent Registry | | Runtime and job queue | One runtime image started in five roles. Work moves from the API role to a driver and then to a worker over durable promises, under leases and heartbeats, with recovery loops that redrive anything that stalls | Background runs started from chat, Slack and Teams; Factory; the CLI's Factory commands | | Browser sync | Postgres logical replication feeds a sync service that pushes 29 projection and application tables to the browser over a websocket. A table missing from the publication breaks sync for every client, not just one view | Every live view in the application | | Encryption keys | Two 32-byte base64 keys: `BYOK_ENCRYPTION_KEY_B64` for provider keys and `RECEIPT_CONNECTION_ENCRYPTION_KEY_B64` for Receipt Connect connection references. Both must stay stable once data is encrypted with them — there is no re-encryption path | Bring-your-own-key settings, gateway connections | | Receipt Connect tokens | Tokens signed with `RECEIPT_CONNECT_JWT_SECRET`, falling back to `BETTER_AUTH_SECRET`, always bound to one organization and one workspace, and carrying some combination of `connect:read`, `connect:write` and `connect:credential`. The default lifetime is 12 hours; which scopes and lifetime a token actually gets depend on the surface that minted it | CLI sign-in, MCP clients, the Slack and Teams adapters, Factory workers inside a sandbox | | Model credential resolution | Which credential pays for a model call: your organization's or workspace's own provider key when one covers the model, otherwise the deployment's platform OpenAI key from `OPENAI_API_KEY`. There is no platform-funded route for any other provider | Web chat, Factory runs, Slack; Teams, which runs on the organization key only | ## How it fits ```mermaid theme={null} flowchart TB subgraph surfaces [Where people work] Web[Web chat] Slack[Slack app] Teams[Teams app] CLI[Receipt CLI] MCPc[MCP clients] end subgraph core [Kentron Core] Auth[Identity and organizations] Receipts[(Receipt store: hash-chained streams in Postgres)] Runtime[Receipt runtime: jobs, Resonate, workers] Sync[Zero browser sync] end Gateway[LLM Gateway
model policy and credentials] MCPG[MCP Gateway
workspaces, connections, allowlists, /connect/mcp] Factory[Factory
objectives, tasks, OpenSandbox + Codex] Catalog[Catalog
Agent Registry, connectors, skills, Org Brain] Guard[Guard
policies, guardrails, access control] Nango[(Nango: provider OAuth and credentials)] Providers[(Model providers)] Web --> Auth Slack --> Runtime Teams --> Runtime CLI --> MCPG MCPc --> MCPG Web --> Gateway --> Providers Web --> Factory Runtime --> Factory Factory --> MCPG MCPG --> Nango Factory --> Receipts MCPG --> Receipts Gateway --> Receipts Catalog --> Receipts Guard -. applies to .-> Gateway Guard -. applies to .-> MCPG Receipts --> Sync --> Web ``` Every surface enters Core somewhere. The web app resolves your session and organization before it does anything else. Slack and Teams resolve a Receipt user through an install claim link, then call the runtime's channel-neutral routes, which are served on the private runtime network and carry the resolved user and organization in the request body rather than a bearer token. The CLI and other MCP clients hold nothing but a Connect token. Factory workers ask the gateway for what a call needs at the moment of the call: provider credentials stay in Nango, and MCP client configs and sandboxes never contain them. Everything those paths do lands back in one place. Chat turns, gateway actions, Factory runs, and policy, skill and Agent Registry changes all append receipts, and the sync layer carries the resulting projections back to your browser — which is why a task list, a run's progress and a replay are views of one stream rather than separate records. One gap is worth knowing before you rely on that trail: calls made through the MCP bridge are not yet recorded. [Receipts and audit](/guard/receipts-and-audit) accounts for what does and does not write one. The runtime answers `/healthz` and `/readyz`; the web application answers `/health`. Readiness, not liveness, is the gate worth alerting on — see [health and observability](/core/health-and-observability). Next step: [create your account and sign in](/core/your-account).