> ## Documentation Index
> Fetch the complete documentation index at: https://docs.luklak.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Ground Layer: Governance and Access Control

> A detailed guide to Luklak's Ground Layer, covering the 3 Tiers of Governance: system-wide Business Privileges, component-level Item Access, and granular Permission Schemes.

## The Foundation of Your Headquarters

<Note>
  As introduced in our [Platform Architecture overview](/platform), the **Ground Layer** provides the secure, governed foundation upon which your entire digital headquarters is built. It is the land and the law.
</Note>

<Info>
  This layer consists of a sophisticated, **3-tier governance model** that gives you precise control over who can see and do what. To understand it, think of your Luklak instance as a secure corporate campus where a user must pass through three distinct security checks to perform any action.
</Info>

\[Image Placeholder: A diagram showing a funnel with three sections labeled Tier 1, Tier 2, and Tier 3. An icon of a user is at the top, passing through each layer to reach an icon of an Object at the bottom.]

***

## Tier 1: Business Privilege - Your Campus ID Badge

This is the highest level of access. A user's **Business Privilege** determines if they are allowed onto the campus at all and defines their maximum potential authority. It's the first gate everyone must pass.

<CardGroup cols={2}>
  <Card title="Owner" icon="crown" iconType="duotone">
    The highest level. Manages billing and holds all Admin privileges. Can add or remove everyone, including Admins.
  </Card>

  <Card title="Admin" icon="user-gear" iconType="duotone">
    Can configure everything in the system, from users to global settings, but cannot remove the Owner.
  </Card>

  <Card title="App Manager" icon="map" iconType="duotone">
    A specialized role that can design and manage `📋 Functions`.
  </Card>

  <Card title="Member" icon="user" iconType="duotone">
    The standard privilege for most users to work within `⏹️ Spaces`.
  </Card>
</CardGroup>

***

## Tier 2: Item Access - The Keys to the Buildings

Once a user is on campus, **Item Access Control** determines which specific "buildings" they can enter. These "Items" are high-level containers like a `📋 Function`, a `Dashboard`, or a `⏹️ Space`. This tier answers the question: "Which workspaces and tools can you access?"

***

## Tier 3: Permission Schemes - The Rules Inside the Building

Once inside a specific building (like a `⏹️ Space`), the **Permission Scheme** governs what a user can actually *do* to the contents (the `🧊 Objects`) within. This is the most granular layer of control.

Implementing Tier 3 security is a two-step process that separates **design** from **operation**:

### Step 1: Design the Scheme (in the `Function`)

First, as an architect, you design the `Permission Scheme` as a blueprint inside a `📋 Function`. This is where you create your `Roles` (e.g., "Project Lead," "Team Member") and define the rules: which `Role` can perform which `Action` (e.g., `View Object`, `Edit Object`, `Delete Object`). This scheme is automatically inherited by every `⏹️ Space` created from this `Function`, ensuring a consistent set of rules.

### Step 2: Assign Roles (in the `Space`)

Then, in a live `⏹️ Space`, a manager assigns specific `Users` or `Groups` to the `Roles` that were defined in the `Function`'s blueprint. This provides ultimate flexibility: the rules are standardized, but *who plays which role* can be different for each individual `Space`.

## Putting It All Together: A Governance Matrix Example

<Expandable title="Putting It All Together: A Governance Matrix Example">
  <Info>
    A user must have the correct permissions at **all three tiers** to perform an action. Let's use a real-world scenario to illustrate this.

    **Scenario:** A highly confidential "Project Phoenix" M\&A `⏹️ Space`.
  </Info>

  ### The Setup: A Tier-by-Tier Configuration

  We will configure the permissions for four users: Alice (CEO), Bob (Project Manager), Carol (Legal Team), and David (Sales Team).

  **Tier 1 Setup: Business Privileges**\
  First, we confirm each user's system-wide "Campus ID Badge."

  | User      | Business Privilege | Description                   |
  | :-------- | :----------------- | :---------------------------- |
  | **Alice** | `Admin`            | Has high-level system power.  |
  | **Bob**   | `Member`           | Standard user for daily work. |
  | **Carol** | `Member`           | Standard user for daily work. |
  | **David** | `Member`           | Standard user for daily work. |

  **Tier 2 Setup: Item Access on the 'Project Phoenix' ⏹️ Space**
  Next, we grant the "Keys to the Building" for this specific `Space`.

  | User or Group              | Assigned Item Access Level | Reason                                                                                         |
  | :------------------------- | :------------------------- | :--------------------------------------------------------------------------------------------- |
  | **Executive Team (Alice)** | `Admin`                    | The executive team needs full control over the `Space`'s settings and access list.             |
  | **Bob**                    | `Manager`                  | As the project manager, Bob needs to manage the `Space`'s content but not its access controls. |
  | **M\&A Legal (Carol)**     | `Member`                   | The legal team needs to view and use the `Space` but not change its settings.                  |

  <Warning>
    Note: David and the Sales Team are not on this list, so they have no key to this Space.
  </Warning>

  **Tier 3 Setup: Role Assignment within the 'Project Phoenix' ⏹️ Space**
  Finally, we assign the users who can get inside a specific "Role" which was designed in the `Permission Scheme` of the source `Function`.

  | User      | Assigned Role   | (Role is defined in the `Permission Scheme` for this `Space`)             |
  | :-------- | :-------------- | :------------------------------------------------------------------------ |
  | **Bob**   | `Project Lead`  | This Role has permissions to `Create`, `Edit`, and `Delete` `🧊 Objects`. |
  | **Carol** | `Legal Counsel` | This Role has permissions to `View` `🧊 Objects` and `Add Comments` only. |

  <Warning>
    Note: Alice was not assigned a specific Role for working with the data inside.
  </Warning>

  ### The Outcome

  <Note>
    This table shows the **effective permissions** for each user, demonstrating how the tiers combine to prevent security loopholes.
  </Note>

  | User      | Tier 1 (Privilege) | Tier 2 (Can Enter Space?)               | Tier 3 (Role Inside) | Final Result: Can they...                                                                                                                                                                                              |
  | :-------- | :----------------- | :-------------------------------------- | :------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | **Alice** | `Admin`            | ✅ **Yes** (as part of `Executive Team`) | *(No Role assigned)* | **Can:** Manage the `Space` settings, add/remove members (as `Admin` of the Item).<br />**Cannot:** See `🧊 Objects` inside, unless a `Permission Scheme` rule grants access to Admins.                                |
  | **Bob**   | `Member`           | ✅ **Yes** (as `Manager` of the Item)    | `Project Lead`       | **Can:** Enter the `Space`, manage `Space` content, and perform all actions granted to the `Project Lead` Role (e.g., `Create`, `Edit`, `Delete` `🧊 Objects`).<br />**Cannot:** Change the `Space`'s access controls. |
  | **Carol** | `Member`           | ✅ **Yes** (as part of `M&A Legal`)      | `Legal Counsel`      | **Can:** Enter the `Space` and perform actions granted to the `Legal Counsel` Role (e.g., `View` `🧊 Objects`, `Add Comments`).<br />**Cannot:** `Delete` `🧊 Objects` if the Role doesn't permit it.                  |
  | **David** | `Member`           | ❌ **No**                                | *(Not Applicable)*   | **Cannot do anything.** Even though David is a `Member` of the business, he was never granted `Item Access` to this specific `Space`. The security model stops him at Tier 2.                                          |
</Expandable>

## What's Next?

You now have a comprehensive understanding of the 3-tier governance model. To learn how to start building your solutions on this secure foundation, explore the Build Layer.

* [**Ready to build? Explore the Build Layer in Detail**](/en/02-platform/platform-overview/the-build-layer)
* [**Go back to the main overview: Platform Architecture**](/en/02-platform/platform-overview)