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.
As introduced in our Platform Architecture overview, the Ground Layer provides the secure, governed foundation upon which your entire digital headquarters is built. It is the land and the law.
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.
[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.]
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.
Owner
The highest level. Manages billing and holds all Admin privileges. Can add or remove everyone, including Admins.
Admin
Can configure everything in the system, from users to global settings, but cannot remove the Owner.
App Manager
A specialized role that can design and manage 📋 Functions.
Member
The standard privilege for most users to work within ⏹️ Spaces.
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:
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.
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
Show Putting It All Together: A Governance Matrix Example
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.
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.
Note: David and the Sales Team are not on this list, so they have no key to this Space.
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.
Note: Alice was not assigned a specific Role for working with the data inside.
This table shows the effective permissions for each user, demonstrating how the tiers combine to prevent security loopholes.
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). 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). 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). 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.
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.
