# Ralti brand guidelines

Version 2.0 · September 22, 2026 · Brand and launch-preview guidance

Ralti is a confident, approachable work platform. It helps people turn what they need to track into a workspace they can understand and change. The brand should feel credible beside established work-management products while showing its own advantage: useful structure that adapts through a simple request.

These guidelines describe the brand, not a production-release announcement. The source application is currently locally hosted. Public copy and links must reflect the experience actually available.

## 1. Positioning and promise

**Category:** An adaptable work platform.

**Positioning:** For individuals and teams who need more than a list and less setup than a complex system, Ralti brings editable sheets, connected records, and reviewed AI changes into a workspace that can grow with the work.

**Promise:** Start with what you need. Keep shaping it as you go.

**Brand line:** **Work, moving.**

**Campaign message:** **Good work. Better together.** Connect it to the two modules joining, and to related work coming together. Keep the product headline below as the primary introduction. Use “Work, moving.” as a sign-off, campaign accent, or presentation close. Pair it with category context when introducing Ralti; it cannot explain the product alone.

The distinctive story is not that Ralti contains AI. It is that a person can describe the work, review a useful structure, and continue editing that structure directly. Show this sequence whenever possible: request → proposal → workspace → useful change.

## 2. Audience and personality

Give individuals, teams, and small businesses equal legitimacy. Individual examples include applications, learning plans, personal projects, and reading lists. Team examples include product planning and content calendars. Business examples include customers, follow-ups, and operational records. Do not imply that personal users are a temporary audience before the “real” enterprise customer arrives.

Speak to people doing the work, rather than exclusively to administrators or software experts. Make the first step understandable without teaching database terminology.

Ralti is **capable, direct, upbeat, and composed**. Capability comes from a precise demonstration. Directness comes from naming the action. Optimism comes from making progress feel possible. Composure comes from restrained layouts, readable records, and honest explanations when something needs attention.

Boldness belongs in the headline and visual hierarchy. It does not require exaggerated claims, aggressive sales language, or constant exclamation marks.

## 3. Name and product language

Write **Ralti** in prose, headings, app titles, accessibility labels, metadata, and support communications. Pronounce it **RAL-tee**. Use **ralti** only inside the approved lowercase wordmark or when reproducing an actual lowercase address or handle. Never write RALTI as the default product name. Do not invent an acronym or an etymology.

Use the current product hierarchy: **workspace → workbook → sheet**. A workspace contains personal or shared work. A workbook brings related sheets together. A sheet contains records. In introductory copy, “items” is often more natural than “records”; in technical documentation, retain the exact concept needed. Use **field** for a stored attribute and **column** when discussing the visible table.

Use **Ask Ralti** for the branded assistant after the interface is renamed. Use **automations** for configured triggers and actions; use **agents** when reasoning is actually involved. Do not call every scheduled rule an agent.

Prefer “connected records” to “relational entities,” “change a column” to “modify the schema,” and “review changes” to “validate an operation batch.” Preserve exact button labels in instructions.

## 4. Messaging architecture

| Pillar | Customer-facing message | Demonstrable evidence |
|---|---|---|
| Start simply | Describe the work. Build from there. | A request creates a proposed tracker or connected workbook. |
| Adapt visibly | Change the structure as your work changes. | Editable columns, linked records, formulas, saved views, and boards. |
| Keep context connected | Give the details a place to belong. | Record notes, attachments, assignments, discussions, and relationships. |
| Stay in control | Review the next change before it becomes your work. | Chat proposals have review/apply steps; automation modes have separate controls. |

Do not promise that every change always requires review: configured automations can run automatically. Specify the behavior being demonstrated.

A feature announcement follows **situation → action → useful result**. Example: “Campaign dates changed. Update the schedule in your sheet and keep related work together.” Do not imply automatic dependency rescheduling unless that exact behavior exists.

## 5. Recommended launch message

**Headline:** **Big plans. Find your fit.**

**Supporting copy:** A flexible workspace for projects, ideas, customers, and everything connected to them. Tell Ralti what you need, review its suggestions, and shape the work as you go.

**Primary CTA for the current preview:** **Explore Ralti** — link to a real product walkthrough or capabilities section on the page.

**Context label:** **A first look at Ralti** when presenting a preview. Use **Product preview** beside illustrative interface artwork. Do not style an illustration as a working embedded application.

This headline connects ambition to a workspace that adapts to different kinds of work. The supporting copy establishes the product category immediately, so “fit” reads as useful flexibility rather than recruitment or fitness. The two-piece identity makes the same idea visible. “Fit” names the identity concept; the product remains Ralti.

After a usable hosted application exists, **Create your workspace** can become the primary CTA. Until then, do not offer a broken sign-up, imply instant Cloud access, display invented pricing, or create a nonfunctional waitlist form. “See Ralti in action” requires an actual demonstration.

## 6. Voice in practice

| Situation | Use | Avoid |
|---|---|---|
| First visit | What would you like to keep track of? | Configure your intelligent operational database. |
| Example request | Track campaign ideas, owners, and publish dates. | Unleash infinite productivity with agentic intelligence. |
| Proposal ready | Review 4 new columns before adding them. | Your workspace has been magically optimized. |
| Change applied | Added Publish date. Undo | All done! Everything is perfectly organized now! |
| Conflicting edit | This sheet changed while your preview was open. Refresh the proposal before applying it. | Something went wrong. |
| AI unavailable | AI is unavailable right now. Try again or choose the built-in helper. | Our offline AI has taken over. |
| Email connection | Connect a Microsoft mailbox to work with email. | All your messages, automatically connected. |
| Empty customer sheet | Add your first customer. | No relational entities detected. |

Use sentence case. Favor verbs and concrete nouns. Keep helper text to one thought per sentence. Use contractions in conversational guidance; keep destructive-action labels literal. State what happened and what the person can do next. Never mask uncertainty with cheerful filler.

Marketing may be more expressive than product messages, but both should sound like the same competent colleague. Avoid “revolutionary,” “limitless,” “effortless,” “autonomous everything,” and unsupported superlatives.

## 7. Use-case copy

**Product planning — From requests to a clearer roadmap.** Organize feature ideas, priorities, owners, and status in editable sheets. Connect related work and switch to a board when stages are easier to see. Do not imply a shipped GitHub/Jira synchronization or dependency engine.

**Content — Keep the next idea moving.** Capture ideas, assign owners, set publish dates, and follow work from draft to published. Keep notes and attachments with each item. “Track publication” is accurate; “publish everywhere” is not.

**CRM — Keep the customer and the next step together.** Connect customer records, opportunities, notes, and follow-ups in a workbook you can adapt. Configured Microsoft email can link conversations to records. Do not advertise external CRM synchronization or guaranteed email delivery.

**Operations — Give recurring work a structure.** Connect projects, requests, inventory lists, and operational records. Use formulas, rollups, and configured helpers to reduce repeat handling. Describe finance and inventory as tracking; do not call them a compliant accounting or inventory transaction system.

## 8. Claims and proof

The current README is the source of truth for shipped behavior; the original product brief describes intent and may lag the implementation.

Supported capabilities include editable tables and grouped boards; typed fields and saved views; linked records, formulas, and rollups; reviewed chat proposals; automations and scoped agents; team roles, discussions, assignments, and invitations; CSV/TSV import and CSV export; and a native companion for existing capture/find/update flows.

Qualify features where the condition changes the promise. AI requires a configured provider. Scheduled helpers require the server to run. Microsoft email requires configuration and consent. Team/email/workbook management is currently web-only. CSV import has documented size and row limits; avoid “import any spreadsheet.”

Do not claim a deployed public service, App Store availability, enterprise ERP parity, SOC 2 certification, HIPAA compliance, enterprise SSO/SCIM, unrestricted scale, realtime cursor coauthoring, per-record permissions, native Excel import, or external CRM sync. Do not claim all data stays on-device: selected context may go to a cloud AI provider.

No invented customer logos, user counts, reviews, star ratings, savings percentages, uptime promises, or testimonial portraits. Use clearly fictional demonstration records. A founder observation is not a customer testimonial. Screenshots must show real behavior or carry an adjacent preview label.

## 9. Color system

| Token | Value | Main role |
|---|---|---|
| Midnight | `#17233F` | Primary text, dark brand panels |
| Cobalt | `#3457E6` | Primary action, links, active emphasis |
| White | `#FFFFFF` | Main canvas, text on Cobalt or Midnight |
| Mint | `#BAF2CF` | Selective accent, small editorial highlights |
| Cloud | `#F4F7FC` | Secondary panels and quiet grouping |
| Slate | `#5C6780` | Secondary text and supporting detail |

Let white and Cloud occupy most layouts. Use Midnight for clarity, Cobalt for the main interaction, and Mint for one focal accent at a time. Use Mint for supportive accents and confirmed completion, paired with a clear label or checkmark. Do not put a rainbow of decorative statuses into the core brand. Status needs a label or icon, not color alone.

### Contrast rules

Ratios below were calculated from the exact solid hex colors using sRGB linearization: `c/12.92` at `c ≤ 0.04045`, otherwise `((c + 0.055)/1.055)^2.4`; relative luminance is `0.2126R + 0.7152G + 0.0722B`; contrast is `(Llighter + 0.05)/(Ldarker + 0.05)`.

| Foreground / background | Ratio | Approved use |
|---|---:|---|
| Midnight / white | 15.57:1 | All text |
| Midnight / Cloud | 14.50:1 | All text |
| Slate / white | 5.67:1 | Normal supporting text |
| Slate / Cloud | 5.28:1 | Normal supporting text |
| White / Cobalt | 5.75:1 | Button and panel text |
| Cobalt / white | 5.75:1 | Links and emphasized text |
| Cobalt / Cloud | 5.36:1 | Links and emphasized text |
| Midnight / Mint | 12.38:1 | Accent-panel text |
| Cobalt / Mint | 4.57:1 | Normal text, sparingly |
| Mint / Cobalt | 4.57:1 | Normal text, sparingly |
| White / Midnight | 15.57:1 | Dark-panel text |

Prefer Midnight text on Mint. Slate/Mint measures 4.5024:1, leaving almost no tolerance for opacity or color changes; do not use it as a standard pairing. Cobalt/Mint passes at 4.57:1 only at these exact opaque colors. Avoid Midnight body text on Cobalt (2.71:1), white on Mint (1.26:1), and Slate on Cobalt (1.02:1). Cloud against white is only 1.07:1; it cannot be the sole visible boundary of an input or essential control. Add a contrasting outline or another clear affordance.

WCAG AA requires 4.5:1 for normal text and 3:1 for qualifying large text; essential non-text control/state information generally requires 3:1. These pairings are not a declaration of whole-site compliance. Recheck opacity, gradients, images, focus states, and actual rendered sizes. Sources: [W3C text contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html), [non-text contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html).

## 10. Typography and layout

Use **Inter Tight** for expressive display headings and **Inter** for body text, navigation, controls, and product data. Both are available under the SIL Open Font License; retain the supplied license with distributed font assets. Sources: [Inter](https://github.com/rsms/inter/blob/master/LICENSE.txt), [Inter Tight](https://github.com/google/fonts/blob/main/ofl/intertight/OFL.txt).

Suggested scale: desktop hero 80–96px, mobile hero 44–56px, section headings 36–48px desktop and 30–36px mobile, body 16–18px, labels 14px regular and secondary text no smaller than 12px. Use display weight 600–700 and body 400–500. Display line height 1.0–1.1; body 1.5–1.65. Tighten display tracking modestly, around −0.03em; keep body tracking normal. Avoid compressed all-caps paragraphs and tiny product labels.

Build spacing from 4px: 8, 12, 16, 24, 32, 48, 64, 96. Give each section one clear visual job. Keep body measures near 55–70 characters and center the page within a 1200–1280px content area. Use 24px mobile gutters, adjusted for small screens. Favor purposeful alignment over decorative cards around every sentence.

Use 12–16px corner radii for cards and 8–10px for controls; use pills for chips and selected navigation only. Shadows should separate layers, not create a floating-card collage. Interactive hit areas should normally be at least 44px high with visible keyboard focus.

## 11. Logo, imagery, and motion

Use approved logo assets only. The lowercase wordmark is a visual signature; regular text still uses Ralti. The Fit symbol consists of exactly two asymmetric interlocking modules that form a compact square with a stepped negative seam. Preserve both modules and the space between them. The master symbol uses a 272 × 260 viewBox. Keep at least one quarter of the symbol width clear on every side, measured from the master artboard width. Use the symbol at 20px or larger; 24px is preferred for normal UI. The full lockup is at least 100px wide. Use the supplied outlined lockup; never retype the logo. Preserve both approved module paths and the original proportions. Do not redraw letters, add effects, rotate the symbol, or derive a new construction from a thumbnail. The logo is a design output, not legal trademark clearance. Prefer Midnight on White, White on Midnight or Cobalt, and Midnight on Mint. Test the smallest actual placement before release.

Product imagery should lead. Show a readable workspace, a purposeful request, or a clear before/after change. Keep density plausible and data internally consistent. Do not fill screens with unreadable filler or imply integrations through unearned third-party logos.

Photography is optional: show real people doing specific work, natural light, and useful context. Avoid staged handshake scenes, generic futuristic offices, glowing brains, robot assistants, and decorative stock-photo grids. Obtain appropriate asset rights and never present a stock person as a customer.

Motion follows the two-piece fit motif: separate elements align, a reviewed proposal becomes an applied change, or a completed action settles into place. Keep entry, review, apply, and undo transitions causal. Use approximately 120–180ms for controls and 180–260ms for panels. Never move or hide information needed for reading. Respect reduced-motion settings; the static state must communicate the same story. Any continuous decorative motion requires a visible pause control. No scroll hijacking or unpausable loops.

## 12. Release consistency check

Before publishing, confirm the name, approved artwork, readable contrast, keyboard operation, mobile layout, working CTA destination, and truthful product state. Check each claim against the current README and each screenshot against an actual workflow or explicit preview label. The strongest proof of this brand is a clear demonstration that lets someone understand the next useful thing they can do.