Roadmap

Where CTXR is heading. This page is the what and the why — the technical detail lives in the reading journeys once something ships.

A note on how we work: features are designed on paper first, then built in focused rounds, and documented after the code proves the design. That means this roadmap describes intent, not dates. Things ship when they’re right, and occasionally the order changes because building one thing teaches us something about another.

Now

Developer access — push to deploy. Every space gets its own repository for templates and assets. A developer clones it, works locally, and pushes; the platform checks the work at the gate and puts it live atomically — with history and rollback built in, because that’s what version control is for. Content, configuration and uploads stay out of reach by design. Why: agencies and freelancers should be able to build a space’s look and feel without ever being able to touch its data — and a space owner should be able to grant that access with one key, and revoke it just as easily.

Public submissions. Visitors can contribute content — reviews first — through forms that are quiet about their own defences: submissions arrive as drafts, and nothing appears until an editor approves it. This has just landed and is rolling out across spaces and content types. Why: community content is valuable, but only when moderation is the default rather than an afterthought.

Local development kit. Pull a snapshot of a space to your own machine, preview it locally with the same rendering rules as production, and push your template work back through the same checked gate. Why: visual work needs a fast feedback loop — edit, refresh, edit — and that loop shouldn’t run through a live site.

An assistant that does more than explain. The assistant already answers questions about the platform and takes you anywhere in the workspace. Next it learns to act: creating content step by step, showing you a node’s form right in the conversation, and — with an AI connection — understanding free-form language instead of fixed commands. Why: everything in a space can be done through the interface, but new people need help finding their way. A guide beats a manual.

The graph, visible. A space is a graph — nodes connected by meaning — but until now you could only see it one list or one page at a time. A graph view shows the whole: which content clusters together, what the backbones are, what floats loose at the edge. Why: insight. Seeing the shape of your content answers questions no list can — and it’s simply a pleasure to look at.

Starting from something real. New spaces will begin as a copy of a curated example space — real pages, real collections, real templates — instead of an empty shell. Why: an empty canvas explains nothing. A working example shows how the pieces fit, and editing something real is faster than inventing from zero.

Events and schedules. New Schema.org types are coming to the content vocabulary: Event for things that happen — an opening, a guided walk, a festival — and Schedule for things that repeat, with days, times and exceptions. Places and routes answer where; events answer when. Why: much of what a space describes has a time dimension, and time is data too. And once content knows when it happens, time-based notifications (see below) have something real to announce.

Later

Notifications. The mobile experience is already installable, offline- capable and location-aware; server-sent Web Push is the missing piece, so a space can reach its followers when something new is nearby or worth knowing.

Multilingual, properly. Language becomes a first-class property of content, managed by the platform the way URLs and authorship already are — with translation flows built on top.

Deeper semantic intelligence. The platform already stores content as Schema.org; increasingly it will understand it too, deriving behaviour from the schema itself so that new types bring their own mechanics along.

The account layer. Accounts today carry your identity across spaces; next they grow into a place of your own — folders, collections, and the things you follow, kept up to date by the spaces that publish them.

Recently landed

Term sets and tags — structured tagging built on Schema.org’s DefinedTerm. Spaces define their own vocabularies; every set is its own namespace, so the same word can mean different things in different sets — that’s meaning, not a conflict. Editors tag content straight from the picker (or mint a new term inline, with a nudge when it already exists), sets and terms live in the content browser like any other content, and the terms travel into the published data where search engines read them.
Public review submissions with honeypot-and-moderation defences, live on the demo space.
A space-aware assistant — every space’s workspace has an assistant that knows its way around: ask it what anything is or where anything lives, and it explains or takes you there.
The media model — a reusable media library with watch pages, thumbnails and a sitemap feed that search engines read directly.
Push-to-deploy infrastructure for developer access, tested end-to-end and awaiting its first external space.

Something missing that you’d want to see? The FAQ covers what exists today; for everything else, we’re listening.