Choose by the requirement#

Begin with the user action and its owning service. A shared interface or attractive generated screen does not decide where a business invariant belongs. Use this map to select a starting capability, then verify the exact contract against the pinned release.

Requirement Starting capability What the application must supply
A normal business application with custom UI Matrix hosting, Shell and custom modules/pages Domain API, typed adapters, authorization and page registration
Entity and relationship maintenance Explicit CRUD module Data context/provider, permissions, validation and mutation rules
A service-backed or SQL-backed worklist Query-backed CRUD or Reporting, according to write ownership Typed query handler, row scope, key and authorized operation mapping
Typed reports, exports and drill-through Reporting Data grain, query execution, limits and source/destination authorization
A fixed multi-panel dashboard Dashboards with registered Reporting queries Page bindings, independent state and refresh expectations
A bounded guided submission Wizard Typed session handlers, final command and durable result handling
Shared theme, language or private favorites Preferences and Portal adapters Supported schemas, enrollment and restoration policy
An application launch directory Portal Enrolled application metadata and independent sign-in/authorization
Durable service and human process steps Workflow Typed participant capabilities, bindings, receipts and business interactions
Common inbox and action navigation Messages and presentation adapters Authorized recipients, registered actions and destination behavior
Shared operational services Infrastructure profiles Approved allocations, runtime configuration and release acceptance

Build an application#

Start with the first application journey. Capture the requirement, select a template and runtime baseline, then compose API and Web halves. Register only what the application needs.

For a custom page, keep its business logic in the Consumer API and its UI in a normal page. For generated CRUD, configure the model and the feature-owned presentation surfaces explicitly. JSON presentation settings cannot introduce executable behavior, new trusted routes or permissions.

Choose a read model by its ownership. A query-backed worklist that retains entity mutations has a different contract from a typed report. Totals, exports and drill-through must agree with the authorized query and cannot be inferred from the rows currently visible in a browser.

Integrate independent services#

Portal enrollment adds a discoverable application entry and documented shared preferences/session integrations. The destination continues to enforce its own policy.

Workflow integration adds process ownership, immutable definition publication, explicit activation and durable operation handling. It does not replace the participant application's business transaction. An uncertain outcome requires recovery against the operation identity, not a blind new operation.

Messages adds durable acceptance and user presentation state. Reading a notification or following an action link does not complete a Workflow task. Completion depends on the owning application's outcome and the Workflow contract.

Qualify availability#

The reviewed documentation includes implemented source, published versions, compatibility candidates and future designs. These are deliberately kept separate:

Evidence What it establishes What remains to check
Implementation and local tests Behavior within the tested source/fixture Packaging and target environment acceptance
Published package or image Identifiable release bytes Consumer composition and deployment compatibility
Consumer acceptance A bounded application's verified use A materially different use case and operating scale
Installation acceptance Behavior in a named environment/release set Ongoing controls, maintenance, restore and capacity

An optional runtime AI Assistant/MCP design, broader BPMN semantics, installation-time engine selection and Kubernetes qualification must be assessed using their own source status. Development skills, a service contract or a general technology capability do not by themselves establish these implementations.

Verify before widening adoption#

Use one bounded journey to prove business fit and an internal developer's ability to change it. Include denied paths, duplicate delivery, uncertain mutation outcomes and restoration where they apply. Review actual package versions, configuration, evidence and operating ownership before adding another application or promising a service level.

Read AI guidance and verification and operations for the checks that connect development to sustained operation.