Example workload proposal: synthetic customer-support triage

[Krako-cloud]

This is an example workload proposal for KORA validation.

The goal is to show how developers can propose a workload using synthetic or sanitized data only.

Workload name

Synthetic customer-support triage

Workload type

Customer support / support ticket routing

Current model or runtime

Local no-network validation for now.

Future versions may use a local model runtime or a real provider adapter, but this proposal does not require API keys or external providers.

Why this workload may fit KORA

Support queues often contain many repetitive requests that do not require a model call every time.

Examples:

• password reset instructions
• refund policy lookup
• shipping status instructions
• account email change instructions
• cancellation deadline rules
• warranty eligibility rules

Some requests should still escalate to a model because they are ambiguous, sensitive, incomplete, or multi-intent.

Approximate request volume

Example synthetic version:

• 12 total requests
• 8 deterministic or structured routes
• 4 model-required routes

Larger future version:

• 100+ synthetic requests
• multiple support categories
• repeated validation runs

Deterministic or repetitive request types

Examples:

• “How do I reset my password?”
• “Where can I find the refund policy?”
• “How do I update my account email?”
• “What is the standard cancellation deadline?”
• “How do I check my order status?”

These should be handled through deterministic, policy, lookup, or structured paths when possible.

Model-required request types

Examples:

• ambiguous complaint with missing context
• unusual edge case
• sensitive escalation
• multi-intent request
• request that needs judgment beyond a deterministic policy

These should escalate to model inference.

Validation rules

Possible validation rules:

• response_type_matches
• required_link_present
• policy_value_matches
• lookup_placeholder_present
• escalation_reason_present
• no_private_data_emitted

Expected counters

For the current 12-request synthetic version:

Counter	Expected value
total_requests	12
baseline_model_calls	12
kora_model_calls	4
avoided_model_calls	8
avoided_model_call_rate	0.6667
deterministic_routes	8
model_escalations	4

Privacy class

Synthetic.

This proposal should not include:

• real customer names
• real emails
• real phone numbers
• real order IDs
• private customer data
• proprietary datasets
• raw provider responses
• API keys or credentials

Can results be public?

Yes, if the workload remains fully synthetic and sanitized.

Claim boundary

This workload can support local no-network validation or future local model validation.

It should not be described as:

• production validation
• real API-cost reduction evidence
• production cost-reduction proof
• energy-reduction evidence
• broad workload superiority proof

Related public docs

• Workload proposal template: https://github.com/Krako-Labs/KORA/blob/main/docs/community/workload-proposal-template.md
• Customer-support triage workload spec: https://github.com/Krako-Labs/KORA/blob/main/docs/workloads/customer-support-triage.md
• Local validation reviewer packet: https://github.com/Krako-Labs/KORA/blob/main/docs/benchmarks/local-validation-reviewer-packet.md