Notes on content and the tools we build.

When teams adopt a traditional hosted headless CMS, they gain an editing UI but surrender direct database ownership. Every query must traverse a vendor-specific query language, and migrating or joining content with application tables requires external sync pipelines.

SCHMA takes a different architectural approach: your workspace connects directly to a PostgreSQL instance you own—whether hosted on Supabase, Neon, Railway, AWS RDS, or your own infrastructure. Connection credentials are encrypted at rest with AES-256-GCM in the control plane, while all content types, draft entries, published snapshots, and 768-dimension pgvector embeddings live in schma_* tables inside your database.

On Pro and Max workspaces, environment isolation maps directly to PostgreSQL search_path schemas, letting you test schema evolutions in staging before promoting changes to production.

Connecting an LLM directly to a production CMS is risky: missing required fields, malformed references, or unreviewed copy can immediately break downstream frontend builds.

In SCHMA, AI never publishes directly. Whether you are generating a batch of entries from a prompt or compiling a multi-step schema-and-content changeset, outputs land in a staged review workspace first. Every candidate item is validated against your content model’s 8 AI-supported field types, required constraints, and reference targets.

For multi-step orchestration on Pro and Max, SCHMA computes an RFC 8785 canonical JSON hash over the proposed changeset so what you approve in preview is cryptographically identical to what commits to your draft tables.

Editorial teams need freedom to iterate on drafts without risking accidental exposure on live sites. SCHMA enforces strict separation between working drafts and published snapshots: public Delivery API requests read exclusively from published records and emit CDN-ready Cache-Control headers (public, s-maxage=60, stale-while-revalidate=300).

When an editor needs to preview unpublished work in Next.js or Astro, generating a 24-hour entry-scoped preview token (?preview=TOKEN) automatically switches the response to private, no-store headers.

Once an Owner or Admin publishes an entry or release bundle, Pro and Max workspaces dispatch outbound events through a durable BullMQ worker queue signed with HMAC-SHA256 (x-schma-signature) and idempotency keys.