> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/start-here/how-qore-is-organized.md). # Accounts, Projects, Spaces Accounts, projects, the two spaces, and what each Operator can reach. Qore uses accounts, projects, and two spaces to separate daily creation from account-wide governance. Use this overview to choose the correct boundary and surface before you begin. ### At a glance | Concept | Use it for | | ------------------ | ------------------------------------------------------------------ | | **Account** | Billing, access, governance, and account-wide controls. | | **Project** | Apps, agents, knowledge bases, design systems, and shared context. | | **Console** | Building and running work in the selected project. | | **Control Center** | Monitoring and governing the full account. | {% hint style="info" %} **Key rule:** Console is project-scoped. Control Center is account-scoped. Control Center screens can still filter their data by project. {% endhint %} ### Organizations, accounts, and projects An **organization** is Qore's top-level boundary — one deployment for a customer. It holds org-wide roles, brands, the plan and model catalog, and one or more **accounts**. Org Settings manages the organization's accounts and brands. Most customers see a single account and rarely need to think above that level, so the rest of this page focuses on account and project — see the [Glossary](/start-here/glossary.md#organization) for the organization entry. An **account** is a business unit inside the organization, not the organization itself. Billing and credits, users (by membership), roles, teams, API keys, and governance controls belong to the account. Find **Account** in the left sidebar. Users with one account see that account. Users with multiple accounts can switch accounts from the account panel. A **project** groups your apps, agents, knowledge bases, and design systems. Projects also define **context**. Every conversation in a project can use its resources. Create a project for unrelated work. This keeps its context separate from other work. Assets stay available within their project. For example, you can attach one knowledge base to multiple agents. You can also reuse a design system in a new app. | Boundary | Owns | Why it matters | | -------- | ------------------------------------------------- | ------------------------------------------ | | Account | Billing, access, and governance | These controls apply across every project. | | Project | Apps, agents, knowledge bases, and design systems | Resources and context remain isolated. | A new user receives a starter project named after them. It gives them an immediate place to build. {% hint style="info" %} **Terminology change:** Earlier releases used **workspace**. It now means **project**. Older screenshots and release notes may still use the earlier term. {% endhint %} ### Console and Control Center A switcher beside the platform logo moves between **Console** and **Control Center**. {% columns %} {% column %} #### Console **Console** is your daily project workspace. Build apps and agents, create knowledge bases, and run what you built. Console uses the project selected in its header. It also shows the active account. {% endcolumn %} {% column %} #### Control Center **Control Center** provides account-wide administration and monitoring. Use it for observability, quality, guardrails, audit, cost control, and access management. It opens at the account level. Use each screen’s project filter to narrow its data. {% endcolumn %} {% endcolumns %} | If you need to… | Use | Scope | | --------------------------------------------- | -------------- | ---------------------------------------- | | Build or run an app, agent, or knowledge base | Console | Selected project | | Check project resources | Console | Selected project | | Review activity, quality, cost, or access | Control Center | Account, with optional project filtering | | Manage users and roles | Control Center | Account | {% hint style="info" %} Console combined the earlier **Build** and **Run** spaces. Both activities now happen in one project workspace. {% endhint %} Control Center does not have a global project selection. Analytics, Audit Trails, logs, Reports, and Credit Usage support project filters within the screen. ### Operators and resource scope Each space has an **Operator**. An Operator coordinates specialized agents with shared conversational context. | | Console Operator | Governance Operator | | ------------------- | --------------------------------- | -------------------------------------- | | **Space** | Console | Control Center | | **Reach** | Selected project | Whole account | | **Focus** | Apps, agents, and knowledge bases | Activity, cost, access, and guardrails | | **Change handling** | Dispatches work immediately | Stages changes for approval | The Console Operator can create a knowledge base, app, or agent. It creates the resource in the current project. You can test it in the same chat. The Console Operator can also search or crawl a URL. It can turn the result into a knowledge base or use it to create a design system. The Governance Operator answers account-wide questions. Ask about published apps, recently created agents, or credit use. It can narrow a question to one project without changing Control Center’s account scope. {% hint style="info" %} Use the Governance Operator for oversight. It stages proposed changes and waits for your approval. {% endhint %} #### Module scope | Module | Scoped to | Practical effect | | --------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Design Systems** | Project | Apps in the project inherit the design system. | | **Apps, agents, knowledge bases** | Project | They use the project context. | | **Store** | Account | Published solutions are visible across the account. | | **Observability** | Account | Screens can filter results by project. | | **Evaluators** | Account | An evaluator is attached to agents across the account, not created per project. | | **Cost Control** | Organization, account, and agent | Credit limits exist at all three levels — an organization-wide cap, per-account caps and alerts, and a per-agent credit guardrail — and the strictest applicable limit wins. | | **Admin** | Account | Roles apply across every project. Roles are held per account membership: one person can hold different roles in different accounts. | | **AI Gateway** | Account | Model policy applies to all account activity. | | **Govern** | Account | Controls apply across the account. | | **Console Operator** | Project | It works and builds in the selected project. | | **Governance Operator** | Account | It supports account-wide questions and project filtering. | {% hint style="warning" %} The scope of **Integrations Hub** and **Custom Skills** is not confirmed. Do not treat either scope as documented until verified. {% endhint %} {% hint style="info" %} **This table grows.** Each module gets a row here as it is documented, and states its own scope in its **At a glance** — [Design systems](/console/design-systems.md) is the model. Where a module page and this table disagree, **fix the table**: the module page is closer to the screen. {% endhint %} ### Known limitations * Control Center does not show an app or agent’s originating project. * Switching accounts does not preserve the selected project. ### Publishing and access Apps have an in-product publishing flow. Agent publishing is currently handled through backend processes. All spaces are currently open to everyone. A future RBAC release will scope access by role and permission. ### Quick choice {% tabs %} {% tab title="I need to build" %} Use **Console**. Select the project where the work belongs. Create and run apps, agents, and knowledge bases there. {% endtab %} {% tab title="I need to govern" %} Use **Control Center**. Review account activity, quality, costs, access, and controls. Filter by project when available. {% endtab %} {% endtabs %} ### Related resources {% content-ref url="/pages/6712483fe92d4497b985e3f00b6d0737aa398200" %} [Console](/start-here/console.md) {% endcontent-ref %} {% content-ref url="/pages/807cab861e090edd0ce825909db3db1b28f73799" %} [Control Center](/start-here/control-center.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.uptiq.ai/start-here/how-qore-is-organized.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.