Application modules

Start with the application parts that already exist.

Choose an outcome. Each cluster connects released models, application behavior, UI, working examples, and exact Package Reference pages.

Outcome clusters: 8
Evidence release: v0.44.0
Package status: Visible

Largest time savers

Application foundations

These clusters replace the widest sets of models, workflows, controls, and integration work.

Application foundation

Identity and access

Give each person a durable identity, tenant membership, session, role, and controlled view of application data.

Models and application behavior

Users, profiles, tenants, memberships, roles, permissions, sessions, access requests, feature decisions, and protected secrets ship as application models and services.

OIDC and terminal sign-in use one session model. Tenant context and operation permissions apply the same identity to generated and custom interfaces.

Frontend components

UserList, UserForm, InviteUserModal, TenantSwitcher, membership controls, and field-policy editors supply common administration surfaces.

Field policy can change labels, help, visibility, order, and organization locks without creating a second form schema.

Framework and UI integration

The packages use the framework manifest, tenant context, generated interfaces, and the shared UI component contracts.

Postgres applications can add generated row-level security. Other databases still use application permission guards and tenant-aware collections.

Time and integration work removed

This foundation removes the separate account, session, tenant, role, permission, invitation, feature-control, and field-preference projects that most applications need.

Limits and maturity

Postgres supplies the generated row-level security layer. Other databases do not provide that additional data-layer check.

Application foundation

Agents and automation

Run governed agents, durable personas, conversations, schedules, background jobs, and application tools under one principal.

Models and application behavior

Agents declare interests, schedules, tools, tenant bindings, principal limits, and optional learning behavior.

Personas add durable identity, memory, directives, feedback, and approval. Chat and jobs provide conversation and execution records.

Frontend components

Agent dashboards, schedule forms, run history, directive review, chat layouts, tool-call views, and job operations ship with the packages.

The shared module UI registry lets an application place package-owned views inside AdminShell or another shared UI surface.

Framework and UI integration

Principal execution intersects user permissions, agent limits, and persona tool limits before work reaches application models.

The application MCP runtime exposes selected generated tools. The application must authenticate requests before supplying a principal.

Time and integration work removed

These modules remove separate work for persona storage, chat state, schedules, retries, tool policy, job visibility, and agent administration.

Limits and maturity

smrt-personas and smrt-chat are new. Applications must validate their workflows before broad production use.
smrt-jobs supplies runners and queue controls, but each deployment must select and operate an execution host.

Application foundation

Content and media

Create governed content and manage the assets, images, messages, social posts, voice, and video around publication.

Models and application behavior

Content models cover drafts, publication, contributions, reviews, corrections, versions, references, and transparent governance evidence.

Asset and media packages add storage, versions, image processing, communication accounts, message channels, social publishing, voice, and video production records.

Frontend components

Content editors, contribution portals, governance views, asset managers, image tools, account lists, message readers, and compose forms ship today.

Package-owned Playground views demonstrate the major content, asset, image, and message workflows.

Framework and UI integration

Content and media models use the same tenant scope, asset associations, generated interfaces, and shared UI registry as the framework.

Provider-neutral storage boundaries let an application choose local or Ergot-backed processing without changing the content model.

Time and integration work removed

This cluster removes separate editorial workflow, asset library, image tool, inbox, social scheduler, voice record, and video workflow foundations.

Limits and maturity

Voice, video, and social packages have no registered Playground examples on this site.
External storage, messaging, social, voice, and video operations still require provider configuration and credentials.

Application foundation

Commerce and operations

Connect products, stock, manufacturing, contracts, invoices, payments, accounting, subscriptions, and fulfillment.

Models and application behavior

Commerce models cover customers, vendors, contracts, invoices, payments, instruments, payouts, fulfillment, and guarded money operations.

Product, inventory, manufacturing, ledger, and subscription models connect catalog demand to stock, production, accounting, plans, grants, and usage.

Frontend components

Invoice cards, line items, totals, actions, unbilled work, plan selection, subscription summaries, and usage thresholds ship as Svelte components.

The Commerce Playground shows invoice and unbilled-item workflows. Several supporting packages remain intentionally headless.

Framework and UI integration

Tenant-scoped models generate consistent data interfaces and permission names. Commerce operations can post balanced entries to smrt-ledgers.

The packages use integer minor units for money and explicit services for guarded stock and payment state changes.

Time and integration work removed

These modules remove the base schemas and lifecycle rules for catalog, stock, production, billing, accounting, entitlement, and fulfillment work.

Limits and maturity

Applications still supply payment rails, tax calculation, provider settlement, and deployment-specific accounting policy.
smrt-subscriptions has UI components but no registered Playground module on this site.

Focused outcomes

Connected application domains

Use these clusters when the application needs a specialized workflow or a native client foundation.

Application domain

Support and projects

Route customer cases, connect delivery work, synchronize provider records, and approve the time spent on each result.

Models and application behavior

Project models cover repositories, issues, pull requests, time entries, approvals, and provider-neutral synchronization.

Support models add channel-neutral cases, routing, service targets, escalation, audit evidence, and explicit links to delivery work.

Frontend components

Time lists, summaries, duration display, approval actions, case queues, case detail, targets, and routing rationale ship with the packages.

The Projects Playground demonstrates time entry, summary, and approval behavior.

Framework and UI integration

Both packages use tenant-scoped framework models and shared UI contracts. A work link connects support cases to project delivery records.

Provider adapters synchronize external project systems without changing the application-facing model.

Time and integration work removed

This pair removes the first case queue, service-target engine, project provider layer, time ledger, and approval workflow.

Limits and maturity

smrt-support is new and has no registered Playground example on this site.
Provider synchronization requires application credentials and conflict policy for each connected service.

Application domain

Analytics and growth

Measure application activity, build reports, run campaigns, sell agreements, attribute referrals, and manage growth work.

Models and application behavior

Analytics tracks properties, streams, events, and saved reports. Reporting adds materialized aggregates, schedules, locking, and incremental refresh.

Ads, marketing, sales, referrals, commissions, and payouts cover acquisition work from delivery through attributed revenue.

Frontend components

Analytics summaries, event tables, campaign dashboards, sales pipelines, agreement lists, attribution queues, and payout review surfaces ship with the modules.

The Analytics Playground demonstrates summary, event, and property views from the released package.

Framework and UI integration

Provider records and metric snapshots use framework models, tenant scope, background schedules, generated interfaces, and shared UI registration.

Sales keeps agreements, CRM, referrals, and commissions in focused subpaths while preserving one neutral data model.

Time and integration work removed

This cluster removes separate reporting infrastructure, event storage, campaign ledgers, CRM foundations, referral attribution, and commission payout models.

Limits and maturity

smrt-reports, smrt-marketing, and smrt-sales are new. Provider connectors still require application configuration.
smrt-affiliates is a deprecated compatibility layer. New applications must use the smrt-sales commissions module.

Application domain

Domain knowledge

Model events, places, facts, properties, sites, and tags without rebuilding their relationships and search behavior.

Models and application behavior

Events include series, participants, placements, and nested programs. Places add hierarchy, geocoding, proximity, and lookup-or-create behavior.

Facts preserve provenance, confidence, reconciliation, and evolution. Properties, sites, and tags organize where application knowledge appears.

Frontend components

MeetingView supplies a complete event presentation. The other domain packages focus on models and generated interfaces.

The Events Playground demonstrates the released meeting view with package-owned example data.

Framework and UI integration

Each model joins the framework registry and receives persistence, tenancy where declared, semantic operations, and generated interfaces.

Content can link facts and assets. Sites and properties supply placement boundaries for content, ads, and application features.

Time and integration work removed

These modules remove recurring hierarchy, geospatial, provenance, taxonomy, event, site, and placement models from application projects.

Limits and maturity

Most domain packages are headless and rely on generated interfaces or application-owned UI.
smrt-gnode contains type definitions and class shells only. Federation discovery and exchange are not implemented.

Application domain

Mobile

Build Android and iOS clients on shared contracts, offline state, authentication, evidence capture, and native shells.

Models and application behavior

The Kotlin Multiplatform foundation supplies offline packs, durable writes, authenticated networking, evidence capture, and shared state presenters.

The contract package generates mobile allowlists and DTOs. Platform packages add Android and iOS shells and native adapters.

Frontend components

smrt-android supplies a Compose shell, theme, and Android adapters. smrt-ios supplies the corresponding SwiftUI shell, theme, and adapters.

Shared presenters let Compose and SwiftUI consume the same application state without sharing platform UI code.

Framework and UI integration

Mobile sessions use the same user, tenant, permission, and generated application contracts as web clients.

Offline writes replay through the declared synchronization contract instead of bypassing application validation.

Time and integration work removed

This foundation removes separate offline queues, authentication contracts, cross-platform state, evidence capture, networking, and shell architecture for each client.

Limits and maturity

smrt-mobile, smrt-android, and smrt-ios use source distribution. They are not public npm packages.
This site has no browser Playground for native platform shells. Native applications must supply platform permissions and service configuration.