The tidy version was wrong
This entry is reconstructed from the accepted Dream Atlas build history through July 30, 2026, plus the repository authorities for the surfaces involved. The sequence is supported. The exact first public Dream Atlas activation date is not, and neither is the exact day the Event Producer custom domain became active.
The tidy version of Dream Atlas would have put everything in one place: one repository, one runtime, one deployment, fewer boundaries to explain.
It would also have been wrong.
Dream Atlas ended up coordinating three different kinds of surface:
- an indexable public archive and evidence layer;
- a noindex project workspace with a renderer;
- an independently owned, mutable public demo.
They shared a narrative. They did not share an authority boundary.
That distinction became the architecture.
The public site owned the relationship
The public Dream Atlas runtime had one job: make the work legible to a stranger. It could present project casefiles, logs, processes, screenshots, decisions, and limits. It could explain how certain projects belonged to the same body of work.
It did not need to own either product's implementation to do that.
This sounds obvious now. It was less obvious when the site was still becoming a coherent system and every related surface looked like something that could be mounted beneath the same shell. Shared branding made consolidation feel natural. Shared ownership made it feel harmless.
But a casefile and the product it describes answer different questions.
- The casefile asks: What was built, why was it built this way, and what evidence can a visitor inspect?
- The product repository asks: What code, configuration, provider state, and release process make this thing work?
Those are related questions. They are not the same source of truth.
The protected /console route became a small test of the same idea. Dream Atlas uses operator-console language because it helps organise the archive and because I like the atmosphere. That did not make /console a real dashboard, login page, redirect, or mount point for private tools. Keeping the fictional console separate from operational capability stopped the frame from manufacturing a fact.
The public site could own the narrative relationship without absorbing every runtime behind it.
The renderer exposed the real boundary
The Liminal Tarot workspace made the problem concrete because the renderer failed in a very particular way.
It could look healthy at the root and break when mounted under /renderer/. Runtime paths assumed they started at /. Assets and JSON were not packaged reproducibly. Worse, a request could return 200 and still be wrong because fallback HTML arrived where an image or data file should have been.
A green status code was not proof. It was barely a clue.
There were two convenient fixes available: absorb the renderer into the public Dream Atlas repository and make the public site carry its build requirements, or hide the path problem behind rewrites and provider configuration.
Neither would have answered the more important question: who was the renderer for?
It was not public evidence. It was a production workspace for generating and checking Liminal Tarot content. Its audience, lifecycle, failure modes, and future sensitivity triggers were different from the public archive. Once that was clear, the packaging defect and the product boundary became the same problem.
The repository contract that followed made the renderer base-aware, packaged its runtime assets and data as reproducible build inputs, and assembled it beneath a static mission-control shell. The workspace had its own repository and deployment contract. Its exposure model was deliberately narrow: unlisted, noindex, no sitemap, static output, no API routes, no database, no upload or write endpoints, and no authentication.
That last point needs to stay explicit. The workspace was noindex, not private in the security sense. Anyone with the URL could reach it. Search exclusion controlled discovery; it did not control access.
Words like internal, private, and noindex had been doing too much work. They are not synonyms.
The trigger for authentication was not the existence of a console-shaped interface. It was the arrival of sensitive content or consequential capability: private data, credentials, client material, uploads, database writes, or production actions. Adding login chrome before that point would have created another system to maintain without protecting anything that actually needed protection.
Audience determined indexing. Capability and sensitivity determined access control. Implementation responsibility determined repository ownership.
One word could not do all three jobs.
The public demo was the opposite case
Event Producer looked related for a different reason. It was intended as a public demonstration surface, and it was mutable. Its application boundary included a frontend, backend state, saved casefiles, deterministic engines, model-provider seams, and human approval gates. The repository described a capstone prototype, not production SaaS, and left production authentication and several external actions deferred.
That made it unsuitable for the Liminal workspace's exposure model. It also made it unsuitable for absorption into the public Dream Atlas runtime.
Dream Atlas could host the public casefile and explain why the demo mattered. The hosted-demo repository still had to own the application, its build contract, its backend configuration, and its deployment truth.
The shared namespace did not change that. A subdomain can show relationship. It cannot transfer operational responsibility by punctuation.
That distinction mattered when a manually deployed Event Producer artifact worked while the Git-integrated path did not. The automated build started from a repository root without the required tracked contract and produced an empty deployment. A later merge could replace a working demo with a 404.
The manual artifact and the reproducible deployment path were two different properties. The first had been treated as evidence for the second.
It wasn't.
Dream Atlas could link to the demo. It could not guarantee the demo's root build, backend state, provider configuration, or promotion status from the public-site repository. The implementation owner needed its own tracked, self-applying contract and its own verification.
The visible edges made accountability clearer.
The six questions I use now
The boundary model that came out of this is not “one repository per surface.” That would be a neat rule and a terrible one.
I compare six contracts instead.
Audience
Who is the primary user, and what are they trying to do?
A casefile serves a stranger evaluating the work. A renderer serves the person producing assets. A public demo serves someone trying the product. A single surface can technically serve all three and still be a bad product for each of them.
Indexing
Should the surface appear in search, navigation, and the sitemap?
Indexing is not a small SEO switch. It signals intended audience and permanence. Putting a noindex workspace into public navigation crosses a product boundary even when every route still works.
Capability
What is the strongest thing the surface can do?
Read-only narrative, static tooling, data access, saved state, uploads, messages, payments, and production actions carry very different obligations. The most consequential capability sets the access-control and failure-handling requirement.
Source ownership
Which repository or system owns implementation truth?
A public casefile may describe another product. It should not quietly become that product's source of truth. Description is not ownership.
Deployment truth
Which project, configuration, and provider record determine whether the surface works?
Source complete, merged, deployed, promoted, domain attached, and production verified are separate states. A working artifact makes that distinction easy to overlook.
Failure radius
What breaks together?
A renderer build should not block the public archive. A demo backend failure should not replace the narrative site. Separation is useful when it keeps one failure local and makes the responsible owner obvious.
My working rule is simple enough to remember:
Keep surfaces together when they share audience, indexing posture, capability, source ownership, deployment truth, and failure radius. Separate them when those contracts materially diverge.
“Materially” is doing important work there. Cosmetic differences do not deserve new repositories. Some single differences do. Authentication, payments, regulated artifacts, frozen submissions, or independently owned deployment paths can be decisive on their own.
Separation has a maintenance bill
More boundaries create more orientation work. There are more repositories to document, more deployments to verify, more links that can go stale, and more chances for a README to describe a surface that has already changed.
Dream Atlas hit that too. A workspace route advanced faster than its dated orientation material. The runtime and the document briefly told different stories.
The fix is not to collapse everything back into one repository. It is to make each boundary legible:
- one owner per concern;
- one local authority for the relationship;
- no duplicate claims of implementation ownership;
- explicit indexing and linking rules;
- separate provider verification;
- a public layer that admits when an off-site surface is stale or unavailable.
The narrative layer can still make the system feel coherent. Stable project identities, casefiles, related domains, and a shared visual language do that work. Coherence does not require pretending the products share a codebase or lifecycle.
My conclusion is narrower: In this system, the boundary was the product decision.
// End of transmission — ZYANE