Case study 05 · Self-directed · AI-native editorial system · 2026
Giving AI a system to think and build with.
SYX already governed how a page gets built. Nothing governed what it should say. ATLAS is a second system, generated separately, that carries the rules of one domain — digital media — and hands them to SYX to execute. This case is the test of whether two systems can be stacked without either one losing its grip.
In 30 seconds
- The tension
- SYX governed how a page gets built. Nothing governed what it should say.
- My call
- A second system, ATLAS, generated separately: six knowledge domains and ten motion patterns that hand their rules to SYX.
- The evidence
- Two opposite registers, ATELIER and OBSIDIANA, sharing 32 semantic tokens and 3 primitives. Counted on 22 August 2026.
- What changed
- The stack holds two registers on one semantic API. The 17 MB and 57 MB of media are the cost I would not accept in production.
- Role
- System designer
- Mental model
- ATLAS · editorial intent
- Execution
- SYX · governed build
- System
- SCSS · GSAP · ScrollTrigger · Lenis
Act 01
The test I set myself
The starting point
SYX governs how a page is built. Nothing governed what it should say.
SYX is my design system: tokens, accessibility, architecture, a validator that fails the build. It answers how something is built. It holds no opinion about editorial hierarchy, about the distance between a portrait and a dossier, about when a page should feel slow. I wanted to know whether that second body of rules could be generated separately — as its own system, with its own vocabulary — and whether SYX would take orders from it. ATLAS is that second system. Digital media is the domain I used to test it.
Success criteria
Two opposite registers, one system.
I wrote the bar down before starting, so that the result could not quietly move it.
- What I set out to prove
- Two long-form experiences sharing the semantic API and disagreeing on everything else — typography, palette, motion, tension — built without editing SYX and without lowering the accessibility floor.
- What would have counted as failure
- One register, or two that differed only in colour. A system that produces one thing is not a system, it is a template.
What I accepted
Two registers, and a media budget I would not accept in production.
Two deliberate constraints, and I would rather name the price than leave it out.
- What the constraint bought
- Two registers far enough apart to be worth comparing, and a motion language taken to its ceiling instead of to a safe midpoint. The test needed both extremes to mean anything.
- What it cost
- Two registers prove variation, not that the semantic API scales — that would take a fourth and a fifth. And the pieces carry a media budget that is indefensible in a client product: 14.6 MB and 52.9 MB of video.
- ATELIER · declared media
- 17 MB
- OBSIDIANA · declared media
- 57 MB
- Registers built
- 2
Act 02
How the rules were built
The decision the project hangs from
Knowledge split into domains, loaded on demand.
I broke the rules into six domains that load separately, inside a public mind-system of 340 files, so a task reads only the domain it needs instead of the whole body of rules. Everything else follows from that. Splitting the knowledge is what makes a second system cheap enough to consult on every single task, and a second system nobody consults is documentation, not governance.
- brandingPerception of prestige: foundations, and the rules derived from them
- frontAccessibility, CSS architecture, semantics, progressive enhancement
- motionTen patterns, plus fundamentals, capabilities and a glossary
- syxTokens, themes, OKLCH colour and the SCSS pipeline
- uiTypography systems, colour theory, practical interface craft
- uxHeuristics, laws of UX, microinteractions, writing for interfaces
Separation of concerns
ATLAS decides what the experience should feel like. SYX decides how it is built.
ATLAS is the editorial mental model; SYX is the executor. The split keeps creative direction from leaking into implementation rules, and it is what makes the stack debuggable: when a piece comes out wrong, it is an intent problem or a build problem, and the two live in different repositories.
Knowledge, not prompts
Ten motion patterns became part of the system, not part of a prompt.
The motion domain documents ten reusable patterns — narrative intent, parameters, GSAP controls, the prompt that invokes each one and the reduced-motion fallback it degrades to. A pattern written into the system is loaded by a mode; a pattern described in a prompt is rediscovered on every task. That is the whole distance between context and instruction.
- character-cascadeLetters enter one after another
- cursor-followerA mark that trails the pointer
- draw-svg-pathA line that draws itself
- horizontal-scrollVertical scroll moved sideways
- magnetic-buttonA control that pulls toward the pointer
- mask-revealContent uncovered by a moving mask
- parallaxLayers travelling at different depths
- pinned-scrubA pinned section scrubbed by scroll position
- scramble-textCharacters resolving into words
- typewriterText typed out on entry
Act 03
What it proved
Live product evidence
Same system. Two radically different editorial registers.
ATELIER and OBSIDIANA are rendered directly from the published GitHub Pages experiences. The previews are intentionally non-interactive here; each project can be opened separately to explore the full motion and scroll behaviour.
The measurement
Thirty-two shared semantic tokens. Three shared primitives.
Whether two pages look alike is an opinion, so I counted instead. ATELIER declares 35 semantic tokens and OBSIDIANA declares 37; 32 of those names are the same. Underneath them ATELIER declares 15 primitives and OBSIDIANA 14, and only 3 are shared. The two pieces speak an almost identical semantic API on top of almost entirely different identity values — which is the behaviour the stack was built to produce, stated as something a reader can go and recount.
- Shared semantic tokens
- 32
- Shared primitives
- 3
- Knowledge domains
- 6
Act 04
What it left behind
Where the pattern went
The method moved to a domain with nothing editorial about it.
ATLAS was not absorbed into SYX — the traffic ran the other way, and SYX is untouched by it. What travelled was the shape: a domain system sitting on an execution system, with the knowledge split into loadable domains. SYX-mail applies that shape to HTML email, where the constraints are Outlook and Gmail instead of editorial hierarchy: a mental model, six knowledge domains, one mode. This portfolio runs on it too — eight domain skills over a router that decides which ones a task loads. Neither of them is about media, and that is the part that makes the test worth something.
Takeaway
Writing the pattern down costs more than writing the code.
Documenting the ten motion patterns took longer than implementing them would have taken in the two pieces that use them. Written knowledge only pays back above a certain number of pieces, and I did not know that number when I started — I still don’t. So the honest reading of this project is narrower than the ambition behind it: it shows that two systems compose, not that writing the second one down was the cheaper route.
Open ATELIER ↗Open OBSIDIANA ↗Explore repository ↗SYX on GitHub ↗SYX-mail on GitHub ↗