Stop writing the email design system. Derive it from what you already send.

The reason design-system documents rot in email specifically — faster than they rot in product — is that email production runs through duplication. Nobody builds a campaign from the design system. They open last month's campaign, duplicate it and change the copy. Every send inherits the last send's decisions, including the ones made at 6pm to fix a wrap on mobile. Eighteen months of that and the document and the output are describing different products.

So the useful question in 2026 is not "how do we get people to follow the system". Given that the emails already encode a system, can a machine read it back out? The answer is mostly yes, with a boundary that matters more than the capability does. Ingestion recovers inventory reliably. It does not recover intent at all. Almost every bad outcome with this technique comes from confusing the two.

Mechanically, there are two entry points and they behave differently enough that picking the wrong one wastes a day.

Starting from a shipped email, Orbit's orbit_learn_email_template parses the HTML into a module spine — the ordered list of the repeatable blocks the template is built from — plus brand tokens: the colours actually used, the type sizes actually set and the foreground/background pairs that meet on the page with their computed contrast ratio. It preserves the builder-specific structure in the markup, so an assembled result can go back into the tool it came from and still be editable rather than arriving as one immovable slab. Learn the same template again later and it saves as a new version instead of overwriting, which is what makes drift visible.

Starting from design, orbit_import_design takes a Figma file or frame and saves the raw node data, a preview and a normalised import record. Figma is the preferred source because a frame carries real structure — named layers, groups, constraints — and that structure is what makes a rebuild reusable instead of a one-off trace. PDF is supported and deliberately demoted, arriving as a reference-mode record with an explicit low-confidence warning, because a PDF is a picture of a layout with the layout removed. The protocol's own rule is to not overstate what PDF recovers, which is the correct posture for a tool that could otherwise hand you a confident-looking catalogue built on guesses.

The verdict is to derive from the HTML that shipped and reach for Figma only when the design deliberately leads the build. Teams instinctively reach for Figma first because that is where design lives — but the Figma file is frequently the version before three build compromises, and rebuilding from it reintroduces the exact problems the compromises solved.

The Email Design Ingestion skill carries the full protocol, including the part people skip: assessing confidence in the extracted structure before anything downstream is built on it. An import record that is unsure about which frame it read should say so and ask, rather than proceed on a guess.

The honest limitation is not a small one. Derivation is descriptive. Point it at a template with a 13px caption at 3.9:1 contrast, and 13px and that grey become part of the derived palette. The machine has no way to know the caption was a compromise, that the grey was picked to match a website that has since been redesigned, or that the accessibility review flagged it and lost.

So the derived catalogue is a draft. The human act that follows is pruning. Where three greys exist and one was intended, keep one and record why the other two turn up in old sends. Where two hero modules differ only in image aspect ratio, decide whether that is a real variant or an accident, because if you do not decide, both survive and next quarter there are four. A derived system that nobody prunes is just your inconsistency, now with a filename.

The second thing derivation cannot give you is the rule layer. A catalogue can tell you a promo strip exists. It cannot tell you the promo strip never appears in a transactional email, that the legal line never sits inside a hero, or that the second CTA is for campaigns and never for lifecycle. Those rules are the actual content of a design system. They only exist in someone's head until someone writes them. The machine gives you the inventory in an afternoon so that the week you would have spent cataloguing goes into the rules instead. That is the whole trade, and a good one.

The failure mode after a successful import is common and undramatic. You now have a beautiful module catalogue, a token file and a contrast sheet. Six weeks later a campaign ships that ignores all three. Nothing was enforcing them. Nothing ever is, in email, because the send button does not read your documentation.

The line between a catalogue and a system is a gate — an automated check that runs before send and returns a verdict against your specific tokens, your specific limits and your specific templating branches. Orbit generates one from the derived system for exactly this reason: the catalogue defines what compliant means, and the gate is the thing that can say no. Without it you have documentation. The gate is what turns a catalogue into a system. The difference shows up the first time someone duplicates last month's campaign and the gate objects to a colour pair that has been slowly drifting for a year.

This is also where derivation pays its second dividend. Because the catalogue came from your sends, you can re-derive from last quarter's sends and compare. Drift stops being a feeling that things have got messy and becomes a diff: two new greys, one new type size, a module that exists in four sends and no catalogue. That is a maintenance loop a person can actually run, quarterly, in under an hour.

The Template Brain skill covers the full path — scaffold the repository, ingest what you already send, generate the gate, then frame each program against it. The dark mode guideis worth reading alongside it, because the derived colour pairs are exactly the ones a client's dark-mode inversion will act on, and a token set chosen without that in mind is a token set with a surprise in it.

Take the last campaign you sent. Not the nicest one — the last one. Feed the HTML to the ingestion step and read the palette that comes back before you read anything else.

Count the greys. If there are more than two, you have found the highest-value hour of cleanup available to you this month. It took about ninety seconds to find. Then look at the contrast pairs and find the lowest one. There is a strong chance it is a caption, a footer, or a disclaimer — the elements that get styled last and reviewed never — and a strong chance it has been in every email you have sent for a year.

Neither of those findings requires a project. They require a decision, which is the thing derivation frees you up to make. Write the rule down next to the catalogue and put the gate in front of the send. The version of this document written eighteen months from now will still describe the emails you are actually sending.