Operating an App

An app's detail page is its value surface — it answers "what did the app decide, and what happens next", not "how is it wired". The centerpiece is the verdict matrix: one row per subject (each invoice, contract, or case the app decided), one column per rule, each cell showing that rule's outcome for that subject — passed, failed, indeterminate, or not applicable. The matrix renders from the manifest alone even before the first run, so a new app looks like itself from minute zero.

By default the matrix shows the standing decisions: one row per subject across the app's whole history, each at the latest decision any sealed, non-dry run reached for it. A run only covers the subjects its trigger touched; the standing view shows every subject the app has ever decided, with the run and version that decided it. Where a historical decision was made under rules that have since changed in meaning, its cells are not passed off as current results. Pick a run from the run selector to narrow the matrix to exactly that run instead; when a newer run lands while you are looking at an older one, a banner offers to switch.

Above the matrix, the operating strip compresses what you are looking at into one line of chips: verdict counts (how many approved, how many held), action counts, inconclusive and not-applicable cells, and the app's own headline metrics — every number a straight render of the ledger, not a client-side recount. Clicking any cell opens the evidence drawer: the rule's plain-language sentence, why this subject passed or failed it, and the provenance locators behind the values compared — down to the source document page when one exists. Where a subject is made of several documents, expand the row for its document × rule drill-in: each document on its own line, with that document's outcome for every rule, so you see which file carried the failure.

From a subject or a cell you can open Review Mode on the underlying record without leaving the app. Opened this way, Review Mode carries the app's own rules — exactly the matrix columns — with each subject's outcome per rule, the fields each rule read, and a plain-language sentence for each outcome in your language, so a reviewer sees the document, the extracted values, and why the app passed or held it side by side. It starts on the rule you clicked, or else the first failed (then the first unclear) rule for that subject.

Export Report turns the page you are looking at into a printed report. It prints the live view — the filters you applied and the run you selected — with a report masthead, and hides navigation and interactive controls; your browser's print dialog supplies "Save as PDF". Nothing is generated or stored on the server, so the report can never drift from what the screen showed.

Configure, edit, and publish

Everything about wiring lives one click away behind Configure, organized as the four questions an operator asks. Data: which sources the app reads (its input bindings and resource grants, with pickers over your real data products and reference tables). Logic: the rule cards in plain language — add a sentence, let the compiler ground it in the app's bound fields, and cards that cannot be grounded stay visibly pending with the reason rather than silently deciding. Actions: what the app may execute, plus thresholds like a confidence floor or an amount ceiling that routes big decisions to human approval. Access: connected clients (which API keys may read or operate the app, for your own agents) and a copy-ready MCP config snippet.

Editing is language-first here too: describe a change — "raise the tolerance to 3 percent" — and the platform proposes typed edit operations with a preview of the manifest after the change; you apply them explicitly. Saving logic publishes a new version, with versions appending so the ledger always names the exact version that decided each run. Before saving a risky change, the publish impact panel replays the draft and the live version over the same recent history and shows which subjects would flip verdict and how each rule's pass/fail footprint moves — an empty flip list is your strongest green light.

Acceptance sets give the app a machine-checkable definition of done: label the expected verdict for known subjects ("INV-2026-0851 must fail — a price drift above 2% never auto-approves"), set a tolerance, and check any run against the labels. The check is a pure ledger comparison — no model involved — so it is free, instant, and repeatable: editing logic, dry-running, and re-checking acceptance is how you iterate an app toward trustworthy before it touches live work.

# Every subject at its standing decision (cursor-paginated by subject key)
curl -s "https://api.talonic.com/v1/apps/$APP_ID/subjects?limit=200&include=summary" \
  -H "Authorization: Bearer tlnc_your_api_key"

# Dry-run: full trace, zero side effects (works even while disabled)
curl -s -X POST "https://api.talonic.com/v1/apps/$APP_ID/runs?dry_run=true" \
  -H "Authorization: Bearer tlnc_your_api_key" -d '{}'

# Score the latest run against the labeled expectations
curl -s https://api.talonic.com/v1/apps/$APP_ID/acceptance/check \
  -H "Authorization: Bearer tlnc_your_api_key"
# → { "evaluated": 12, "matched": 12, "score": 1, "tolerance": 0, "pass": true, ... }

{
  "runsCompared": 42,
  "flips": [
    { "runId": "8c41f3aa-…", "subjectKey": "INV-2026-0851", "from": "failed", "to": "passed" }
  ],
  "ruleDeltas": [
    { "ruleId": "price-tolerance",
      "name": "Hold any invoice whose amount drifts more than 3 percent from its purchase order.",
      "passesBefore": 198, "passesAfter": 205, "failsBefore": 9, "failsAfter": 2 }
  ],
  "summary": { "totalSubjects": 214, "flippedSubjects": 1 }
}