# Alfiz

## Docs

- [Alfiz: Scoped Permissions for TypeScript, an Introduction](https://docs.alfiz.dev/introduction.md): Alfiz is scoped permissions for TypeScript applications: declared in code, verified in CI, and checked in your own process against your own database.
- [Get Started with Alfiz: Install, Define, and Check](https://docs.alfiz.dev/quickstart.md): Install Alfiz, define your first permission catalog, wire a storage driver, grant access, and run your first can() check, all in under ten minutes.
- [Core Concepts: How Alfiz Models Authorization in TypeScript](https://docs.alfiz.dev/core-concepts.md): Learn Alfiz's five semantic building blocks (catalog, grants, scopes, subjects, and checks) and how they compose to model any access control policy.
- [Migrating an Existing RBAC System to Alfiz](https://docs.alfiz.dev/migrating.md): Move a role-column or hand-rolled RBAC system onto Alfiz: map your tables onto the grant row, split the roles that grant globally, import in bulk, and wire the lifecycle paths.
- [Alfiz Catalog: Permissions, Scopes, and Navigation](https://docs.alfiz.dev/catalog/overview.md): The Alfiz catalog declares every permission, scope type, and navigation entry in code, verified at compile time and never configured in a dashboard.
- [Declaring Alfiz Permissions: Keys, Kinds, and Wildcards](https://docs.alfiz.dev/catalog/permissions.md): Learn Alfiz permission declarations: dotted keys, read vs. action kinds, destructive flags, scope wiring, and forward-inclusive wildcards.
- [Alfiz Scope Types: Defining Your Resource Hierarchy](https://docs.alfiz.dev/catalog/scope-types.md): Scope types define the resource hierarchy your permissions apply to, from a flat global scope to deeply nested folder-and-document trees.
- [Wiring Navigation Visibility to Permissions in Alfiz](https://docs.alfiz.dev/catalog/navigation-wiring.md): The Alfiz catalog carries navigation entries that control which menu items render for each user, based on their actual permissions evaluated client-side.
- [Importing Permissions From Another Application](https://docs.alfiz.dev/catalog/imports.md): Declare the permissions your application references but does not own, whether they come from Alfiz Cloud or a federated application, and keep the same typed keys, verified call sites, and grants you have for your own.
- [Check Shapes: can, canAny, can.fresh, and require](https://docs.alfiz.dev/enforcement/check-shapes.md): Alfiz exposes two check shapes: can() for gates and canAny() for visibility affordances, plus can.fresh() to bypass caches on destructive actions.
- [The Four Enforcement Points Every Application Surface Needs](https://docs.alfiz.dev/enforcement/four-points.md): Alfiz requires checks at four points (page, navigation, server action, and conditional UI) to fully protect every surface in your application.
- [The Condition Seam: Attributes Without a Rules Engine](https://docs.alfiz.dev/enforcement/conditions.md): Declare that holding a permission is necessary but not sufficient. Alfiz enforces that your predicate is present, at runtime and in CI, without ever evaluating your attributes itself.
- [Caching and Staleness: What Your Revocation Bound Actually Is](https://docs.alfiz.dev/enforcement/caching.md): Alfiz caches closures, never decisions. Learn the default TTL bounds, how to tighten them across processes with the event log, and when to reach for can.fresh.
- [Static Verification: Catch Ungated Actions with alfiz-verify](https://docs.alfiz.dev/enforcement/static-verification.md): Run alfiz-verify in CI to catch ungated server actions, misused canAny() calls, and catalog violations before they reach production.
- [Permission Metrics: Counting Checks and Attributing Them to Grants](https://docs.alfiz.dev/enforcement/metrics.md): Emit a structured observation from every check, pipe it to OpenTelemetry or read it directly, and store per-grant usage so you know what breaks before you revoke.
- [The Audit Log: Schema, Retention, Export, and Tamper-Evidence](https://docs.alfiz.dev/enforcement/audit.md): Every write lands with an audit entry, structurally. This page specifies the record schema, the retention posture, the export surface, and the optional hash chain.
- [Grants, Revokes, and Effective Access](https://docs.alfiz.dev/access/grants-revokes.md): Learn the grant tuple that powers every access decision in Alfiz (subject, pattern, scope, expiry) and how personal revokes override group grants.
- [Understanding Subjects and Subject Closures in Alfiz](https://docs.alfiz.dev/access/subjects-closures.md): A subject is anything that can hold a grant. Alfiz checks the full transitive subject closure: user, groups, ancestors, orgs, and everyone.
- [Scopes and Resource Hierarchies in Alfiz Explained](https://docs.alfiz.dev/access/scopes-hierarchy.md): Scopes let you grant permissions at any level of your resource hierarchy (folder, document, or global) and Alfiz walks ancestor chains at check time.
- [Roles and Groups: Organizing Permission Assignments](https://docs.alfiz.dev/access/roles-groups.md): Roles are named permission bundles. Groups are cohorts of users. Together they let you grant access to many people with a single row.
- [Separation of Duties: Declarative Exclusions, Union-Only Evaluation](https://docs.alfiz.dev/access/separation-of-duties.md): Declare mutually exclusive permission sets in the catalog. Alfiz reports every principal who crosses them, and can reject the grant that would, without a deny entering the hot path.
- [Access Requests: User-Initiated Permission Workflows](https://docs.alfiz.dev/requests/overview.md): Alfiz access requests let users propose a grant tuple with a justification and route it through configurable approval stages before writing any access.
- [Configuring Access Request Approval Policies in Alfiz](https://docs.alfiz.dev/requests/approval-policies.md): Approval policies define who approves access requests via auto-approval predicates, named approver roles, or management-layer routing, and in what order.
- [Alfiz Standalone: Complete Authorization, One Application](https://docs.alfiz.dev/growth/standalone.md): Two npm packages and your own database, with the complete Alfiz feature set and no external service on your request path.
- [Alfiz Cloud: Add Hosted Administration to Your Application](https://docs.alfiz.dev/growth/linked.md): Link your standalone Application to Alfiz Cloud to unlock the Dashboard and admin seats, without federating or moving any authority.
- [Federating Applications for Cross-App Authorization](https://docs.alfiz.dev/growth/federated.md): Federation moves the org root to Alfiz Cloud, unlocking cross-application role composition, a shared catalog registry, and provisioned integrations.
- [Access Reviews: Entitlement Export, Wildcard Drift, and the IGA Path](https://docs.alfiz.dev/operations/access-reviews.md): The computed per-user entitlement rollup a reviewer signs, the drift report that keeps forward-inclusive wildcards reviewable, and the write-back path an external IGA uses.
- [Directory Sync and Row Reconciliation: Closing the Silent Gaps](https://docs.alfiz.dev/operations/sync-reconciliation.md): Authoritative directory imports that actually deprovision, and the reconciliation report that finds rows referencing users and resources your application deleted.
- [Multi-Tenancy: The Topologies and Their Trade-offs, Honestly](https://docs.alfiz.dev/operations/multi-tenancy.md): Alfiz has no tenant primitive by design. This page gives you the two supported topologies for serving many customer organizations, and the honest costs of each.
- [Shared-Store Topologies: Partitioned Storage and the Mesh](https://docs.alfiz.dev/operations/shared-store.md): Run several Alfiz Applications against one database. Partitioned storage gives strict isolation with zero interaction; the mesh adds granted read/write access between partitions, live imports, and an org partition.
- [The Performance Envelope: Measured Shapes, Stated Methodology](https://docs.alfiz.dev/operations/performance.md): Reproducible benchmark numbers for cold closure supply and warm checks at 10⁴–10⁶ grant rows, with the methodology and its caveats stated plainly.
- [Alfiz Cloud: The Managed Provider for Hosted Administration and Federation](https://docs.alfiz.dev/cloud/overview.md): Alfiz Cloud is the managed Alfiz provider: the Dashboard and Federation, two features over one implementation, with runtime checks untouched in every topology.
- [Connecting Your Application to Alfiz Cloud: The Provider API](https://docs.alfiz.dev/cloud/provider-api.md): Mount the provider handler from @alfiz/application, register your Application in the Dashboard, and verify the connection. Administrative traffic only, never on the check path.
- [The Alfiz Cloud Catalog Registry: Namespaces, Versions, and Tombstones](https://docs.alfiz.dev/cloud/registry.md): The registry holds each application's published catalog as a versioned, namespaced contract: additions need no coordination, removals are tombstones, and drift is reported by name.
- [Promotion, Merges, and Demotion: Moving the Alfiz Org Root](https://docs.alfiz.dev/cloud/promotion.md): The runbook for moving the org root to Alfiz Cloud: validation, the atomic authority flip, second-application merges, and the way back down.
- [Alfiz Cloud Metering and Caps: What Is Billed and What Never Is](https://docs.alfiz.dev/cloud/metering.md): The billed dimensions, hard caps per dimension, and why check volume is not among them and will not become one.
- [createAlfizClient: Initialize the Alfiz Client Instance](https://docs.alfiz.dev/api/create-alfiz-client.md): createAlfizClient(options) creates a typed AlfizClient bound to a catalog and provider. All check methods are typed against the catalog's permission keys.
- [can() and require(): Authorization Gates](https://docs.alfiz.dev/api/can.md): can(principal, key, scope?) returns a boolean authorization decision. require() is the throwing form. can.fresh() bypasses the closure caches.
- [canAny() and requireAny(): Visibility Affordances](https://docs.alfiz.dev/api/can-any.md): canAny(principal, pattern) tests whether a principal holds any permission matching a pattern. Visibility affordance only, and never an authorization gate.
- [snapshot(): Batch Checks in a Single Round-Trip](https://docs.alfiz.dev/api/snapshot.md): snapshot(principal) fetches all closures and grants in one provider round-trip, returning an AlfizSnapshot with synchronous can() and canAny() methods.
- [explain(): Understand Why Access Was Granted or Denied](https://docs.alfiz.dev/api/explain.md): explain(principal, key, scope?) returns a full CheckExplanation showing which grants, roles, and closures produced the authorization decision.
- [grantedScopes() and holds(): Listing Utilities](https://docs.alfiz.dev/api/granted-scopes.md): grantedScopes(principal, key) returns the set of scopes where a principal holds a permission: the primitive for building efficient listing queries.
- [Metrics API: Observations, Sampling, Aggregation, and Usage Reads](https://docs.alfiz.dev/api/metrics.md): Reference for CheckObservation, the metrics client option, createMetricsAggregator, otelMetricsObserver, createProviderMetricsSink, the usage reads, and revocationSafeguard.
- [createApplication: Alfiz Local Provider Setup Guide](https://docs.alfiz.dev/api/create-application.md): createApplication wires catalog, storage, and ancestry into the Alfiz Application, a fully local authorization engine with no external dependency.
- [Alfiz Storage Drivers: Memory, Prisma, and MongoDB Reference](https://docs.alfiz.dev/api/storage-drivers.md): memoryDriver() for tests, prismaDriver() and mongoDriver() for production. All satisfy the StorageDriver interface, so you can swap one for another without changing any application logic.
- [Alfiz Sessions: createSession and View-As Preview](https://docs.alfiz.dev/api/session.md): createSession() makes a typed per-request session from a verified user ID. Covers view-as admin preview, service principals, and cookie serialization.
- [defineCatalog(): Build Your Alfiz Permission Tree](https://docs.alfiz.dev/api/define-catalog.md): defineCatalog(input) builds a typed catalog: the source of truth for permission keys, scope types, navigation, and compile-time KeyOf/PatternOf unions.
- [Alfiz Catalog TypeScript Types: CatalogInput Reference](https://docs.alfiz.dev/api/catalog-types.md): Reference for CatalogInput, PermissionLeafInput, GroupInput, ScopeTypeInput, NavItemInput, and the derived KeyOf and PatternOf types used throughout Alfiz.
- [alfiz-verify CLI: Static Permission Verification](https://docs.alfiz.dev/api/alfiz-verify-cli.md): alfiz-verify checks typed permission keys, gate coverage, gate shapes, and catalog conventions. Run in CI to make ungated server actions a build failure.
- [alfiz-verify.config.json: Configuration Reference](https://docs.alfiz.dev/api/verify-config.md): alfiz-verify.config.json reference: catalog path, scan directories, additive gate names, visibility names, server patterns, and client-reach guards.
- [The Alfiz Cloud REST API: Authentication, Parity, and Error Envelope](https://docs.alfiz.dev/api/cloud-overview.md): How to authenticate against the Alfiz Cloud REST API, why it has full parity with the Dashboard, and how error names map to HTTP statuses.
- [Alfiz Cloud API Endpoints: The Complete REST Surface](https://docs.alfiz.dev/api/cloud-endpoints.md): Every Alfiz Cloud endpoint under /api/v1, grouped by area, with the gate and semantics of each, over the same server functions the Dashboard calls.
- [Alfiz Changelog: Every Release from 0.2.0 to 0.8.1](https://docs.alfiz.dev/changelog.md): Every Alfiz release, from 0.2.0 to 0.8.1. What shipped, what changed, and what broke across @alfiz/core, @alfiz/application, @alfiz/prisma, @alfiz/mongo, and @alfiz/verify.