Orbit DNA 2.0

When a team changes button colour, spacing or focus separately in several places, design and implementation drift apart. Orbit ties a design decision to a named token and gives components a shared starting point. For a client, that makes the next page or product easier to check against a rule instead of guessing the decision again. DNA 2.0 specifies a further step in that relationship; it is not a released system version. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The story follows a token into a usable component and then into a checkable rule. This is a proposed way to explain the system: a component can be inspected, but one visual example cannot establish that DNA 2.0 has been adopted. [2] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The curated specimen shows one control in day and night contexts. Visitors see the token name, the resulting component state and the question to test: do text, focus and state remain legible in both contexts? Its logic is a DNA 2.0 proposal. [3] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026 The source value may come from the released Orbit v1 package; it is not a 2.0 release. [2] Observed · Versioned package · reviewed 24 Sept 2026

Without scripts, the token name, static control and check explanation remain readable. Motion supports feedback rather than carrying content; reduced-motion settings preserve the same decision. These are acceptance criteria for the proposed specimen, not a claim that DNA 2.0 gates have passed. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The first rule is one semantic name per meaning: a component reads a token instead of embedding an isolated colour value. The second is a visible state: keyboard focus and the selected mode must make sense without relying on colour alone. The third is a traceable change: a token edit triggers component review and a specific gate. These are DNA 2.0 specification directions illustrated by the specimen. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026 [3] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The material decision separates opaque content, a covered navigation bar and an opaque decision surface. Light navigation material must not become the background for a report, price or dialog; without blur, the bar still needs to be readable. Controls get their own semantic boundary token because a decorative hairline may not identify the target. These are proposed DNA 2.0 contracts whose contrast still needs measurement against actual CSS. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The type rule keeps roles in tokens while allowing reader enlargement: a long heading can wrap, and a button must not widen its grid column at 200% text size. The document profile keeps a readable line measure, while aligned figures are a separate data-type decision. The prototype's type sample does not establish every page's behaviour; that needs browser verification. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

A gesture needs activation, release, cancellation and a keyboard path. A press, for example, acknowledges input immediately but performs the action only on release inside the target; cancellation must not cause a side effect. A send state likewise separates local press, pending request and server-confirmed result. Haptics cannot be the only message channel. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

The motion proposal uses an interruptible physical spring: if the target changes, an object continues from its current position and velocity. A duration-based “bounce” adapter is not presented as the same contract, and reduced-motion settings keep the state visible without movement. Exact pixel behaviour still needs an integration test. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

Layout follows the job: marketing needs one clear next step, product views preserve selection and data state, and documents support reading and verification. On a contact journey that means service choice, scoped enquiry, honest sending state and a real confirmation or recoverable error. The six proposed conversion screens express decision logic, not measured conversion growth. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

Orbit v1.0.0 is internally stable. The generated token map from the related @leisson/shared v2.5.0 package supplies released source values, but the package version is not a DNA 2.0 release. We do not present the older artifact's token count or check result as progress on the new specification. [2] Observed · Versioned package · reviewed 24 Sept 2026

This page keeps two evidence layers separate. The generated token map and pinned package describe existing Orbit v1 implementation. [2] Observed · Versioned package · reviewed 24 Sept 2026 The sixteen-section DNA 2.0 HTML sets out proposed directions for identity, components, motion, accessibility and quality gates. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026 Check a source's status before treating a specimen as a technical commitment.

The specimen maps the v1 token color.signal values #7CB8FF for night and #1F5FD1 for day to the CSS output --orbit-color-signal. The sample button's focus ring uses the selected mode's value; permitted token uses are a focus ring, active navigation or one highlighted number. [2] Observed · Versioned package · reviewed 24 Sept 2026 The next check is to measure visibility, legibility and state distinction in both modes. It has not passed for DNA 2.0. This specimen does not establish system-wide contrast, passing tests, current Figma variables or a DNA 2.0 release. [3] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

If the same design decisions recur across your channels, we can map one important user journey, assign its tokens and components, and agree a measurable check. The outcome is a bounded system slice with a visible specimen, usage rule and handoff criteria; a full product redesign needs a separate scope. [2] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026

Tell us which screen or state diverges most today. We can use it as a shared starting point without assuming DNA 2.0 is already deployed in your project. [1] Proposal · DNA 2.0 specification · reviewed 24 Sept 2026