Skip to main content

Run Inspector & Review Inbox

The Run Inspector is the ledger made legible. Open any run and read, top to bottom: what triggered it and who the actor was; what data it read, with provenance locators you can click through to the source — down to the page anchor when one exists; which logic version decided and who or what the decider was (rules, a drafting agent, a human, or an external agent — recorded with identical weight); which thresholds applied; which reviews touched the run; what was executed and how delivery went; and the sealed record, the immutable export-grade summary minted when the run reached its terminal state. If the Inspector cannot show it, the ledger did not capture it — that is the design contract.

For batch apps the Inspector also carries the per-subject verdict matrix with its summary and filters, so "why was this one load held" is one click from "how did the run go overall". The raw journal and the sealed record are both exportable from the page — the sealed record is what you hand an auditor, and it survives even app deletion.

The Review Inbox collects Human Reviews from every app in the workspace: questions an app needs a person to answer — an approval above an amount ceiling, a judgment a rule routed to review, a data request, or an exception the system raised. Filter by status and kind, open an item, and resolve it on one screen: the app's proposal and its evidence sit beside a two-part form — the resolution fields, generated from the review's own input contract, and then the feedback prompts. Feedback is optional to fill but always shown: it is the half that teaches the app.

You can also talk a review through instead of filling the form: the interview chat asks one focused question at a time, maps your plain-language answers onto the resolution fields, and reads back what will be submitted once your intent is clear — the prefilled form is still yours to confirm. Feedback compounds over time: marking a proposal incorrect with a correction and "apply going forward" queues a rule candidate in the app's Logic pane, where a person can promote it into the draft — never auto-applied — and resolved reviews become precedents that inform the Assisted drafting agent and are retrievable by external agents on similar runs.

Approval-kind reviews are human-only, and the raiser can never be the resolver — separation of duties is enforced at the endpoint, not by convention. Agents holding an operate grant may resolve judgment and resolution kinds; data requests accept any authorized actor.

Review teams organize who sees what: an owner creates teams under the review-teams surface, adds workspace members, and reviews route to a team at raise time or by reassignment. A team can carry a webhook URL for its own notification channel, and the workspace app.review.raised webhook signals every new review for custom integrations. Assignment is routing, not authorization — the resolver policy above still decides who may actually answer.

Watch the loop from the API side
# The inbox your team triages
curl -s "https://api.talonic.com/v1/reviews?status=open" \
  -H "Authorization: Bearer tlnc_your_api_key"

# One run's full journal — what the Inspector renders
curl -s https://api.talonic.com/v1/runs/$RUN_ID/events \
  -H "Authorization: Bearer tlnc_your_api_key"

# The sealed decision record — what you hand an auditor
curl -s https://api.talonic.com/v1/runs/$RUN_ID/record \
  -H "Authorization: Bearer tlnc_your_api_key"
One interview turn (the chat behind the form)
POST /v1/reviews/$REVIEW_ID/interview
{ "message": "Approve it — the carrier confirmed 24 pallets by phone.",
  "transcript": [] }

{
  "reply": "I'll submit: decision \"approve\", note \"Carrier confirmed 24 pallets by phone.\" Shall I?",
  "proposed_values": { "decision": "approve", "note": "Carrier confirmed 24 pallets by phone." },
  "proposed_feedback": null,
  "ready": true,
  "warnings": []
}

Frequently asked questions

What is the difference between the run journal and the sealed record?+
The journal is the append-only play-by-play: every event with its actor and timestamp, written as the run executes. The sealed record is the immutable summary minted once at terminal state — decision, evidence, rationale, decider, thresholds, reviews, timing. Read the journal to debug; export the sealed record to audit.
Where do exceptions show up?+
In the same inbox — exceptions are the system-raised subset of reviews (threshold breaches, validation failures, fallback holds), distinguished by their raiser, and each app's view can filter to them. There is no separate queue to watch.
Does resolving a review change the app's rules?+
Never silently. Your resolution settles the matter at hand; your feedback becomes context (precedents) and, when you mark it generalizable, a rule candidate a person must explicitly promote into a draft and publish. Every behavioral change stays a versioned, human-approved publish with the review as its provenance.
Can I automate parts of the inbox?+
Yes. Subscribe to app.review.raised and app.review.resolved webhooks for push notification, and let a granted agent resolve data_request reviews over the API while approval kinds stay with humans. The interview endpoint is also available programmatically for building your own review frontends.

Related

Operating an App
Gallery & Creating Apps
Team Management
Webhooks