Trust & operations
Choosing a platform to hold your organisation’s content is a question of trust before it is a question of features. You are deciding who guards the door, what happens on a bad day, and whether the people who use your site can actually use it. This section answers those questions plainly, for the people who have to sign off on them.
CTXR earns that trust the same way it does everything else: structurally, not by good intentions. The protections described here are not settings you remember to switch on. They are consequences of how the platform is built, which means they hold even when nobody is watching.
Five ideas run through everything that follows.
Isolation is the architecture. Every tenant is a hard boundary — its own data, its own domain, its own actors — and that holds for more than spaces. The platform also serves the management modules (platform, account, onboard) and the account layer, and each is its own isolated directory resolved from its subdomain. There is no shared database to leak across them, and no cross-tenant query that could ever return someone else’s content. What this section describes for a space is true for every tenant on the platform.
Authorization is layered. Authentication, permissions, and property protection are independent gates checked at every point where data changes. Defeating one does not get you past the others.
Privacy is built in, then made your responsibility where it has to be. CTXR holds almost no personal data of its own and tracks nobody. Where the law assigns duties to you as the data controller, this section says so clearly rather than implying the platform covers them.
Everything is recoverable. Because content lives as plain files and everything else is derived from it, recovery is usually a command rather than a procedure. Code is in version control; content is backed up; a corrupted index is regenerated, not restored.
The platform is accountable and accessible. Three separate logs record what happened, a health endpoint reports how the system is doing, and the editing interface meets accessibility standards out of the box.
The pages in this section cover each of these in turn:
- Anonymous by default — the most basic use asks for nothing; identity only when it buys something.
- Edge routing — what the edge will and won’t serve, the same way for every domain (spaces and the management modules alike): rendered pages, allow-listed assets, the API — never source, config, or the raw graph.
- The security model — isolation as architecture: every tenant — a space, an account, a management module — is its own boundary; plus layered authorization, content integrity, and API hardening.
- Separate sign-ins — account, onboard, and each space sign in the same way but never share a session; collaborating in a space needs no platform account, and onboarding is the one place the islands meet.
- Access & permissions — passwordless sign-in, the nine atomic rights, presets, and the one actor model — the same across spaces, accounts, and platform admins.
- Privacy and GDPR — who is the controller, who is the processor, and what that means for you.
- Reliability and recovery — backups, concurrency, self-maintenance, and the crisis playbook.
- Observability — the three logs, health checks, and metrics.
- Accessibility — what the platform guarantees and what your space owns.