generated from coulomb/repo-seed
Add implementation workplans and integration boundaries
This commit is contained in:
89
INTENT.md
89
INTENT.md
@@ -1,63 +1,84 @@
|
||||
# User Engine INTENT.md
|
||||
# INTENT
|
||||
|
||||
> This file captures why this repository exists, the direction it is moving
|
||||
> toward, and the kind of system it is meant to become. It is intentionally
|
||||
> aspirational and stable, not a description of current implementation.
|
||||
|
||||
## Purpose
|
||||
|
||||
`user-engine` exists to provide a reusable, headless user domain service for applications, platforms, and repositories that need account, profile, preference, membership, and application-specific user attribute management without becoming tightly coupled to a single identity provider or UI.
|
||||
`user-engine` exists to provide a reusable, headless user-domain service for
|
||||
products and platforms that need account, profile, preference, membership, and
|
||||
application-specific user attribute management without coupling those concerns
|
||||
to a particular identity provider, authorization engine, or user interface.
|
||||
|
||||
## Primary Utility
|
||||
|
||||
The project provides a canonical user layer that can be embedded in small standalone services and extended into multi-tenant, multi-application, and multi-team environments.
|
||||
The project provides a canonical user layer that can start small in a
|
||||
standalone service and grow into governed multi-tenant, multi-application, and
|
||||
multi-team environments.
|
||||
|
||||
It manages:
|
||||
|
||||
- users and account state
|
||||
- external identity links
|
||||
- profile and preference data
|
||||
- tenant, application, and team memberships
|
||||
- application-registered customization attributes
|
||||
- catalog-driven profile schemas
|
||||
- profile projections for consuming applications
|
||||
- lifecycle and profile-change events
|
||||
- users and account state;
|
||||
- external identity links;
|
||||
- profile and preference data;
|
||||
- tenant, application, and team memberships;
|
||||
- application-registered customization attributes;
|
||||
- catalog-driven profile schemas;
|
||||
- profile projections for consuming applications;
|
||||
- lifecycle and profile-change events.
|
||||
|
||||
## Strategic Role
|
||||
|
||||
`user-engine` separates user-domain management from authentication, authorization, and application-specific UI concerns.
|
||||
`user-engine` separates user-domain management from authentication,
|
||||
authorization, credential lifecycle, and UI experience concerns.
|
||||
|
||||
It is intended to integrate with established identity and access systems such as OIDC providers, SCIM provisioning sources, LDAP-compatible directories, and external authorization engines, while remaining useful in simple standalone deployments.
|
||||
It is intended to integrate through standards-aligned interfaces with identity
|
||||
providers, provisioning sources, directories, authorization systems, event
|
||||
sinks, and optional UI surfaces while remaining useful in simple standalone
|
||||
deployments.
|
||||
|
||||
## Intended Users
|
||||
|
||||
- application developers adding user/account functionality to a service
|
||||
- platform teams managing users across multiple applications
|
||||
- product teams needing self-service account and preference management
|
||||
- operators and tenant administrators managing scoped user populations
|
||||
- agentic systems that need structured access to user preferences and profile context
|
||||
- application developers adding user/account functionality to a service;
|
||||
- platform teams managing users across multiple applications;
|
||||
- product teams needing self-service account and preference capabilities;
|
||||
- operators and tenant administrators managing scoped user populations;
|
||||
- agentic systems that need structured access to user preferences and profile
|
||||
context.
|
||||
|
||||
## Product Boundaries
|
||||
|
||||
`user-engine` is the headless backend and domain service.
|
||||
|
||||
Related UI surfaces may be provided separately:
|
||||
It does not aim to be:
|
||||
|
||||
- `user-account` for self-service account, profile, and preference management by the individual user
|
||||
- `user-manager` for administrative and operational management of users in a tenant, application, team, or platform scope
|
||||
- a full identity provider;
|
||||
- a password, passkey, session, or MFA system;
|
||||
- a fine-grained authorization engine;
|
||||
- a directory server;
|
||||
- a UI application.
|
||||
|
||||
`user-engine` does not aim to be a full identity provider, password/MFA system, or fine-grained authorization engine, though it may integrate with such systems.
|
||||
It provides the user-domain APIs, catalog metadata, projections, events, and
|
||||
audit records that those surrounding systems can consume.
|
||||
|
||||
## Design Principles
|
||||
|
||||
- headless first
|
||||
- optional UI, not UI-driven
|
||||
- standalone-friendly
|
||||
- enterprise-integratable
|
||||
- identity-provider agnostic
|
||||
- authorization-engine agnostic
|
||||
- catalog-driven customization
|
||||
- explicit ownership, visibility, mutability, and sensitivity of attributes
|
||||
- layered profiles instead of one global metadata blob
|
||||
- concrete user-domain focus with a possible future extraction path toward a generic profile engine
|
||||
- headless first;
|
||||
- optional UI, not UI-driven;
|
||||
- standalone-friendly;
|
||||
- enterprise-integratable;
|
||||
- identity-provider agnostic;
|
||||
- authorization-engine agnostic;
|
||||
- catalog-driven customization;
|
||||
- explicit ownership, visibility, mutability, and sensitivity of attributes;
|
||||
- layered profiles instead of one global metadata blob;
|
||||
- deterministic and inspectable effective profile resolution;
|
||||
- concrete user-domain focus with a possible future extraction path toward a
|
||||
generic profile engine.
|
||||
|
||||
## Success Definition
|
||||
|
||||
`user-engine` succeeds when a repository or application can add robust user-domain capabilities with minimal coupling, while still having a clear path from a simple local setup to a governed multi-tenant, multi-application deployment.
|
||||
|
||||
`user-engine` succeeds when a repository or application can add robust
|
||||
user-domain capabilities with minimal coupling while keeping a clear path from
|
||||
a simple local setup to a governed multi-tenant, multi-application deployment.
|
||||
|
||||
Reference in New Issue
Block a user