What we've shipped, and when.

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, entitlements, 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, signing keys, rate-limit visibility, and IdP audit events
• 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

Governance gets stronger when policy, evidence, and system state are visible in the same product surface.

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

A clearer control plane for teams that need to explain access, extend integrations, and move through operations without losing context.

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

More of the access lifecycle now lives in Owlie as structured, governed workflow instead of side-channel coordination.

Two big pieces before the final pre-launch pass.

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 OEL
• 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
• Turns what used to be a six-figure services engagement into a configuration task

Next entry will be the early-access launch itself. That one waits.

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

These are the features that look small on paper and change how the work feels in practice.

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 handles this honestly.

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
• Conflict resolution is a policy, not an accident

Owlie Expression Language (OEL)

• 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

These two features are quiet, but they’re load-bearing. Every identity attribute flowing through the platform touches at least one of them.

The trust plumbing. The invisible foundation under every claim the platform makes about auditability.

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

The underlying promise: “what we applied” cannot drift from “what we recorded as applied.”

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

The result is a request flow that is easier to follow and less likely to stall on missing org data.

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

Auth0

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

BambooHR

• Sync only: employee records — HRIS lifecycle signals and identity attributes
• Deliberately narrow scope. BambooHR owns the truth on HR events; provisioning flows from there, not the other way around

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.

The extensibility layer. Every subsequent differentiator in the platform hangs off this.

• 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 — it’s a design constraint, not an oversight

Decisions that matter: drafts and lives are separate. Published releases are immutable code (secrets can still rotate). Outbound is opt-in, never implicit.

Sync in Owlie does more than import data. It observes reality, compares it to intended state, and applies the policy you set when the two 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 month established the product surfaces that later workflows can build on.

Connector one and two. Picked deliberately — Google Workspace and Microsoft Entra ID cover the workforce-identity root for most mid-market teams.

Google Workspace

• Sync: users, groups, admin roles, org units, domains
• Provision: full account lifecycle + entitlement 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 + entitlement 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

Narrow and deep. No wide-and-shallow catalog theater.

The provisioning engine. This is the deepest technical piece in the platform, and it went green today.

• Typed operation intents: provision, enable, disable, revoke, update attributes, add/remove/set entitlements — each with per-action payload validation
• desired_version and applied_version per assignment — concurrent or retried operations converge by version, not by timing luck
• 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

The line that matters most in the whole system: every operation carries a target version.

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 — each case handled honestly
• 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. No “mostly succeeded” final statuses.

Most governance tools model “apps” and “entitlements.” Owlie models Resources — and a Resource is whatever you need it to be. This is the conceptual core of the platform, and it landed today.

• 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 that matters for that Resource, not the vendor’s default schema
• 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.

The auth surface got serious. Three login methods that cover the range from familiar to phishing-resistant, and a policy layer that lets tenants stage MFA rollouts instead of flipping a switch.

• 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

Detail: backup codes are hashed and consumed once. A used code is gone. Passkeys track sign-count to detect replay.

auth-svc took its first real shape. 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

The decision: authentication is a pipeline, not a form. Other services borrow authentication state; they don’t reimplement it.

The core bet: 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. Everything after this is built on it.

• 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

The significant decision: tenant scoping is architectural, not a check you remember to write.