Atlas

Platform due diligence

The decisions Atlas makes — and why they hold together.

Architecture layers, typed data flow, production safeguards, agent workflow, and what ships in the repository. This page is for technical evaluation, not feature marketing.

Read the diligence answersTrace the data path
Atlas frontend architecture: product applications at the center, supported by the interface system and data and validation layers, application foundation beneath both, enclosed by a production reliability boundary.

Production reliability

  • Testing
  • CI
  • Security
  • Observability

Product applications

  • Marketing site
  • Demo routes
  • Feature modules

apps/web/src/app/

Interface system

  • Shared primitives
  • Design tokens
  • Themes
  • Application states

@atlas/ui

Data and validation

  • Contracts
  • Typed client
  • Queries
  • Forms
  • Server-error mapping

@/lib/api

Application foundation

  • Shell
  • Authentication
  • Configuration
  • Feature flags

apps/web/src/lib/

Technical due diligence

Strong opinions, made coherent.

A staff engineer should leave this page able to explain Atlas decisions without a sales call.

Capability model

  • Build

    The conventions needed to build product features already exist.

  • Ship

    The repository contains the quality gates, not just application code.

  • Operate

    Production operation is part of the platform from the beginning.

  • Scale

    The architecture remains understandable as the team and codebase grow.

Inspect the UI system proof
What opinions does Atlas make?
Feature modules own domain logic. Routes stay thin. UI uses shared primitives. Data goes through typed clients and React Query. Forms share schemas with server validation. Production gates live in the repository.
Why were those decisions made?
They remove repeated infrastructure work, keep ownership predictable for humans and agents, and fail unsafe changes before merge instead of after deploy.
Where does code belong?
Product behavior lives in features/. Shared infrastructure lives in lib/ and packages/. Visual primitives belong in @atlas/ui only when they are genuinely reusable.
How does data move through the application?
OpenAPI contracts generate types. A central API client normalizes errors and correlation IDs. Feature hooks wrap React Query. Interfaces render loading, empty, error, and success states.
How are production failures surfaced?
Normalized API errors, structured logging, Sentry capture, and correlation IDs keep failures attributable from the boundary to the operator.
What does the repo enforce?
Lint boundaries, typecheck, unit tests, build validation, e2e smoke coverage, security audits, and performance budgets run as required gates.
What can I replace?
Providers and integrations are intentional seams: auth provider, telemetry backend, analytics, and flag delivery can change without abandoning the architecture.
What do I inherit automatically?
Shell conventions, form patterns, query key factories, UI states, theme tokens, consent gating, AGENTS.md guidance, and CI guardrails.

Data path

From contract to product interface

One typed path from the API specification to rendered UI. Each stage has a defined owner in the repository.

  1. OpenAPI contract

    The API specification is the single source of truth for request and response shapes.

    openapi/openapi.json

  2. Generated typed client

    api:gen produces TypeScript types and a typed client from the specification.

    apps/web/src/lib/api/contracts/

  3. Query or form integration

    Feature hooks call the client; forms bind Zod schemas through useZodForm.

    apps/web/src/features/demo/hooks.ts

  4. Validation and server-error mapping

    Client validation and applyServerFieldErrors keep field errors aligned with the API.

    packages/ui/src/lib/forms/server-errors.ts

  5. Product interface

    Loading, empty, error, and success states render through shared UI primitives.

    packages/ui/src/components/ui/empty-state.tsx

Product interface

The data demo renders every application state from the same query hook pattern.

Rendered interface

users.list query · mode: loaded

Showing loaded state for team directory.

Team directory
  • Alex MorganAdmin

    alex.morgan@example.com

  • Jordan LeeUser

    jordan.lee@example.com

  • Sam RiveraUser

    sam.rivera@example.com

  • Casey ChenAdmin

    casey.chen@example.com

Open data-fetching demo

Production reliability

Safeguards between change and production

Atlas ships automated checks that run on every pull request. Each gate maps to verified CI configuration.

These checks run in parallel. They protect production without implying one linear pipeline.

Pull request quality gates

Required before merge

Required

Code quality

  • Lint and format

    pnpm format · pnpm lintapps/web/eslint.config.mjs

  • Type checking

    pnpm typecheckturbo.json

Automated verification

  • Unit tests

    pnpm testapps/web/src/test/

  • Production build validation

    pnpm build.github/workflows/ci.yml

  • End-to-end tests

    pnpm --filter @atlas/web test:e2eapps/web/e2e/smoke.spec.ts

Production guardrails

  • Dependency and security audits

    pnpm audit.github/workflows/security-audit.yml

  • Security boundaries

    ESLint fetch and vendor import rulesapps/web/eslint.config.mjs

  • Observability

    Sentry capture · Pino loggingapps/web/sentry.server.config.ts

The CI workflow runs parallel jobs on every pull request. Any failing job fails the workflow.

Engineering workflow

Agents move faster when the architecture tells them where to go.

AGENTS.md, how-we-build guides, and ESLint rules encode ownership. The goal is predictable extension for humans and agents — not opaque automation.

  • Find extension points

    Feature modules, shared packages, and thin routes have defined ownership.

  • Follow conventions

    AGENTS.md, how-we-build guides, and ESLint rules encode architectural boundaries.

  • Verify before merge

    Lint, typecheck, test, and build commands match what CI enforces.

Agent context: AGENTS.md
apps/web/src/features/<name>/  → domain logicapps/web/src/app/              → thin routespackages/ui/                   → reusable primitives // Prohibited: raw fetch() in UI layers// Required: loading, empty, error, success states pnpm lint && pnpm typecheck && pnpm test
AGENTS.mdLn 8, Col 1

Reference

What ships with Atlas

A scannable map of each platform layer, what it provides, and where to explore it.

  • Application foundation

    Shell, auth, config, feature flags, and thin route conventions.

    apps/web, @/lib/auth, @/config

    Demo

  • Interface system

    Radix primitives, design tokens, themes, and application states.

    @atlas/ui

    Components

  • Data and validation

    OpenAPI contracts, API client, React Query hooks, and Zod forms.

    @/lib/api, useZodForm

    Data demo

  • Production reliability

    Testing, CI gates, observability, and security boundaries.

    Sentry, Pino, Playwright

    Observability demo

  • Engineering workflow

    Feature modules, AGENTS.md, docs, and contribution conventions.

    AGENTS.md, docs/how-we-build

    Platform overview

Ready to evaluate Atlas in a real product?

Break the demos, inspect the architecture, or bring the same platform discipline into your codebase.

Bring Atlas to your productOpen the demosUI system proof