Overview & result
The skill helps a coding agent recognize patterns such as prompt → JSON → parser → retry and propose smaller Jev Choice, Noul, or Score boundaries while leaving execution and policy in application code.
From the original post
I dropped a generic Jev System Architect skill. And I think the distinction behind it is important.
TypeSafe already has an official skill for Jev that helps coding agents understand the API, SDK, primitives, and implementation patterns.
But there’s another question that comes before implementation:
Where should Jev exist in the system in the first place?
That's what this skill is for. Most AI coding agents are increasingly good at:
"Implement this API."
They're much less reliable at recognizing:
"We just built 300 lines of brittle semantic logic because nobody realized this should have been a tiny probabilistic decision boundary."
So the skill continuously looks for patterns like:
unstructured information
↓
fuzzy semantic judgment
↓
software needs a typed answer
Those are potential Jev boundaries. For example:
Customer message
↓
Huge LLM prompt
↓
"Return JSON"
↓
parse validate retry
↓
route ticket
Maybe you don't need an agent there. Maybe you need four judgments:
┌→ topic Choice
│
MESSAGE → JEV ──┼→ refund requested? Noul
│
├→ frustration Score
│
└→ fraud signal? Noul
↓
CODE
↓
decides what happens
That architecture is fundamentally different.
Jev supplies programmable judgment.
Your software still owns the system.
The skill teaches an agent to inspect a codebase for things like:
→ prompt → JSON → parser → retry pipelines
→ giant semantic if/else trees
→ expensive reasoning models doing tiny classifications
→ agent loops whose entire purpose is making one bounded decision
→ brittle routing logic
→ semantic verification
→ RAG relevance decisions
→ guardrails
→ fuzzy extraction from known candidates
→ tool/function selection
Then it asks: Should Jev actually be used here?
Importantly, "no" is a valid answer.
If the problem is deterministic: use code.
If the output needs to be genuinely generative: use a generative model.
If the task requires deep multi-step reasoning: use a reasoning model.
But if normal software encounters something it can't semantically understand and only needs a bounded judgment to continue... that's where Jev gets interesting.
The skill then helps decompose that boundary into:
Choice – Which bounded option?
Score – Where does this sit on an ordered semantic spectrum?
Noul – What's the probability this proposition is true?
And instead of one enormous prompt:
Analyze this customer, determine whether they're angry, whether fraud is likely, whether they want a refund, which department should handle them, what priority they should receive, and what we should do next.
You get atomic judgments:
topic → Choice
refund_requested → Noul
fraud_signal → Noul
frustration → Score
Then:
JEV
↓
typed probabilistic judgments
↓
CODE
↓
compose / route / verify / ask / escalate / execute
The skill also pushes several architectural principles I think matter a lot:
1. Batch independent judgments.
If five questions can see the same state, don't automatically make five sequential model calls. Fan them out.
┌→ urgency
├→ category
STATE → JEV ─────┼→ sentiment
├→ refund?
└→ escalation?
2. Treat uncertainty as part of the interface.
Typed does not mean infallible. So your application can explicitly decide:
high confidence → automate
uncertain → gather more evidence
lower confidence → human review
And those thresholds should depend on the consequence of being wrong. Showing the wrong help article and moving money should obviously not share the same risk policy.
3. Keep side effects in code.
Jev can help determine:
"Does this look like a cancellation request?"
Your application should still own:
permissions
authorization
transactions
tool execution
policy
side effects
4. Use Jev around generative models too.
This is where I think things get especially interesting.
INPUT
↓
Jev guardrail
↓
LLM
↓
Jev verification
↓
CODE
↓
return / retry / escalate
Or with RAG:
query
↓
retrieve 50 passages
↓
Jev relevance / injection judgments
↓
keep the useful context
↓
reasoning model
The broader idea is: We're very quickly giving software access to increasingly powerful reasoning and agency. But not every intelligent decision needs an agent. Sometimes software just needs a tiny piece of machine judgment.
My mental model for Jev is increasingly:
CODE
↓
encounters something deterministic code can't understand
↓
JEV
↓
small typed probabilistic judgment
↓
CODE
↓
continues deterministically
Or even shorter: Give normal software access to programmable common sense.
I packaged the architecture rules into a reusable SKILL.md so coding agents can recognize those boundaries themselves. Works with Cursor / Claude Code / compatible skill harnesses. MIT licensed.
I recommend pairing it with TypeSafe's official skill:
their skill → how to implement Jev
This skill → where and why to use Jev
Repo: https://github.com/samtay32/jev-system-architect
How Jev fits in the loop
- The coding agent inspects existing semantic logic and its surrounding code.
- The skill identifies candidate bounded judgments and maps them to Jev primitives.
- The developer decides whether to implement the boundary and how to handle uncertainty.
How to reproduce
- Install or read the skill and run it against a small codebase containing a semantic parser-and-retry pipeline.
- Record each proposed Jev boundary and the evidence in the code that triggered it.
- Implement only one bounded decision and keep permissions, side effects, and execution in deterministic code.
Why this build matters
This is a foundational architecture case for explaining not just how to call Jev, but when Jev belongs in an agent system.
Limitations
- This is an architecture aid, not proof that every proposed boundary improves a production system.
- The skill cannot replace open-ended reasoning, code generation, or authorization logic.
- Every suggested boundary needs human review and a task-specific evaluation set.