Two different jobs

Generating and deciding are not the same task.

They get lumped together as "AI," but they're judged by different standards and they fail in different ways.

Generative — produce something new

Write the reply. Summarize the document. Draft the description. The output is open-ended, there's no single correct answer, and you judge it on whether it's good.

There's no answer key to score it against, because one can't exist.

Discriminative — pick the right answer

Which category is this? Is this allowed? Where's the defect? Which existing record does this match? The answer space is known in advance, and you judge it on whether it's right.

Every prediction can be marked right or wrong — which is what makes accuracy a number rather than an impression.

Nyckel builds the second kind. That's the whole product.

Recognizing the shape

You're looking at a discriminative problem when…

The answers are known in advance

You can write down the list. Spam or not spam. Billing, technical, or shipping. Approved, rejected, needs review.

The same call repeats constantly

Not once. Thousands of times a day, on every item that arrives, forever.

Code acts on the answer

Something downstream routes, flags, blocks, or files based on it — so the answer has to be one of a fixed set your system already understands.

You need to know how sure it is

Because you want to auto-approve the clear cases and put only the uncertain ones in front of a person.

Consistency matters as much as accuracy

The same input on Tuesday and Thursday has to produce the same answer, or your downstream logic is built on sand.

The judgement is yours, not general

What counts as "inappropriate" or "defective" on your platform isn't what it means elsewhere.

Start with what you have

A generalist model can absolutely do this. Start there.

Prompting an LLM with your categories is a legitimate classifier.

It works, it takes an afternoon, and it needs no training data. We're not going to pretend otherwise — it's how a Nyckel function answers on day one, before it has seen a single example of yours. If your volume is modest and roughly-right is good enough, you may never need anything more, and that's a fine place to stop.

The interesting question isn't whether a generalist model can classify. It's what happens when the thing you built on it has to run in production for a year.

Where it starts to hurt

Four things that show up at scale.

None of these are faults in any particular model. They're properties of using a general-purpose model for a job that has a fixed set of right answers.

1

The confidence number isn't calibrated to your data

The whole auto-approve-or-review pattern depends on a score you can set a threshold against. What a generalist model gives you is either its own self-assessment or a token probability — and neither was fitted to how often it's actually right on your inputs. Picking a cutoff from it is guesswork wearing the costume of arithmetic.

2

Corrections have nowhere to go

When your team spots a bad call, nothing turns that into a better model. You edit the prompt and hope. The judgement your reviewers apply every day evaporates instead of accumulating, so the system is no smarter in month six than it was on day one.

3

Cost and latency scale with every item

You pay per call, on every item, forever. And the obvious lever for more accuracy — reach for a larger model — pushes cost and latency the wrong way at exactly the point where volume makes both of them matter.

4

It changes under you

Model versions get deprecated and behaviour shifts on somebody else's schedule. A prompt you tuned six months ago isn't guaranteed to behave the same way today, and you're likely to hear about it from your users before you hear about it from your monitoring.

What a specialized model gives you

Build it, watch it, make it better.

The advantage isn't only that a specialized model is more accurate on day one. It's that it's something you can operate.

1

Build from examples, not prose

Your edge cases are easier to demonstrate than to describe. Showing the model thirty borderline cases encodes judgement that no amount of prompt wording captures cleanly.

2

Monitor a real accuracy number

A prompt has no accuracy figure — only a vibe. A trained function is scored continuously against held-out labeled data, per label, so you can see which categories are weak and whether last month's change helped.

3

Improve through the same loop you already run

Every correction your reviewers make becomes training data. Nyckel retrains, benchmarks the new model against the current one, and promotes it only if it actually scores better.

You don't have to pick one up front.

A Nyckel function starts zero-shot on a generalist model, so you get predictions from the first call. As you review and correct them, a private model trains on your examples in the background. When it benchmarks better than the baseline, it takes over the endpoint — same URL, no migration, no second integration. You move from generalist to specialized without rewriting anything.

When not to use us

If you need something written, use an LLM.

Summaries, replies, drafts, conversation, anything open-ended — that's generative work and a general-purpose provider is the right tool. The same goes for a one-off analysis, or a decision you make a hundred times rather than a hundred thousand. Nyckel earns its place when the answer space is bounded, the volume is real, and being wrong has a cost.

Your application doesn't need a paragraph. It needs a decision.