Your app changes every week. Your permissions shouldn't be left catching up.
import { defineCatalog } from "@alfiz/core"; export const catalog = defineCatalog({ namespaces: ["docs"], permissions: { "docs.files.read": { scopes: ["docs.folder", "docs.doc"] }, "docs.files.share": { scopes: ["docs.folder", "docs.doc"] }, "docs.files.delete": { scopes: ["docs.folder"] }, }, scopeTypes: { "docs.folder": { parent: null }, "docs.doc": { parent: "docs.folder" }, },});// A grant on the folder covers every doc inside it.const ok = await alfiz.can( { userId }, "docs.files.share", "docs.doc:123",);Every key is a compile-time type, and alfiz-verify fails the build on a surface you left ungated.
A catalog that lives in a console falls behind every time the application changes. Alfiz keeps permissions in the codebase that actually uses it.
Your permission catalog lives inside the application it governs.
CI publishes the catalog to your provider as a versioned contract.
Your team builds roles from published keys and assigns them to people, groups, or a place in the org chart.
No field here for a permission your code doesn’t enforce.
can() answers there, in-processOne application or a dozen, one database or one each, permissions crossing between them or strictly separate. Every combination below is a supported deployment, and a place deployments stay.
One application, or several that never reference each other. Two packages and the database you already run. Most deployments stay here.
Groups, roles and the reporting hierarchy live in one shared org root and sync down to every app. Run it yourself over the Provider API, or have Alfiz Cloud host it.
Each app pins to its own slice at construction, and on Prisma a driver query that forgot the partition doesn’t compile. The two never interact.
Grant an edge and a peer Application opens over the neighbour’s partition, running the owner’s validation and writing to the owner’s audit log. One partition can home the org for all of them.
In all four, can() answers in your process, from your own tables.
An agent has two lines to get right when it adds a permission, one search to find every place one is spent, and a verifier that fails the build when it misses a gate.
Two lines add a permission: one in the catalog, one at the call site. There is nothing else an agent has to find first.
// ...catalog.ts "docs.files.export": { scopes: ["docs.folder"] }, // app/actions/export.tsawait alfiz.requirePermission( { userId }, "docs.files.export", scope,);One search returns the declaration and every gate that depends on it. The same property lets alfiz-verify work without a type-checker.
$ grep -rn "docs.files.share" src/ authz/catalog.ts:14 "docs.files.share": { scopes: [...] }docs/[id]/page.tsx:22 snap.can("docs.files.share", scope)actions/share.ts:9 requirePermission(p, "docs.files.share")components/nav.ts:31 { permission: "docs.files.share" }An agent works on the task in front of it and misses the surface next door. alfiz-verify fails the build when a route ships without a gate.
A surface is not done until all four points hold:
Gated before a row is fetched.
Only items the principal matches are rendered at all.
Gated before any work. The step that gets skipped, so it errors.
Gated at the scope of the thing it acts on.
$ alfiz-verify ✖ [ungated-action] app/actions/export.ts:14 exported server action "exportDocument" contains no gate ✖ [visibility-as-gate] app/actions/share.ts:15 canAny() is a visibility affordance, never a gate ⚠ [unreferenced-leaf] "docs.files.read_history" declared, but referenced by no gate or nav itemInstall two packages, declare a catalog, wire the driver you already have, and call can().