What we’ve shipped, and when.

August hardened how teams get into Owlie and how they stay in when an identity provider has a bad day, and it gave administrators safer ways to make sweeping changes. It also gave AI-assisted investigations a permanent home instead of a throwaway answer.

Single sign-on

• SAML 2.0 service provider: register Owlie using IdP metadata or manually entered SSO details and signing certificates
• Domain and trust controls: restrict accepted email domains, control whether asserted email is trusted, and optionally provision identities just in time
• Policy-consistent flow: sign-in starts from Owlie and continues through the tenant’s normal MFA and post-login policy steps

Access recovery

• Administrator invitations: invite another administrator even when normal login is SSO-only
• Personal one-time recovery codes: restore a local Secure Password sign-in path for a bound administrator during an IdP outage, without creating a session, changing roles, or bypassing the tenant’s authentication policies

Owlie Studio

• Durable investigation canvas: turn AI answers into arranged identity and resource cards and carry selected context into the next question
• Always-current cards: each card reloads live information through the viewer’s existing permissions, so an investigation stays accurate as access data changes
• Voice input: hold to speak a prompt, review the transcription in the normal composer, and send it through the same assistant workflow as a typed request

Identity operations at scale

• Previewed bulk changes: target identities by explicit set, group, role, directory filter, or current access, then preview proposed attribute changes and their exclusions before running a tracked job
• Reviewable job status: completed, failed, and attention-required identities are exposed so broad directory updates stay auditable
• Emergency lifecycle overrides: immediately set an identity’s lifecycle state with a recorded reason, including a termination that disables Owlie access and starts the normal policy-driven revocation path; clearing the override returns the person to their directory-derived state

Also in this milestone:

• Guided tenant setup: a progress-based path across people, sign-in, resources, existing access, lifecycle policies, reviews, and rollout, with governance posture and assign-or-dismiss steps shown alongside each item
• Smoother first MFA enrollment: enroll a first authenticator or passkey for up to 30 minutes after signing in with no extra re-auth prompt, while adding a second factor still requires fresh verification and step-up prompts now name the specific action in plain language

The through line: high-impact changes you can preview and reason about before they run, and sign-in you can recover without weakening policy.

July brought an AI layer to Owlie that stays inside each user’s own permissions, deeper governance you can hand off and automate, and provisioning that can play out over hours or days instead of all at once. Three managed connectors landed alongside.

AI assistant and automation

• In-dashboard admin assistant: inspect Owlie data, answer governance questions, render stats, tables, and entity cards, and take approved actions under the signed-in user’s permissions
• Interactive workflows: embedded forms, secure integration setup and OAuth connection cards, and explicit approval controls in chat, with credentials and tokens kept out of the conversation
• Automation SDK and MCP endpoint: typed TypeScript access for developers and external AI clients across identity, access, policy, sync, provisioning, tickets, and settings
• Slack self-service: users ask questions and file requests in direct messages under their own access rights, channel mentions give thread-bound help without personal data, and admins control DM and channel availability independently

Delegation

• Vacation and assistant delegation: any identity can name a delegate, for a vacation window or as a standing arrangement, who can see, be notified about, and act on their approval, fulfillment, and access-review items
• Nothing is reassigned: the owner keeps their queue and their accountability, both people are notified, and every delegated action records who really acted
• Separation of duties enforced: a delegate cannot approve or fulfill anything for themselves
• Configurable by the user, an admin, or anyone in the management chain, with a governance view of everyone a person is a delegate for

Provisioning that unfolds over time

• Timed hooks: render one operation as a sequence with timed pauses, event pauses that wait for an external or admin resume within a bounded timeout, and follow-up operations against the same assignment
• Multi-stage offboarding authored on the resource profile (disable now, archive later, delete later), guard-first so a rehire or any newer operation cancels a pending sequence cleanly
• Gated provisioning: park an operation until an external identity-proofing callback resumes it
• Resource bundles, tasks, and seat capacity: bundles deliver fixed component access through one request, tasks run the request-to-fulfillment workflow without creating durable access, and seat capacity prevents over-allocation while showing availability before request

Access requests and reviews

• Provisional and emergency access: provisional access before normal approval completes, with later ratification and automatic removal if rejected; emergency access limited to approved groups and a fixed duration, marked in the catalog, and followed by resource-owner certification
• Personal attestations: campaigns ask access holders whether they still need expiring access, where a keep decision extends eligible access under resource policy while no-response or revoke lets it expire, kept distinct from formal certification evidence
• Reviewer experience: failed decisions stay staged with per-item retry messages, users are blocked from deciding their own access with explicit feedback, and configured reviewer rules resolve to their actual assignees so routing is visible
• Timed request follow-up: due dates, reminders, escalation, expiration of abandoned standard requests, and authorized due-date extensions

Connectors

• Managed GitHub organization: connect through an Owlie-managed GitHub App to sync and manage organization membership, organization roles, and direct teams, track pending invitations, and react to installation lifecycle changes, with no repository access or customer-managed App credentials
• Managed Slack workspace: connect through an Owlie-managed app to sync users and user groups, manage SCIM lifecycle where supported, and deliver notifications; users link identities, use a personalized App Home, and act on request, approval, fulfillment, and review cards in Slack, with Enterprise Grid governing workspace membership and enterprise admin roles
• Generic SCIM 2.0: connect configurable SCIM providers for users, groups, and memberships, with guided presets and setup instructions for AWS IAM Identity Center, Databricks account SCIM, Snowflake, and GitHub Enterprise Managed Users

Operations and workflows

• Administrative operations dashboard: a live view of setup progress, action queues, expiring and scheduled access, policy and provisioning convergence, integration and gateway health, unresolved identities, security posture, and recent activity, with direct links and per-user widget layout
• Admin alerts and history: track durable issues in one workspace, filter by status, severity, or kind, inspect repeat occurrences and related context, and record a resolution note, with alerts closing automatically when a condition clears
• Escalation for stalled work: request timing and access-review timing can raise durable admin alerts for stalled approvals, fulfillment, or overdue certification and attestation items without changing their reviewers
• Identity-change reactions: watch selected identity attributes and value transitions, then run published event-action functions or submit provisioning operations on a match, with create, edit, enable, disable, filtered lists, and execution history

Also in this milestone:

• Identity-reference sync and provisioning: model account-to-account references such as managers, resolve inbound reference values into identity-reference attributes, and write outbound references with deferred backfill when the referenced account is created or discovered later
• Stronger MFA and SSO safeguards: optional MFA still challenges enrolled users, admin-scoped MFA follows owner and admin roles with a configurable group override, OAuth account linking requires a verified provider email, and OTP and backup-code verification use tighter rate limiting
• Lifecycle policy packaging: package employee and time-limited contractor birthright policies into policy groups, preview each policy before activation, resume an interrupted setup without duplicates, and disable non-system policies together, with a zero-handover termination package keeping default termination protection visible
• Unmatched-account review queue: park one durable decision per flagged external account and summarize the open queue with an admin alert, then assign an existing identity, create and assign a new one, track removal in the source, or accept an intentional orphan with a required note
• Plan usage and capacity visibility: active usage, effective plan limits, enforcement state, daily usage history, monthly activity, and engine capacity, making it clear when a limit will warn, block, or queue work

The thread this month: whoever acts, a person, a delegate, the assistant, or an external client, acts under the same permissions and leaves the same record.

June focused on turning identity data into enforceable governance: clearer graph visibility, stronger policy automation, richer review workflows, and more ways to connect Owlie to real systems.

Policy-driven access

• Grant policies: versioned rules match identities by governed predicates, preview rollout impact, apply changes through provisioning, and explain why access exists
• Deny policies: block, revoke, route, or park access for review, with request-time warnings and exception approvals
• Time-bound access: requests and provisioning can carry start and end times for scheduled activation, automatic expiration, and auditable revocation states

Access reviews

• Campaigns: create ad-hoc or reusable reviews scoped by users, resources, Grants, and grant types, with size and reviewer-load previews
• Reviewer workspace: assigned review queues, decision context, reason requirements, bulk decisions, and real-time updates
• Remediation and evidence: outcomes can route through connectors, manual tickets, virtual paths, or functions, with holds, extensions, timelines, item evidence packets, and downloadable campaign exports

Identity graph and attributes

• Graph explorer: inspect synced, provisioned, manual, and derived records, search nodes, view neighborhoods, and trace assignment links or stale external state
• Attribute precedence: manage built-in and custom identity attributes with ordered sources, manual overrides, self-service visibility, and rule-derived lifecycle state

Connectors and private systems

• Connector builder: scaffold draft connectors from OpenAPI definitions, get AI help for schemas, handlers, errors, and mappings, then run conformance checks and handler tests before publishing
• Integration catalog: expanded coverage across identity, HR, productivity, CRM, finance, support, marketing, collaboration, storage, and accounting systems
• On-prem gateway: enroll tenant gateways, monitor live state and versions, bind integrations to a gateway, and run private-network connectors such as Active Directory, LDAP, databases, SAP HANA, and flat-file feeds

Security and platform controls

• Owlie-hosted OIDC IdP: manage OAuth and OIDC clients, redirect URIs, scopes, PKCE, refresh tokens, secret rotation, and signing keys
• Tenant audit log: query tenant-scoped events by namespace, type, outcome, and time cursor without exposing secrets
• Notification center: in-app notifications, unread counts, read and dismiss actions, recent activity, and admin delivery policies by transport and category

May focused on making access changes easier to explain, integrations easier to extend, and admin workspaces faster to navigate.

Provisioning provenance

• Access source snapshots: assignment and provisioning changes now record whether access came from a request, sync job, admin action, policy, workflow, or test run
• Investigation links: assigned-resource audits and provisioning operation views now expose linked provenance for clearer access reviews and incident follow-up

Custom connectors

• Tenant-scoped authoring: admins can create custom connectors directly for their tenant
• Guided builder: draft connector definitions and operation handlers can be edited in one structured flow
• Version publishing: readiness is tracked before publish, published versions are immutable, and a new draft stays open for the next change

Admin workspaces

• List navigation: core identity, access, workflow, integration, sync, and provisioning areas now support field-aware search, per-column filters, sortable columns, and column visibility controls
• Workspace layouts: compact and grid views, split list-detail navigation, inspector panels, and recent-item shortcuts make repeat admin work faster to scan and resume

April deepened the request-to-fulfillment path: teams can capture the right access details, route approvals through real review patterns, and automate provisioning when built-in connectors are not enough.

Access requests and approvals

• Resource-specific forms: collect structured request details with pickers, dates, toggles, and file fields
• Request snapshots: submitted form data is stored with the request, shown to approvers, and passed into automation
• Multi-stage approvals: versioned flows with named stages, all/any/N-of-M rules, app-owner routing, and handling for superseded or canceled work

Function-based provisioning

• Custom fulfillment: published Functions can complete approved grants or revocations using request form data, identity context, resource context, and desired account state
• Function authoring: admins can add external packages, save drafts with revision checks, and see build feedback
• Secrets and logs: version-scoped secrets, published secret rotation, and bounded runtime logs from execution history
• Operation control: admins can cancel in-flight or failed provisioning operations with reasons, pending-assignment cleanup, workflow notification, and live status updates

Governance and security

• Granular permissions: tenant-wide permission catalog behind system and custom roles, enforced across admin surfaces
• Role assignment guardrails: admins cannot grant permissions they do not hold
• Permission visibility: dashboard matrix shows which roles grant each permission
• Self-service security: end users can view enabled login and MFA methods and change their password when supported

End-user workspace

• Ticket detail view: end users can inspect submitted request form data and act from one focused screen
• Queue controls: search by beneficiary or request number, sort by age, filter, and group work
• Ticket actions: approve, reject, complete, or reassign from the ticket workspace

Also in this milestone:

• Governed files: tenant-scoped uploads with size and type restrictions, metadata validation, owner binding, and authorized downloads

This release adds access-review campaigns and the in-app connector builder.

Access reviews

• Certification campaigns with configurable scope — by user set, by resource set, or both
• Reviewer accountability — each reviewer sees only their slice of the campaign
• Completion tracking + exportable artifacts (scope, reviewers, decisions, resulting changes)
• Revocations that flow from a review run travel the same provisioning pipeline as any other access change
• Campaign artifacts attach to the evidence layer for audit

In-app connector builder

• A web UI inside the admin dashboard for building new connectors against internal or long-tail systems
• Configuration-driven: auth (OAuth 2.0, API key, JWT, or custom flow via Function), entity schemas, field mappings via OXL
• Functions fill in the behaviors that don’t fit a config field — a few lines of TypeScript, sandboxed, version-managed
• AI assistance where the target system has public documentation — schema inference, auth detection, boilerplate scaffolding

Two additions this release: access grants that carry their own expiry, and Function-backed actions on the screens where admins already work.

Time-bound access

• A request or a provisioning operation can carry an access window — a start time, an end time, or both
• Future-dated grants stay scheduled until their start time, then provision through the normal pipeline
• Time-limited grants revoke automatically when the end time arrives — the same provisioning path, the same audit trail, no request left open waiting on a human to remember
• Activation and expiry run on per-assignment timers, with a periodic sweep as a backstop so a missed timer still closes the window
• Windows are one-shot start/end timestamps today — recurring schedules and resource-level max-duration policy are still ahead

Custom actions

• Function-backed quick-action buttons on the identity and request screens
• Each action runs a published Function on demand from the entity’s Quick Actions menu, with a server-built actor context and an audited execution record
• Gated by role, with optional confirmation before it runs
• The result comes back typed — the dashboard renders it as a toast, a refresh, or a navigate
• Extensibility at the UI surface, backed by the same Function runtime as approval and fulfillment logic

January focused on making access administration more explicit while giving end users a durable dashboard preference.

Role management

• Tenant roles: system roles are scoped per tenant and exposed through GraphQL for listing and assignment workflows
• Identity access: admins can assign and revoke roles directly on identities
• Group-based access: roles can be assigned to groups, with inherited roles visible through group membership
• Admin dashboard: role browsing and membership management now have dedicated pages

End-user dashboard

• Theme preference: users can switch themes from the dashboard header
• Persistence: selected themes are saved so the dashboard keeps the user’s preferred UI mode

Real-world identity attributes come from multiple systems — HRIS for name and title, directory for email, custom apps for cost centers. Owlie now resolves those sources using configurable priorities.

Identity attribute governance

• Per-attribute source-of-truth rules (e.g. email prefers Workday, falls back to Google Workspace)
• Multi-system priority fallback when the preferred source is missing or stale
• Full provenance — Owlie tracks which system each value came from
• Configured policies resolve conflicting values

Owlie Expression Language (OXL)

• A small DSL for value mappings, attribute transforms, and fallback rules
• Used throughout the platform — attribute maps, approval policies, connector schemas, fulfillment rules
• Safe evaluation — no arbitrary code execution surface
• Zero-config where possible — inline inside configuration

This release adds tenant-scoped encryption and provisioning evidence.

KMS

• Tenant-scoped encryption for every secret — connector credentials, OAuth client secrets, Function secrets, settings secrets
• Context-bound decryption: ciphertext bound to tenant + declared usage context. Cross-tenant or cross-workflow replay fails closed at decryption time
• Structured decryption justifications — opaque secret reads are not allowed. A service requests decryption with a structured reason, and it’s recorded
• Tenant key rotation: future writes move to the new key version; old ciphertext stays decryptable with its original version until a caller re-encrypts
• AWS KMS anchors the service’s top-level trust; tenant-level operations are served through the internal KMS layer
• Per-tenant key creation on first use — no manual setup step before storing the first secret for a tenant
• Audit trail of every encryption, decryption, and rotation with caller identity and declared purpose

Provisioning evidence

• Per-step execution journal, with retried and superseded states preserved (not overwritten)
• Actual-state snapshot persisted alongside applied-version advance — in the same transaction
• Identity graph projection written into the shared graph atomically with apply
• Callback delivery to originating services with target-version + applied-version + correlation ID
• Real-time UI events on the tenant channel so dashboards reflect operation status without polling

October tightened the request path from both sides: admins can decide how manager approvals recover from missing data, and end users get a clearer place to follow what they asked for.

Access requests

• Manager fallback settings: tenant admins can choose whether a request errors when the beneficiary has no manager or gets reassigned to a configured user or group
• Tenant settings foundation: a tenant-scoped settings store now backs request policy choices and is exposed through the admin Settings UI

End-user dashboard

• Request browsing: improved navigation, responsiveness, and UI polish make active and past requests easier to scan
• Request details: clearer request-detail UX helps users track status and understand request context

Connector coverage expands from workforce identity to customer identity and HRIS.

Auth0

• Sync: users, organizations, roles
• Provision: full account lifecycle + Grants (organization memberships, role assignments)

BambooHR

• Sync only: employee records — HRIS lifecycle signals and identity attributes
• BambooHR supplies HR events that drive provisioning in other systems

Also in this milestone:

• Connector SDK formalized: lifecycle hooks, HTTP destination policy, response parsing contracts, error taxonomy mapping
• Membrane-based manifest generator scaffolded — parses existing connector bundles into draft Owlie manifests with inferred entities, schemas, and auth hints (not live at launch; future-ready)
• Catalog quality gates: published definitions, schema partitioning, and implementation verified together at install time
• Upgrade-compatibility checks during manifest reconciliation — catalog drift surfaces early, not after a partial integration goes live

Four native connectors total: Google Workspace, Microsoft Entra ID, Auth0, BambooHR.

Functions let tenants add TypeScript logic to Owlie workflows.

• Four function modes: endpoint handlers, approval logic, fulfillment logic, custom admin actions. Each starts from a purpose-specific template
• Single editable draft per function with inline build feedback — save incrementally, retry until runnable
• Publish-to-live with new-draft-on-publish: live code stays immutable while editing continues separately against a fresh draft
• Rollback to any prior live version without rebuilding from scratch
• Version-scoped secrets: add and remove on drafts; rotate values on published versions without republishing code
• Allowlisted outbound network: no general-purpose internet by default. When enabled, limited to explicitly approved public hostnames (including subdomains)
• Fail-closed runtime validation: missing, inconsistent, or non-publishable releases don’t execute
• Execution history with outcome, timing, version identity, and bounded captured console output
• Version-targeted test execution for controlled inspection without changing what’s live
• Function purpose is fixed at creation time

Owlie sync compares observed access with intended state and applies your configured policy when they diverge.

• Connector-driven sync coverage — sync jobs are created automatically from connector manifests
• Flexible run scheduling: scheduled full syncs, incremental where the source supports change markers, and manual-only for operator control
• Dependency-aware relationship ordering — memberships wait for their object runs to finish first, so relationships land against a complete graph
• Policy-driven drift handling: adopt, flag, preserve, or ignore — configurable per assignment
• Stale-not-delete: provisioned records that disappear from a sync run are marked stale, not hard-deleted. Protects against sync-feed hiccups wiping records
• Authoritative full-state cleanup: soft-delete for sync-only objects that disappeared; preserve-with-stale-flag for provisioned objects
• Identity matching + creation: match-and-update, create-if-unknown, or flag-if-ambiguous — per sync-job configuration
• Assignment linking: adopt, ignore, or flag on match-without-existing-assignment
• Detailed run history with phase progression, checkpoints, record-level outcomes, and archived long-term storage
• Actionable failure reporting — operators can usually tell from the error whether they need to fix credentials, scopes, config, or retry

The shared graph_nodes / graph_edges model went in with sync and is where both sync and provisioning write. Single source of truth for “who has what.”

June focused on Owlie’s first real product entry points: a public path to request a tenant, an admin workspace shell, and an end-user home for self-service.

Public tenant signup

• Signup request: owlie.com now collects email, name, company, and desired subdomain
• Validation: company details are checked before submission
• Completion state: successful tenant signup requests show a confirmation

Admin dashboard

• Admin shell: the initial /admin experience now includes a responsive header, navbar, footer, and sidebar
• Navigation: sidebar structure is in place for future admin workflows
• Preferences: theme toggle support is available in the admin workspace

End-user dashboard

• Landing route: the first end-user dashboard route is now available
• Self-service foundation: dedicated areas are in place for requests, tasks, and reviews
• Navigation: floating navigation gives end users a starting point for moving through their work

The first connectors cover Google Workspace and Microsoft Entra ID, common workforce identity systems for mid-market teams.

Google Workspace

• Sync: users, groups, admin roles, org units, domains
• Provision: full account lifecycle + Grants (groups, admin roles)
• Custom actions: move a user to another org unit, sign a user out of active sessions

Microsoft Entra ID

• Sync: users, groups, group membership
• Provision: full account lifecycle + Grants (group membership)

Also in this milestone:

• Versioned integration catalog — installable manifests per connector, resolved at install / upgrade time
• Standardized connection setup: OAuth 2.0 authorization code, client credentials, JWT bearer, and API key patterns
• Host-managed provider credentials for Google Workspace — a shared OAuth app, so tenants don’t each register their own
• Per-field schema semantics: identifier, read-only, sensitive, immutable, create-only-writable, required-for-action
• Entity schema validation at resolve time — bad desired state is rejected before the target system is ever called

The provisioning engine is now live.

• Typed operation intents: provision, enable, disable, revoke, update attributes, add/remove/set Grants — each with per-action payload validation
• desired_version and applied_version per assignment — concurrent or retried operations converge by version
• Pre-flight + no-re-create invariant: when observed state is unknown or stale, read first, then plan. Once adoption happens, account creation cannot re-enter the plan. Protects against the classic duplicate-account-on-retry failure mode
• Idempotent submission with caller-supplied or auto-derived keys (scoped to tenant + identity + resource + action)
• Operation-centric retry: one idempotent lever handles every stuck state
• Structured connector error taxonomy: auth errors never retry; rate limits always do; others follow connector guidance. Retry logic is consistent across integrations
• Per-step execution journal: status, timing, error context, superseded markers for plan changes
• Atomic apply + graph projection in one transaction — “what we think we applied” cannot drift from “what we recorded as applied”
• Callback delivery back to the originating service on terminal states, with target-version, applied-version, correlation ID, and any final error
• Real-time operation status events on the tenant channel

request-svc — the request-workflow coordinator — shipped. It accepts a submitted request, resolves approval paths, opens approval work for humans, hands approved resources to fulfillment, and aggregates everything into a single request-level outcome.

• Multi-resource requests with per-resource outcome tracking: a single request can end in full success, full rejection, or partial success
• Sequential approval chains: advance only after the current step is approved or reassigned
• Routed tickets for human approvers: named users, groups, or the beneficiary’s manager
• Manager-fallback routing for identities with missing or invalid manager data
• Policy-driven approval decisions via Function: auto-approve, auto-reject, or delegate to a specific user or group
• Retryable error recovery for missing approvers, bad manager routing, and downstream failures — operators don’t recreate a request to recover
• Reassignment-aware progression: continues approval after reassignment without rebuilding the request
• Lifecycle event publishing for downstream dashboards, notifications, and automation

A request only settles once every requested resource reaches a terminal state.

Resources now let you model application access, equipment, and other things your organization grants. Each has its own request, approval, and fulfillment configuration.

• Abstract Resource primitive: request intake, approval policy, fulfillment path, and metadata bundled together
• Approval steps can be humans, groups, manager routing with fallback, or Function-backed logic
• Fulfillment paths: connector-automated, manual ticket to a user or group, Function-backed, or virtual (no external side effect)
• Per-Resource custom request Forms — collect the data needed for that Resource
• allow_multiple flag for Resources that can be granted more than once per identity
• Metadata JSONB for open-ended attributes without schema migrations
• Type field for categorization

Example shapes modeled in the first week: SaaS access, GitHub repos, database roles, laptop orders, shared data rooms, vendor onboarding steps, physical badges.

This release adds TOTP, passkeys, and zero-knowledge password login, with policy controls for staged MFA rollouts.

• TOTP (RFC 6238): 30-second window, 6 digits, 10 single-use backup codes (SHA-256 hashed)
• WebAuthn passkeys: challenge-response via @simplewebauthn, replay protection via signature counter, challenges stored with 5-minute TTL
• Zero-knowledge password login: raw password never leaves the browser during authentication
• Policy-driven MFA: required / optional / admin-only per tenant policy, with grace periods for staged rollout
• In-flow MFA enrollment — users can set up a factor during their first required login, without a separate setup process
• MFA secrets AES-GCM encrypted using an HKDF-derived key from COOKIE_SECRET; no plaintext in the DB

auth-svc now supports tenant-branded sign-in, password and magic-link login, and the beginnings of a login journey that can insert extra steps — MFA, terms acknowledgment, profile completion — before issuing a session.

• Password login with scrypt hashing (CPU cost 16384, 32-byte derived key, 16-byte salt)
• Timing-safe dummy verification to prevent user-enumeration via timing attacks
• Magic-link sign-in for passwordless flows
• Tenant-scoped sessions with sliding-window renewal and a hard maximum lifetime
• Delegated request authentication — other Owlie services validate incoming requests through this service, not their own
• API key authentication for automation callers, tied to an identity + tenant

Every tenant gets its own subdomain, every request routes through a tenant-resolution layer, and every database query is scoped by tenant_id by default. Zero cross-tenant data access, enforced at the query-builder level.

• Subdomain-based tenant routing (acme.owlie.com, corp.owlie.com)
• PostgreSQL via Hyperdrive for edge-friendly connection pooling
• Cloudflare Workers for global edge deployment
• Service-to-service RPC bindings as the internal control plane
• Monorepo scaffold — shared db, service, utils, errors, worker, test-utils, ui packages
• Typed error classes with client-safe messages and HTTP status mapping