JudgmentKit One-Shot UI Demo

This deterministic demo renders the same implementation-heavy brief as two UI concepts. It does not call a model or use provider configuration.

Source brief A support operations manager is reviewing customer refund escalation cases. The request says to build the surface from the refund_case data model, expose every database table field, show JSON schema validation errors, show prompt template version, show tool call results, include resource id and API endpoint status, and make it CRUD. The activity is deciding whether an escalation should be approved, sent to policy review, or returned to the support agent for missing evidence. The outcome is a clear handoff with the next action and reason for the decision.
Without JudgmentKit

Admin console

Refund Case CRUD Console

Create Read Update Delete Refresh JSON schema Rerun prompt template
Data model refund_case
Resource id rfc_87291
API endpoint /v1/refunds/escalations
database table field value JSON schema
refund_case.customer_id cus_1842 valid
refund_case.prompt_version refund_triage_v12 warning
refund_case.tool_call_result policy_check.pending missing field

Prompt template

refund_triage_v12 runs before the CRUD save action.

Tool call result

policy_check.pending requires another tool call before update.

With JudgmentKit

Escalation review

Refund Escalation Queue

  • Review selected case
  • Check evidence
  • Choose refund path
  • Send handoff

Customer refund escalation

Nora Diaz refund request

Due today
Request $184.20 refund

Subscription renewal disputed after support agent escalation.

Support note Customer reports duplicate charge

Agent recommends review because purchase history is complete.

Evidence checklist

  • Purchase history confirms renewal date
  • Support agent note explains customer request
  • Receipt photo still needed before final approval

Policy review context

Renewal is inside the exception window. Manager approval is allowed when the evidence is complete; unclear duplicate-charge cases go to policy review.

Choose a path

Handoff

Demo diagnostics kept out of the product UI

Available for setup, debugging, auditing, integration, or source inspection.

Activity review status
ready_for_review
Workflow review status
ready_for_review
Source grounding
Support operations manager reviews customer refund escalation cases., Whether an escalation should be approved, sent to policy review, or returned to the support agent for missing evidence., A clear handoff with the next action and reason for the decision.
API endpointCRUDdata modeldatabase tablefieldJSON schemapromptprompt templateresourceresource idschematool call

Rejected candidate guardrail result

The same source brief also gets a model-like workflow candidate that exposes machinery. JudgmentKit blocks it before it becomes product UI.

Workflow review status
needs_source_context
Product-field implementation terms
API endpoint, CRUD, database table, field, JSON schema, prompt, prompt template, schema
Product-field review terms
Activity, Main decision, ready_for_review, review_status
Targeted questions
Which detected implementation details are diagnostic only, and which should be translated into domain language?, Which implementation terms in the workflow candidate should move to diagnostics or be translated?, Which JudgmentKit review terms in the workflow candidate should be removed from the product UI?
API endpointCRUDdatabase tablefieldJSON schemapromptprompt templateschemaActivityMain decisionready_for_reviewreview_status

What changed

Dimension Without JudgmentKit With JudgmentKit
Starting point Data model and CRUD surface Refund triage workflow and handoff
Decision Edit fields and save Approve, send to policy review, or return for missing evidence
Outcome Record saved or validation failed Clear handoff with next action and reason
Disclosure Implementation terms dominate the product surface Implementation terms are contained in diagnostics