Part 1 said the creative work carves the Organizer into shape. This part is about where that work actually happens. Ceruleo gives you three containers for an idea, and choosing between them is the most consequential judgment call in the platform - not because any choice is fatal, but because each container gives an idea a different kind of life:
- A Spark keeps an idea alive without commitment. It has an owner and a discussion, and it costs nothing to keep.
- A Sandbox gives an idea room to become something - explorations, versioned assets, reviews, and eventually approved work that publishes onto the Organizer.
- A Rally gives a question a burst of collective attention - a short, focused push where contributions pile up fast and end in decisions and action items.
The one-line test: Spark to keep it, Sandbox to make it, Rally to decide it.
The pipeline (the spine of the whole platform)
The journey from nothing to built runs: spark → sandbox → asset → approved → published onto an element. Every stage is a deliberate gate, and each gate exists to protect the stage before it.
1. Sparks - the front porch. A company Spark lives in the company-wide pool, visible to company users: it is where "what if the entry was a curtain of light you part with your hands?" waits for its moment. A project Spark lives inside a sandbox on a specific project - same idea-shape, but already attached to context.
2. Conversion - the commitment. Converting a spark moves it into a sandbox - into an existing one, or into a brand-new sandbox created for it. Understand the mechanics: conversion is a move, not a copy. The spark's discussion and lineage travel with it; there is no residual "idea copy" left on the porch. That is deliberate - the pipeline never forks an idea into two lives that drift apart.
3. Sandboxes - the making. A sandbox is a workroom, not a filing cabinet: concept studies, dead ends, competing options, and eventually assets - the documents, files, and models that accumulate versions as thinking hardens. Assets carry a status ladder (draft → concept → development → not-for-construction → approved) that tells everyone how much weight a document can bear. Nothing in a sandbox is placed on the Organizer, and that is a feature: the map only learns about winners (Part 1).
4. Review - the pressure test. When an asset version needs judgment rather than chatter, request a review: named reviewers, a due date, real tasks on each reviewer's plate, and recorded decisions.
5. Approval and publish - the graduation. Approving an asset freezes its review cycle - approved means done arguing. Publishing then pushes it out of the workroom onto the Organizer, and publishing has two preconditions: the asset must be approved, and it must have an element to land on - the forcing function from Part 1 that keeps the map growing. Publish to everyone, or to a specific audience when the work is sensitive.
From that moment, the element dashboard - not the sandbox - is where the project reads the current truth.
Rallies - the other container
A rally is not a slower sandbox; it is a different physics. Sandboxes hold work products that converge over weeks. A rally holds a question - "which arch finish?", "how do we sequence load-in?" - and burns hot for days: typed contributions (updates, questions, blockers, ideas, feedback), a brief that frames the problem, action items that become real tasks on real plates, and a close when the question is answered.
Link rallies to the elements they concern. A rally about the Portal Arch finish belongs on Portal Arch, where its outcome will still be findable in month six. The platform will never force the link - some rallies genuinely concern the whole project - but an unlinked rally about a specific thing is the orphaned-rally anti-pattern: the discussion happens, the decision gets made, and the element's dashboard never heard about it. (The create dialog offers element linking, unlinked rallies wear a quiet "No element" tag, and element dashboards list their linked rallies - the tooling nudges; the judgment is yours.)
The scenario
The Aurora Light Curtain spark sat on Halcyon's porch until the Meridian Hall opportunity made it real. Morgan converted it into a fresh sandbox on the new project - Entry Portal Concepts - where Jules's arch studies and curtain mockups took over. When the direction won, the elements got their names (Part 1), and the concept sketch that started it all remains in the sandbox as version history: the idea's paper trail from porch to pavilion.
Meanwhile the Wayfinding Package sandbox matured fastest: sign family approved, published onto Monolith Signs and Directional Blades. The Main Stage Design sandbox shows the middle of the road - the LED wall layout at Rev B, an open review with Dana and Jules on the hook, procurement waiting on their verdict.
Two cautionary exhibits live in the same project. The Kinetic Petal Canopy spark has sat on the porch for months, owned but untouched - the spark-that-never-transitions anti-pattern. Sparks are cheap to keep, and that is exactly the danger: a porch full of ideas nobody will ever convert or archive stops being a pipeline and becomes a graveyard that buries the good ones. Review the porch on a rhythm; convert what's ready, archive what isn't, and let owners feel ownership. And the Load-in logistics rally is running with no element link - defensible as a whole-project question, but if it settles anything about the dock or the crates' route through the North Entry, that decision will be invisible from every element it touched.
Decision rules - quick reference
- Spark vs Sandbox vs Rally: keep it / make it / decide it.
- Company spark vs project spark: "should we ever?" vs "should we, here?" - and project sparks are visible to sandbox collaborators, including externals.
- Convert into an existing sandbox vs a new one: existing when the idea feeds work already moving; new when the idea is the work. A sandbox with two unrelated ideas in it will version them into each other's way.
- Comments vs review request: shaping vs verdict. Reviews create tasks and records; comments create conversation.
- Approve, then publish; element first: approval ends the argument, publish needs a landing spot, audience defaults to everyone - narrow it only when the work is genuinely sensitive, because private publishes fragment the "current truth" the element dashboard exists to provide.
⚙ Make it yours - the pipeline's vocabulary is configurable at the company level: spark categories, asset categories and types (company settings → template families) shape the create dialogs your team sees. Per-project, the studio permission grid supports a dedicated reviewer level - collaborators who can judge work without editing it - and each sandbox can allow or withhold collaborator versioning. Privacy toggles exist on sparks, sandboxes, and rallies for work that needs a smaller room. The gates are fixed - approve before publish, element before publish, conversion moves - because they are the scaffolding; everything else bends to how your team works.
Troubleshooting
- "I converted a spark and now I can't find it in Sparks." Working as designed - conversion moves. Its whole history is inside the destination sandbox.
- "I need to publish but the button won't let me." Check the two preconditions in order: is the asset approved? Does it have an element? If the element doesn't exist yet, that is Part 1's signal - the tree just fell behind a decision. Add the element, then publish.
- "A review is stuck on someone who never responds." Reviews are tasks on their plate - chase the task, or replace the reviewer. Do not route around a stuck review with an informal "looks fine" comment; the record will say the version was never judged.
- "We keep debating in a sandbox's comments and going in circles." That is a rally trying to happen. Frame the question in a brief, set the room, and burn it down in a week - then bring the answer back to the sandbox as the next version.
Mechanics - creating sparks and sandboxes, the convert flow, versioning, review requests, publish and audiences, rally contributions and closing are covered click-by-click in the in-app Field Guide → Studio / Workshop / Sparks.
Where you fit
⚑ Company users only - the company Sparks pool. If you joined by project invitation (client, vendor, partner), you will not see Sparks in your sidebar; your window into the pipeline starts at the sandboxes you collaborate on. Project sparks inside those sandboxes are visible to you - that is deliberate, so the room you are in shows its own history.
Your day-to-day judgment calls in this part: pitch ideas as sparks instead of sitting on them; when your concept wins in a sandbox, promote its name to the Organizer and version the asset forward; answer review requests as tasks with deadlines, not as reading material; and when you open a rally, link it to its elements at creation - future-you is the person who benefits.