Event Engine develops Rondayvoo, our website platform for event organisers.
Rondayvoo includes Rondayvoo Builder, our visual website-building environment, with AI-assisted tools that help users create, edit and manage website content more efficiently.
Rondayvoo is built on WordPress, which provides the underlying content management, authentication and permissions framework. Throughout this document, we refer primarily to Rondayvoo rather than repeating the underlying WordPress technology except where it is relevant to a specific safeguard.
Our approach to AI is based on a simple principle:
The AI model is not the security boundary.
The AI can only work through a defined set of Rondayvoo tools. Those tools apply their own permissions, validation and workflow rules before anything is changed.
This page explains what our AI can do, what it cannot do, and where those safeguards sit.
How Rondayvoo Builder AI works
At a high level:
User request → AI model → approved Rondayvoo tool → permissions and validation → Rondayvoo
The AI is not given unrestricted access to the underlying platform, database or server.
Instead, it is provided with a predefined collection of tools for specific jobs such as:
- reading page structure
- creating pages
- adding or editing page content
- working with Rondayvoo Builder modules
- creating templates
- working with design systems
- staging changes to existing pages
- publishing changes when requested
Each tool has a defined purpose and expected input.
The model cannot simply invent a new server command and have Rondayvoo execute it.
Current AI capability breakdown
At the time of writing, the Rondayvoo Builder AI toolset contains:
| Type | Number of tools |
|---|---|
| Read | 22 |
| Create | 6 |
| Modify | 12 |
| Delete | 1 |
The single delete operation relates to discarding an AI staging draft. It does not delete the original live page.
The AI does not currently have a general-purpose “delete page” tool.
Existing user permissions still apply
Using AI does not give somebody additional privileges within Rondayvoo.
Every AI tool operates in the context of the currently logged-in user and the permissions associated with that account.
Where an operation relates to an existing page or item, Rondayvoo checks whether that user has permission to edit it.
Publishing also respects the user’s publishing permissions.
This means the AI cannot elevate itself to a more privileged account or edit content that the person using it is not authorised to edit.
These permission checks are ultimately enforced through the underlying WordPress permissions framework used by Rondayvoo.
Published pages are protected through staging
One of the most important safeguards in Rondayvoo Builder is the way existing live pages are edited.
When the AI modifies a published page, normal editing tools do not immediately overwrite the live version.
Instead, Rondayvoo creates a staging draft.
The AI works against that draft while the original page remains unchanged.
This applies to operations including:
- rebuilding an existing page
- updating the full page
- editing individual page content
- changing page-level assets
- assigning a design system
The staging draft is linked to the original page.
Only a separate publishing operation copies those changes back to the live page.
We check whether the live page has changed
A page might be edited by somebody else while an AI-assisted change is being prepared.
Rondayvoo records the state of the original page when the staging draft is created.
Before staged changes are published, that state is checked again.
If the original page has changed in the meantime, Rondayvoo can reject the publish operation rather than silently overwriting somebody else’s work.
This protects against competing edits and unexpected changes occurring while AI-assisted work is in progress.
Destructive changes have additional safeguards
Some AI operations are potentially more significant than ordinary content edits.
For example, rebuilding an existing page could replace large amounts of existing content.
Rondayvoo Builder therefore includes technical checks around operations such as:
- replacing existing page content
- rebuilding reusable components
- proceeding when content has changed unexpectedly
- publishing a staged page
- modifying shared design-system resources
Some operations require explicit acknowledgement flags before the server will continue.
These safeguards are enforced by the application rather than simply being suggestions in the AI prompt.
However, we also want to be precise about what those safeguards currently mean.
Some acknowledgement flags can presently be supplied by the AI itself. They do not yet represent a separate independently verified human confirmation.
What the AI cannot directly access
Rondayvoo Builder does not expose general server or infrastructure access to the AI.
The current toolset does not provide the AI with the ability to:
- execute PHP
- execute shell commands
- run arbitrary SQL
- access arbitrary database tables
- read or write arbitrary server files
- install plugins or platform extensions
- install themes
- create or manage users
- change user roles
- alter platform configuration
- call arbitrary REST endpoints
- execute arbitrary server commands
The AI can only use the tools that Event Engine has explicitly made available within Rondayvoo.
External requests are restricted
The AI does not receive a general-purpose HTTP tool.
One specific capability allows an image to be downloaded from a supplied URL into the site’s media library.
That operation is separately permission checked and includes protections around the type of content being downloaded and the destination being contacted.
Calls to configured AI providers are also made as part of operating the AI service itself.
CSS and JavaScript authoring
Rondayvoo Builder is a website creation environment, so authorised users may deliberately use AI to create CSS or JavaScript as part of a website design.
For example, AI-assisted tools can work with:
- page-level CSS
- page-level JavaScript
- design-system CSS
- design-system JavaScript
- styles and scripts included within supported page structures
This is intentionally different from giving the AI server-side code execution.
Client-side website code is part of Rondayvoo Builder’s authoring capability, while PHP, shell, filesystem and arbitrary database execution are not exposed.
A predefined toolset
The AI operates through a registered collection of Rondayvoo abilities.
Each ability defines the input it expects.
Requests then pass through several layers, including:
- the AI choosing an available tool
- tool input and schema validation
- user permission checks
- resource-specific checks
- Rondayvoo business rules
- staging and content-state checks where applicable
- the underlying platform operation
An invalid tool name cannot simply become a server action.
Invalid parameters, inaccessible content and failed permission checks are rejected rather than being treated as instructions to work around.
Shared and site-wide content
Rondayvoo Builder also supports resources that can affect more than one page.
For example:
- design systems
- reusable templates
- site-wide layouts
- location and display rules
The AI can work with some of these resources where the logged-in user has permission.
Because these can have broader effects than editing an individual page, we treat them as higher-impact capabilities.
Design-system modifications use permission and content-state checks, but some global operations currently rely partly on the model following instructions to obtain confirmation from the user.
This is an area where we intend to continue strengthening the technical approval boundary.
Publishing and human approval
The AI is instructed that publishing is an explicit action.
Our AI tool descriptions tell the model that it should only publish when the user has clearly asked for content to go live.
Publishing still passes through user permissions, staging validation and source-change protection.
However, we want to be transparent about the distinction between permission and confirmation.
At present, there is not an additional server-side confirmation token or independent approval control that proves the human explicitly confirmed immediately before every AI publishing operation.
The model is instructed to obtain that confirmation, but this part of the safeguard currently relies on model behaviour.
We therefore do not claim that human confirmation before publishing is technically impossible for an AI model to bypass.
This is different from permissions, staging protection and resource validation, which are enforced independently of the model.
Auditability
Rondayvoo currently records several pieces of information that can help investigate AI activity.
These include:
- the user associated with an AI conversation
- the page or item being worked on
- conversation history
- AI provider and model
- token usage
- timestamps
- content revisions where enabled
- staging drafts and their relationship with live pages
However, we do not currently claim that every individual AI tool invocation is recorded in a dedicated immutable audit log.
There is not presently a single chronological log containing every tool name, parameter and resulting change.
This is another area we can strengthen as the system evolves.
Capability and safeguard summary
| Capability | AI access | Safeguard |
|---|---|---|
| Read page structure | Yes | User and resource permissions |
| Read page content | Yes | User and resource permissions |
| Create a new page | Yes | Created as draft by default |
| Edit a draft | Yes | Permissions and validation |
| Edit a published page | Yes | Changes routed to staging |
| Replace an existing page layout | Yes | Staging, content checks and acknowledgement safeguards |
| Add or edit Rondayvoo Builder content | Yes | Defined tools and schemas |
| Add or edit page CSS | Yes | Defined authoring tools |
| Add or edit page JavaScript | Yes | Defined authoring tools |
| Work with design systems | Yes | Permissions and content-state checks |
| Create reusable templates | Yes | Permission and platform checks |
| Work with site-wide layouts | Restricted | Only where available and authorised |
| Upload an image from a URL | Yes | Upload permission, restricted fetch and MIME checks |
| Publish a page | Yes | Permission, staging and drift checks; human confirmation is currently model-instructed |
| Delete a live page | No direct AI tool | Not exposed |
| Discard an AI staging draft | Yes | Must be a valid linked staging draft |
| Manage users | No | Not exposed |
| Change roles or permissions | No | Not exposed |
| Install plugins or extensions | No | Not exposed |
| Run arbitrary SQL | No | Not exposed |
| Access arbitrary database tables | No | Not exposed |
| Access the server filesystem | No | Not exposed |
| Execute shell commands | No | Not exposed |
| Execute PHP | No | Not exposed |
| Call arbitrary REST endpoints | No | Not exposed |
| Act as a more privileged user | No | Existing user permissions still apply |
Model behaviour is not our only defence
Large language models can misunderstand instructions, make mistakes and occasionally behave unpredictably.
For that reason, Event Engine does not rely solely on telling an AI model to “be careful”.
Where possible, important boundaries exist outside the model itself.
These include:
- a predefined toolset
- tool schemas
- existing user permissions
- per-resource permission checks
- content-state hashes
- staging of published-page edits
- source-change detection before publishing
- restricted external fetching
- platform availability and compatibility checks
This means an AI request is still subject to application rules even after the model decides that it wants to perform an action.
Where we are still improving
Transparency also means being clear about safeguards that we believe can be made stronger.
Two areas in particular remain on our roadmap.
Stronger human confirmation
Publishing and some shared or global changes currently rely partly on the AI being instructed to obtain explicit user approval.
We would like higher-impact operations to have an additional application-level confirmation mechanism that the AI cannot satisfy by itself.
Dedicated AI action auditing
We already retain useful context through conversations, revisions, staging and usage records.
A dedicated tool-level audit trail would make it easier to see exactly which AI action took place, when it occurred and what it changed.
Our approach
Our aim is not to claim that AI is infallible.
It isn’t.
Instead, we believe AI should operate inside clearly defined boundaries.
For Rondayvoo Builder that means:
The user retains their existing permissions.
The AI receives specific tools rather than unrestricted system access.
Published content is staged before normal AI edits replace the live version.
Important requests are independently checked by Rondayvoo and its underlying permissions framework.
Infrastructure-level capabilities such as shell, SQL, filesystem and user administration are not exposed to the model.
And where a safeguard currently depends on model behaviour rather than technical enforcement, we believe it is better to say so openly.
AI within Rondayvoo will continue to evolve, and we intend to keep this page updated as its capabilities and safeguards develop.