SUPERMARIO.WORKS LTD · Universal Builder System

08 — Macrosection 04 — Ownership, Users & Permissions

Universal Accommodation Data Model v0.1

APPROVED WORKING DRAFT

Architecture Constitution v1.0: FROZEN · Architecture Consensus: 100% AGREEMENT · Implementation Design: OPEN

Purpose

This macrosection defines how Users are associated with Accommodation objects and how ownership, management roles and permissions are represented within the Universal Builder System.

A User must be able to manage one or more Accommodation objects, while an Accommodation must be able to authorise more than one User without duplicating the Accommodation or transferring its universal identity.

Core principle: ownership and management are relations between Users and managed objects. They are not fixed fields embedded permanently inside an Accommodation.

A — User Identity

The User represents a person or authorised account capable of interacting with protected functions of the Universal Builder System.

Technical Key	Label	Description	Data Type	Required	Universal / Territorial	Public / Private	Editable By	Plan	Validation	Relations	Multilingual	Searchable	Filterable	API-ready
`object_uid`	Universal User ID	Immutable universal identity of the User.	UUID / String	YES	Universal	Internal	System / Admin	All	Unique, immutable	User Relations	No	No	No	Yes
`public_id`	Public User ID	Human-readable system identifier where a readable User reference is required.	String	YES	Universal	Internal	System / Admin	All	Unique	User	No	Yes	No	Yes
`account_email`	Account Email	Email used for account identity, authentication and system communication.	Email	YES	Universal	Private	User / Admin	All	Valid email; uniqueness policy	User Account	No	Internal	No	Yes
`display_name`	Display Name	Name used where an authorised User identity needs to be displayed within the management interface.	String	YES	Universal	Private / Controlled	User / Admin	All	Non-empty	User	Yes	Internal	No	Yes
`account_status`	Account Status	Operational status of the User account.	Controlled Vocabulary	YES	Universal	Internal	System / Admin	All	Controlled values	User Account	No	No	Yes	Yes

Authentication credentials, passwords, tokens and provider-specific authentication data are implementation concerns and must not become portable business identity fields in the Accommodation Data Model.

B — User ↔ Accommodation Relation

User access to an Accommodation is represented through an explicit relationship rather than through a fixed owner field.

USER │ │ HAS_ROLE ▼ ACCOMMODATION

This permits one User to manage multiple Accommodation objects and one Accommodation to have multiple authorised Users.

User A ├── Primary Owner → Hotel One ├── Manager → Hotel Two └── Editor → Cottage Three Hotel One ├── Primary Owner → User A ├── Manager → User B └── Contributor → User C

C — Accommodation Role Assignment

Technical Key	Label	Description	Data Type	Required	Universal / Territorial	Public / Private	Editable By	Plan	Validation	Relations	Multilingual	Searchable	Filterable	API-ready
`user_role`	User Role	Role assigned to a User in relation to a specific managed Accommodation.	Controlled Vocabulary	YES	Universal	Internal	Authorised Manager / Admin	All	Controlled role vocabulary	User ↔ Accommodation	Labels only	No	Yes	Yes
`role_status`	Role Status	Operational state of the User-to-Accommodation role assignment.	Controlled Vocabulary	YES	Universal	Internal	Authorised Manager / Admin	All	Controlled values	User ↔ Accommodation	No	No	Yes	Yes
`assigned_at`	Assigned At	Timestamp recording when the role assignment became effective.	DateTime	YES	Universal	Internal	System	All	Valid timestamp	User ↔ Accommodation	No	No	No	Yes

D — Controlled Role Vocabulary

Primary Owner

Principal authorised User responsible for the Accommodation presence. The Primary Owner has the highest business-level authority over the managed Accommodation, subject to ecosystem administration and governance.

Manager

User authorised to manage substantial operational aspects of the Accommodation presence without becoming its Primary Owner.

Editor

User authorised to create and modify permitted Accommodation content without receiving ownership or full management authority.

Contributor

User with limited contribution permissions. Contributor actions may be restricted or require review before becoming public.

Admin

System or ecosystem administrator with governance and support authority. Admin is not automatically the commercial owner of an Accommodation.

Role does not equal ownership of the Universal Builder System. A Primary Owner controls the authorised business presence; SUPERMARIO.WORKS LTD and the relevant ecosystem retain governance of the platform, architecture and publication environment.

E — Permissions

Roles provide understandable business identities, while permissions define the actual actions that may be performed.

The architecture must therefore avoid permanently embedding every possible permission directly into the Accommodation object.

ROLE ↓ PERMISSION SET ↓ ALLOWED ACTION Example: Manager ↓ edit_accommodation manage_media manage_inventory manage_contacts manage_permitted_campaigns view_permitted_enquiries

Definitive permission keys and role-to-permission mappings will be established during the User System implementation and validated against the completed Data Model.

F — User Experience & Platform Abstraction

Participating Users interact with the territorial ecosystem, not with the underlying technical components.

PUBLIC / USER EXPERIENCE OXFORDSHIRE.world ↓ Create Account / Login ↓ My OXFORDSHIRE ↓ My Accommodation ↓ Hotel One ↓ Manage authorised functions

The underlying implementation may use WordPress, Fluent Forms, Astra, Storage Adapters and other technical components, but those components are not the product identity presented to participating Users.

Users must not require access to the standard WordPress administration interface in order to create and manage their Accommodation presence.

G — Builder Input Principle

During implementation, authorised Users will provide and update information through interfaces presented as part of the territorial ecosystem.

Fluent Forms may operate as an Input Adapter for registration, submission and editing workflows, but Fluent Forms does not own the canonical Accommodation Data Model.

USER ↓ OXFORDSHIRE.world interface ↓ Input Adapter ↓ Universal Builder System ↓ Canonical Data ↓ Presentation ↓ OXFORDSHIRE.world/[public-path]

The User supplies authorised data. The ecosystem controls architecture, presentation, publication standards and the public experience.

H — Creation & Management Flow

The architecture must support the future implementation of a native Accommodation creation and management experience.

Create Account ↓ Login ↓ Create Accommodation ↓ Select Accommodation Type ↓ Complete required information ↓ Add Location / Address ↓ Add Content / Inventory / Amenities ↓ Add Media ↓ Configure Contacts ↓ Select / Apply Membership capabilities ↓ Preview ↓ Submit for Review ↓ Approval ↓ Publish inside the territorial ecosystem

This macrosection does not define the final Builder screens or form layout. Those interfaces will be implemented after the Accommodation Data Model reaches v1.0.

I — Ownership Changes

Changes in business management or authorised personnel must not require creation of a new Accommodation object.

HOTEL ONE object_uid = unchanged Primary Owner: User A ↓ authorised change User B Accommodation identity remains unchanged.

Ownership and management changes therefore modify relations and permissions, not the universal identity of the Accommodation.

J — Separation from Membership

User authority and commercial Membership are separate concepts.

USER ROLE Who may manage the Accommodation? ≠ ECOSYSTEM MEMBERSHIP Where and under which capabilities is the Accommodation participating?

Changing FREE, BASIC or PREMIUM must not change who owns the Accommodation or create a new Accommodation object.

K — Separation from Public Contact

User Account information must remain separate from the public communication channels defined in Macrosection 03.

ACCOUNT EMAIL Private authentication / system communication ≠ ACCOMMODATION CONTACT EMAIL Public or controlled visitor enquiries

The same real-world email address may be used for both purposes if the authorised User chooses to do so, but the two data responsibilities remain separate in the architecture.

L — Macrosection Rules

04-R01 — User identity is independent from Accommodation identity.
04-R02 — A User may hold authorised roles for multiple Accommodation objects.
04-R03 — An Accommodation may have multiple authorised Users.
04-R04 — Primary Owner, Manager, Editor, Contributor and Admin form the initial controlled role vocabulary.
04-R05 — Roles and permissions must remain distinguishable concepts.
04-R06 — Ownership or management changes must not alter the Accommodation universal identity.
04-R07 — User roles are separate from Ecosystem Membership and commercial plans.
04-R08 — User Account contact data is separate from public Accommodation contact data.
04-R09 — Participating Users must interact with an ecosystem-native management experience rather than requiring access to the standard WordPress backend.
04-R10 — WordPress User IDs or other implementation-specific account identifiers must not become universal identity.
04-R11 — Fluent Forms may provide User-facing input workflows but remains an Adapter rather than the canonical User or Accommodation model.
04-R12 — Publication authority remains subject to ecosystem governance, workflow and review rules.

Practical Result

A participating business can create an account inside the territorial ecosystem, create or become authorised to manage an Accommodation, invite or authorise additional people with appropriate roles, and manage permitted parts of its native ecosystem presence without receiving access to the underlying technical administration.

The same User architecture can later operate within OXFORDSHIRE.world, Puglia.world and other territorial ecosystems without redefining Accommodation identity or hard-coding WordPress-specific ownership rules.