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 a load for billing, flag an invoice, 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 gallery is a card grid built for five-second triage: each card shows the app's icon and name, its mode chip — *Rules* (deterministic policy sentences decide), *Assisted* (rules decide, an agent drafts review answers), or *External* (your own agent decides inside Talonic's contract) — its live state (enabled or off), the active version number, and how recently it ran. Clicking a card opens the app's detail view; the New app button starts creation. What you can do is role-gated: viewers browse, members run, senior members configure and publish, and owners manage access and deletion.

Creation is describe-first. The dialog opens on a text panel: write what you want decided, in your own words — "Check every delivered load against its rate card and hold any load where the billed amount differs by more than 2 percent" — and Talonic drafts the app: a name and slug, the mode it thinks fits, your policy restated as plain-language rule sentences, the output it will emit, and the data access it needs. Nothing exists server-side yet; you are reviewing a proposal, not editing a live app.

Review the draft before creating. Access suggestions resolve against your workspace's real resources — a "rate card" hint becomes a picker over your actual reference tables — and confirmed suggestions become read grants at creation, so the app arrives able to see its data. The proposal also lists open questions where your description was ambiguous; answering them now (by refining the description and re-drafting, or later as compiler guidance) is cheaper than debugging an indeterminate verdict later. Only Create this app makes anything real. A manual form — name, slug, mode radio cards — stays one quiet link away for when you already know exactly what you want.

Everything the UI does here runs through the public API, so the same flow scripts cleanly: draft with a description, then create and wire the result.

# 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 delivered load against its rate card and hold any load where the billed amount differs from the rate card amount by more than 2 percent."}'

# 2. Accept the proposal: create the app shell
curl -s -X POST https://api.talonic.com/v1/apps \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"slug": "rate-card-billing-validator", "display_name": "Rate Card Billing Validator", "mode": "rules"}'

{
  "proposal": {
    "display_name": "Rate Card Billing Validator",
    "mode": "rules",
    "policy_sentences": [
      "IF the billed amount for a delivered load differs from the rate card amount by more than 2 percent THEN hold the load."
    ],
    "access_needed": [
      { "resource_type": "data_product", "hint": "delivered loads" },
      { "resource_type": "reference_table", "hint": "rate card" }
    ],
    "open_questions": [
      "How is the percentage difference calculated (relative to billed or rate card amount)?"
    ]
  }
}