Build on the Apps Layer

The Apps Layer turns TWL Tool's existing primitives into installable, domain-specific apps. An app can combine Data Workspace tables, workflows, documents, native product surfaces, and developer-authored Frontend Pages without rebuilding those systems.

The mental model

An app is a typed manifest with four parts:

1. Identity — a stable key, human-readable name, and version.
2. Resources — the data, workflows, documents, forms, and pages created for each installation.
3. Surfaces — the navigation experience users see inside the installed app.
4. Permissions — the minimum platform capabilities those surfaces and workflows need.

At install time, TWL Tool creates account-scoped resources and resolves symbolic references such as dataWorkspaceTables.inspiration to their real IDs. Your source stays portable across accounts.

Native where it matters

Use native surfaces when the platform already has the right experience:

• dataWorkspaceView for structured records and clipped content
• document for generated or curated documents
• chat for a workflow-scoped AI experience
• contentScheduler for reviewing and scheduling documents

Use a frontendPage for the part that is genuinely specific to your product: an overview, dashboard, guided flow, or other custom interface.

:::info Reuse, do not fork An app surface points at the existing TWL Tool feature. It does not copy the AI chat, document editor, scheduler, or Data Workspace into your package. :::

Where to go next

• Follow the quickstart to define and validate a minimal app.
• Learn how resources and references are resolved.
• See Super Writer for a full composition of custom and native surfaces.