Skip to main content
JaaS Skills is deliberately split into three codebases with no shared imports — only network calls — so each can be deployed, scaled, and released on its own schedule.

jaas-ui

Next.js 16 + TypeScript web app. Google/dev sign-in, search & browse, the drafts authoring workflow, tenant & sharing administration, guardrail policy management.

jaas-skills

Python/FastAPI registry backend. Owns search, drafts, publish, tenants, sharing, and the guardrail policy store. Filesystem-backed in this local-first build.

jaas-guardrails

Standalone content-safety scanning service. Owns the rule catalog and the engine that runs it. Reached only over REST — never imported.
Why a separate guardrails service, not a library? An earlier iteration vendored the rule catalog as a pinned git submodule, executed in-process. That still coupled the two codebases at the Python level. Moving the engine behind a versioned REST API means the guardrails service can add rule kinds or retune thresholds on its own release cadence — the registry never needs a code change to consume a newer catalog, only a network call.

Local stack

Both jaas-skills and jaas-guardrails are optional relative to jaas-ui — the web app runs standalone against whatever JAAS_API_URL points at, including a backend it didn’t start itself.