Objects

An object is a typed data model — the schema equivalent of a table. Objects are declared in code with the object() factory, attributes are chained on, and the result is registered so the platform syncs it automatically (API, validation, permissions, views all derive from it).

import { object, relation, status, text } from "@stndrds/schema";

export const CONTACT = object({ name: "contacts", label: "Contact" })
  .icon("user")
  .pluralLabel("Contacts")
  .labelExpression("{{ firstName }} {{ lastName }}")
  .attribute(text({ name: "firstName", label: "First Name" }).required())
  .attribute(text({ name: "lastName", label: "Last Name" }).required())
  .attribute(text({ name: "email", label: "Email" }).email())
  .attribute(
    relation({ name: "company", label: "Company" })
      .to("companies")
      .bilateral({ object: "companies", attribute: "contacts" }),
  )
  .attribute(
    status({ name: "status", label: "Status" }).options([
      { value: "lead", label: "Lead", color: "yellow", group: "idle" },
      { value: "active", label: "Active", color: "green", group: "in_progress" },
      { value: "churned", label: "Churned", color: "red", group: "finished" },
    ]),
  );

Three rules apply to every object:

• name is kebab-case, 63 characters max ("contacts", "order-items").
• labelExpression is required. It controls how records display across the platform.
• id is optional. Set it when fixtures or tests need a deterministic identifier.

Builder methods

Sealing an object

By default an object is extensible: end-users can add custom attributes through the UI, and sync leaves them alone. It only removes system attributes — ones your code declared and then dropped.

.sealed() changes that. On a sealed object, sync treats the code definition as the complete list and deletes every attribute missing from it — including custom ones users created, and the values those attributes held. Use it when an object must stay exactly as written, and use .tolerate() to keep specific names that predate the seal:

object({ name: "contacts", label: "Contact" })
  .labelExpression("{{ firstName }}")
  .sealed()
  .tolerate(["legacyRef"]);

standards pull reports unexpected attributes on a sealed object as drift and exits non-zero, so it works as a CI gate — run it before sync rather than discovering the deletion afterwards.

Label expressions

A label expression interpolates attributes with {{ attribute }}. Pipes transform the value: UPPER, LOWER, capitalize, and trim take no argument; prefix:"…", suffix:"…", wrap:"…", and default:"…" take one.

.labelExpression('{{ title }}{{ status | prefix:" · " }}');

Type inference

The whole point of defining schemas in TypeScript: record types are derived, never written by hand.

import type {
  ExtractRecord,
  ExtractRecordInput,
  ExtractRecordUpdate,
} from "@stndrds/schema";

type Contact = ExtractRecord<typeof CONTACT>;
// { firstName: string; lastName: string; email?: string;
//   status?: "lead" | "active" | "churned";
//   id: string; createdAt: Date; updatedAt: Date; metadata: Record<string, unknown> }

type ContactInput = ExtractRecordInput<typeof CONTACT>; // for create — no system fields
type ContactUpdate = ExtractRecordUpdate<typeof CONTACT>; // for update — all optional

Zero-import alternative: every builder exposes .$infer — CONTACT.$infer.record, CONTACT.$infer.create, CONTACT.$infer.update (and on attributes, .$infer.value and .$infer.definition).

Object builders also implement Standard Schema v1, so they plug directly into React Hook Form, tRPC, and anything else that speaks the spec.

Registries

Objects, views, and forms go into three global registries. The server module reads them at startup and syncs the schema automatically.

import { formRegistry, registry, viewRegistry } from "@stndrds/schema";

registry.register(CONTACT);
registry.register(COMPANY);
viewRegistry.register(CONTACT_DETAIL_VIEW);
formRegistry.register(ONBOARDING_FORM);

registry.register accepts a builder, a built definition, or an array of either. To inspect what is registered, use getByName, getByNameOrThrow, getAll, listNames, has, size, and summary().

Migrations

Renaming an attribute or changing its type is ambiguous from a plain diff, so declare it explicitly with .migration(version, cb):

object({ name: "contacts", label: "Contact" })
  .labelExpression("{{ firstName }} {{ lastName }}")
  .migration(2, (m) => m.renameAttribute("fullName", "displayName"));

Versions start at 2 and must be sequential — .build() rejects gaps. See Migrations for the full set of operations, what's applied automatically versus destructively, and how boot-time sync resolves each case.

Validation helpers

You can validate records outside the server, against the same rules the API enforces:

import { validateObjectOrThrow, validateDraft } from "@stndrds/schema";

validateObjectOrThrow(CONTACT.build(), values); // throws on invalid input
const result = validateDraft(CONTACT.build(), partialValues); // lenient, for drafts

For finer control, import per-type Zod validators from @stndrds/schema/validators/*.