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 invoice 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. Resolved reviews become precedents that inform the Assisted drafting agent and are retrievable by external agents on similar runs.

Rule candidates: accept or decline

Marking a proposal incorrect with a correction and "apply going forward" queues a rule candidate — a proposed change to the app's logic that waits for a person. Candidates can also be raised outside the review loop: an integration holding the configure tier can queue one directly against an app, with its own evidence, and it lands in the same queue. Every candidate is either accepted (promoted) or declined (dismissed) by a workspace owner. Accepting drafts the rule into the app's next version; nothing runs differently until that version is published, so a candidate never changes live behavior on its own.

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"

# Rule candidates waiting for a decision, across every app
curl -s "https://api.talonic.com/v1/rule-candidates?state=open" \
  -H "Authorization: Bearer tlnc_your_api_key"

# Accept one (drafts it into the next version) or decline it
curl -s -X POST https://api.talonic.com/v1/rule-candidates/$CANDIDATE_ID/promote \
  -H "Authorization: Bearer $OWNER_SESSION_TOKEN"
One interview turn (the chat behind the form)
POST /v1/reviews/$REVIEW_ID/interview
{ "message": "Approve it — the supplier confirmed the corrected quantity by email.",
  "transcript": [] }

{
  "reply": "I'll submit: decision \"approve\", note \"Supplier confirmed the corrected quantity by email.\" Shall I?",
  "proposed_values": { "decision": "approve", "note": "Supplier confirmed the corrected quantity by email." },
  "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 workspace owner must explicitly accept. Accepting drafts it into the next version, and every behavioral change stays a versioned, human-approved publish with the review as its provenance.
What happens when I decline a rule candidate?+
It is marked declined and leaves the open queue; the app's logic is untouched. Declined candidates stay listable with state=dismissed, so the decision and its reasoning trail remain part of the record.
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