Preview = Runtime Parity

Why drift is a problem

Most theming systems maintain two separate rendering paths: a preview renderer for the dashboard and a production renderer for the live screens. They start identical, then diverge as the product evolves. By the time an admin configures branding, the preview may no longer accurately represent what users will see.

Common failure modes:

• A border radius set to 12 renders as 8 in production due to a different unit conversion in the preview.
• A font weight of 600 appears correct in preview but maps to 700 in production because of a normalization shortcut.
• A background image appears in preview but fails in production under a stricter CSP policy.
• A color renders slightly differently because the preview applies an opacity filter that production does not.

When an admin approves a design in the dashboard and it ships with visible differences, the branding system has failed its core job.

---

How Shyntr eliminates the split

Shyntr uses a single rendering path. The dashboard preview and the live login and consent screens are rendered by the same token resolver and the same layout components.

There is no preview-specific stylesheet. There is no production-only override layer. Token values are passed to the renderer without transformation — except for borders.radius clamping to 0–32, which applies identically in both contexts.

The parity guarantee is structural. It is not maintained by discipline or convention — it exists because the two surfaces share the same code.

---

The draft/publish safety model

The branding editor operates on a draft. Edits made in the dashboard are saved to the draft state and do not affect the live auth portal until explicitly published.

What this means in practice:

• Editing a draft does not affect live users. You can iterate freely.
• Previewing shows exactly what users will see, rendered by the same engine as the portal.
• Publishing is the only action that changes live behavior. It is explicit and intentional.
• Resetting removes the published branding and returns the tenant to system defaults.

This model gives admins a safe editing environment without risk of accidentally exposing half-finished configurations.

---

Strict parity rules

No preview-only styling No CSS class, style attribute, or layout property is applied exclusively in the preview context. Tokens resolve the same way in both environments.

No runtime-only overrides The production login and consent screens do not apply any style absent from the preview render. Environment-specific factors such as CDN headers or CSP policies may affect asset loading, but the visual token resolution is identical.

No hidden transformations Token values reach the renderer unchanged. The only normalization that occurs — borders.radius clamping — is applied equally in preview and in production.

---

Examples

borders.width = 5

{ "borders": { "width": 5 } }

Context	Rendered border width
Dashboard preview	5px
Live login screen	5px
Live consent screen	5px

The integer 5 maps to 5px directly. No scaling. No rounding.

---

Font weight

{
  "typography": {
    "fontWeightNormal": 500,
    "fontWeightBold": 600
  }
}

Token	Preview	Runtime
fontWeightNormal	500	500
fontWeightBold	600	600

The constraint to 500 / 600 is enforced at write time. No remapping occurs at render time.

---

Background image fallback

{
  "background": {
    "color": "#F8F9FF",
    "image": "https://cdn.acme.com/auth-bg.jpg"
  }
}

State	Preview	Runtime
Image loads	Image over #F8F9FF	Image over #F8F9FF
Image fails	#F8F9FF	#F8F9FF

The fallback logic is the same function in both contexts.

---

Summary

Property	Dashboard preview	Auth portal runtime
Token resolver	Shared	Shared
Layout components	Same	Same
Preview-only styling	None	—
Runtime-only overrides	—	None
borders.width scaling	None (1:1)	None (1:1)
borders.radius clamping	Applied	Applied
Accepted font weights	500 / 600	500 / 600
Background fallback	color when image fails	color when image fails
Hidden transformations	None	None
Draft changes affect live users	No	No (until published)
Publish required to go live	—	Yes

tip

Configure your brand once. What you approve in preview is exactly what your users will see.