Gallery & Creating Apps

Apps turn your governed data into decisions. Where a Spec produces a structured table, an app *reads* tables like it — data products, reference tables, connected databases, even other apps — and produces verdicts: approve or hold an invoice, flag a contract that needs attention, prepare a review package. Every run is recorded in a sealed, replayable ledger, so each decision names exactly what it read, which logic version decided, and who or what made the call. You reach the surface from Apps in the navigation; the apps you pin also appear directly in the sidebar.

The gallery opens on an overview band for the whole workspace — how many apps are live, how many runs happened in the last 24 hours, how many items are waiting for a person, and how many runs are in progress right now. A toolbar below it finds one app among many by name and filters by mode or state. The apps themselves are laid out in three bands: Pinned to sidebar (in pin order — exactly the list the sidebar shows), Active (live apps), and Not running (drafts and switched-off apps, whose history stays readable). When nothing is pinned yet, the page says so, because the sidebar then shows no apps at all.

Each card reads in five seconds, top to bottom: the app's mark, its name and one-sentence description; how it decides (*Rules*, *Assisted*, *External*, or a *Standard app* chip) and whether it is live; how many items it has left waiting for people; and what it did last. Custom apps show their active version and when they last changed; standard apps, which have no versions, show when they last ran or when they were added. Clicking anywhere on the card opens the app. Workspace owners additionally see a pin toggle and a small menu on each card, outside the click target.

Pinning is the workspace's control over the sidebar rail: pin an app and it appears in every member's sidebar, in the order apps were pinned; unpin it and it leaves the rail but stays in the gallery. Pinning is a display choice only — it never enables, disables, or publishes anything, so you can keep a disabled app pinned while you fix it. The card menu's Rename opens the presentation dialog: a new name, a different icon from the platform's set, and the one sentence the card shows. Presentation is stored per workspace and publishes no version; the slug stays fixed, because MCP tool names are derived from it.

Create an App

The Create an App button opens a wizard with four paths. Describe it (recommended): say what should be decided, when, and from which data, and the platform drafts the app for you to review line by line. Add a standard app: pick one of the apps the platform ships whole — one click and it is live in this workspace, with nothing to author (see Standard Apps). Start from scratch: give the app a name and slug, pick how it decides, and write its rules yourself afterwards; it is created as a draft. Register a hosted app: paste the address of an app served from your own or a vendor's host; the platform reads its manifest, shows what it found and what it will ask for, and only registers it once the manifest validates.

On the describe path, write the decision in your own words — "Check every supplier invoice against its purchase order and hold any invoice where the billed amount differs by more than 2 percent" — and the draft comes back as a name and slug, the mode that fits, your policy restated as plain-language rule sentences, the output it will emit, and the data it needs. Access suggestions resolve against your workspace's real resources, so "purchase orders" becomes a match to an actual data product or reference table you can confirm or untick. The draft also lists open questions where your description was ambiguous; answer them in place and redraft, and the answers ride along as part of the description.

Nothing exists until you choose Create this app. Then, in one step, the platform creates the app as a draft with the drafted summary as its card sentence, saves the rule sentences as its logic, grants read access to every data source you confirmed, and interprets the rules into executable checks against the fields those sources actually carry. The result screen says which rules were interpreted and which still need attention. From there you open the app, publish it, and run it on your data — publishing and enabling are always separate, explicit steps.

What you can do here is role-gated. Viewers browse the gallery, ledgers, and reviews; members trigger runs; Senior Members resolve reviews, replay runs, and hold the kill switch; workspace owners configure — create, rename, pin, edit drafts, publish, enable, and manage access. Everything the UI does runs through the public API, so the same flow scripts cleanly.

# 1. Draft from a description (nothing persists)
curl -s -X POST https://api.talonic.com/v1/apps/proposals \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"description": "Check every supplier invoice against its purchase order and hold any invoice where the billed amount differs by more than 2 percent."}'

# 2. Accept the proposal: create the app with its one-sentence description
curl -s -X POST https://api.talonic.com/v1/apps \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"slug": "invoice-po-check", "display_name": "Invoice PO Check", "mode": "rules",
       "description": "Holds supplier invoices that drift from their purchase order."}'

# Pin to the sidebar rail (workspace-wide, in pin order)
curl -s -X POST https://api.talonic.com/v1/apps/$APP_ID/pin \
  -H "Authorization: Bearer $SESSION_TOKEN"
# → { "nav_pinned": true, "nav_pinned_at": "2026-10-06T09:12:44.120Z" }

# Rename, re-mark, and re-describe — publishes no version, slug unchanged
curl -s -X PATCH https://api.talonic.com/v1/apps/$APP_ID/presentation \
  -H "Authorization: Bearer $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"display_name": "PO Match", "display_icon": "receipt",
       "description": "Supplier invoices checked against their purchase order."}'