The model is not the taste.

A better model is not a design system

The immediate catalyst for this Work was a video by Nate Herk about using Fable 5.1 for web design.

The examples were impressive. More interesting was the machinery around them.

Nate was not typing “make it beautiful” into a model and waiting for genius. His process included high-quality references, decomposition of those references into usable design behavior, reusable design doctrine, page grammars, uniqueness controls, richer scroll and interaction behavior, visual inspection, mobile checking, correction, and failure lessons preserved for the next build.

The model was strong.

The environment around the model was much stronger than the prompt.

One part of his comparison made the point almost accidentally. Using the same broad design system, prompts, assets, brand guidance, and Scrollcraft process, he compared Fable 5 with Fable 5.1. His reported visual results were quite similar. The clearer advantage of the newer model was efficiency and cost.

That is not proof that models are interchangeable.

It is a reason to ask a better question.

How much premium design capability can be externalized from the model into the system around it?

Once Work intent, references, visual authority, constraints, verification, and failure memory are held materially constant, how much model advantage remains?

That is a much more interesting experiment than asking which model makes the prettiest landing page after each one receives a different conversation, different assets, different retries, and whatever aesthetic mood happened to prevail that afternoon.

We had already been building this

The funny part is that SharePlane was already moving in this direction before I had a name for it.

We did not start with a Design OS.

We started by getting irritated.

A page looked wrong.

A generated artifact lost something the previous one had.

A coding agent preserved the content and destroyed the composition.

A mobile layout technically fit on the screen and still felt terrible.

An accepted image got replaced by a convenient derivative.

A page passed mechanical checks and failed the only test that mattered: I looked at it and said no.

Those failures accumulated.

In the original SharePlane work, we began recording Design Learning Receipts, Visual Precedent Locks, Layout Locks, no-regression baselines, negative patterns, and the distinction between a design decision and its mechanical implementation.

SharePlane Next pushed the idea further with Presentation Family, Presentation Variant, Visual Grammar, multiple presentations over the same semantic Work, genuinely different candidate directions, and browser qualification of the final composed shell rather than pretending the standalone artifact was the thing the reader would actually experience.

Then SharePlane Platform made the next step explicit.

Design memory should be graph-backed.

A future Work should be able to ask:

What have we already made?

Which presentation families have we used?

What did I accept?

What did I reject?

What required repair after UAT?

Which structural patterns worked in one context and failed in another?

Which patterns are becoming overused?

Is this Work intentionally reusing something, mutating it, recombining it, or creating a new family?

That architecture is already present in the design-memory lineage around Platform Issues #9 and #383, including real preflight records and named presentation families.

It is not complete everywhere at runtime. I do not want to rewrite history and pretend the whole thing is already a polished product.

But the next step is no longer “invent a design system.”

The next step is to connect what we already built.

References should teach, not clone

This became obvious the moment we started feeding outside websites into the design process.

I showed the system Glaido because I liked its restraint and the way it demonstrates product behavior in context. I showed it Fora because I liked its atmosphere, scale, and the way large proof surfaces enter the page. Nate’s material pointed us toward FLORA, 21st, Godly, Awwwards, MotionSites, Lemon, and other strong references.

This is incredibly powerful input.

It is also dangerous if handled lazily.

During this Work, we generated visual studies inspired by outside references. Some of them looked beautiful.

They also carried source branding and product language into the generated concept.

Wrong product name.

Wrong identity.

Wrong implied claims.

Beautiful page. Failed design.

That mistake produced one of the first useful Design OS lessons:

External precedent may transfer design principles. It may not transfer source identity.

Or more compactly:

Beautiful does not mean owned.

A reference should be decomposed before it enters design authority.

What do I actually like about it?

Typography?

Whitespace?

Atmosphere?

How proof enters the hero?

The way product behavior is demonstrated in context?

Foreground and background relationships?

The rhythm between dense and quiet sections?

The way scroll changes composition?

Then we record the other half.

What should not transfer?

Branding. Copy. Product claims. Customer logos. Distinctive source composition. Unlicensed assets. Code without provenance or license.

The goal is not to make something that looks like Glaido plus Fora plus FLORA divided by three.

That is how aesthetic soup is made.

The goal is to preserve the principle and transform it through the semantics of the new Work.

Design input should be multimodal

A useful Design OS cannot require every visual idea to arrive as prose.

Sometimes the best design instruction is:

I like this.

Then point at something.

A website. A screenshot. An infographic. A slide. A diagram. One crop from a larger page. An old artifact we built six weeks ago. Even a rejected design where one particular treatment was excellent.

The intake should be simple.

Paste a URL.

Upload an image.

Drop in a PDF page.

Point to the relevant region.

Then explain only what matters:

I love the typography and how the proof enters the hero. Not the colors.

Or:

This infographic has the relationship structure I want. Redraw it completely in our grammar.

Or:

The motion here is excellent. The rest of the site is irrelevant.

The system turns that visual input into governed precedent.

What was observed?

What did the owner actually select?

Why might it work?

Where could it apply?

Where should it not apply?

What must not be copied?

What other design memory does it conflict with?

Is it conceptual precedent, bounded precedent, or an exact reference?

That is dramatically more useful than a bookmark folder.

It converts visual discovery into durable design context.

Verification is part of design

One of the easiest lies in software is this:

The page built successfully, therefore the page works.

We have enough painful evidence to know better.

The accepted image exists in the repository but does not actually paint in the browser.

One viewport can look beautiful while another is technically non-overflowing garbage.

The artifact respects the operating system’s dark-mode preference while the SharePlane shell has explicitly selected light mode, producing a theme-authority collision.

A button exists and cannot be clicked because another layer intercepts the hit target.

The browser sees the element.

The owner sees the failure.

A mature design process treats visual verification as first-class evidence.

For scroll-driven work, capture intermediate states, not only section endpoints.

For every major viewport class, determine whether the composition remains intentional, not simply whether it fits. Mobile, tablet, desktop, and large desktop can fail differently.

For reduced motion, preserve meaning without requiring the motion path.

For accepted imagery, verify that the expected asset identity appears in the expected semantic position.

For interaction, test the final composed shell.

For theme, test disagreement cases, not only light/light and dark/dark.

For visual originality, compare the structural fingerprint against recent Works.

Then the owner reviews the thing that actually exists.

Approval and rejection are evidence too.

Evidence teaches. Governance decides what gets learned.

This is where the system begins to compound.

Suppose Work #001 reveals that differential multi-plane motion becomes visually incoherent below a certain mobile width.

That is an observation.

It is not automatically doctrine.

The system should preserve the exact Work, viewport and state evidence, observed defect, candidate repair, corrected result, whether the correction held across qualification, whether the owner accepted it, the proposed generalized lesson, and its scope and counterexamples.

Then a governed learning decision determines whether that lesson becomes reusable guidance.

Models can propose lessons. Validators can detect patterns. One successful Work can generate evidence.

None of them should silently rewrite the design constitution.

The governing principle is simple:

Models generate. Evidence teaches. Governance decides what the system learns.

Work #002 is where the claim gets serious

One beautiful page proves almost nothing.

This one should be stunning. A Design OS page that looks like internal documentation with an attractive header would be a failure so perfect it might deserve its own museum exhibit.

But Work #001 is still only the first test.

The more meaningful test is Work #002.

Give the system a semantically different problem. Different reader. Different emotional goal. Different visual authority. Different source material.

Then ask whether the system benefits from Work #001 without becoming Work #001.

Did it avoid a failure we already learned?

Did it retrieve a useful precedent?

Did it reject an overused skeleton?

Did it require fewer human corrections?

Did it remain visually distinct?

Did design memory help without turning into a house style?

That is compounding design capability.