Build Jev Checkpoints in Claude Code

Create reusable typed AI decision checkpoints in your Claude Code workflow.

Introduction

30 Second Summary

When you ask an assistant whether a risky change is ready, a thoughtful paragraph can still leave the next action fuzzy. The wording can shift each time you ask the same question.

In this project, you will add a reusable decision checkpoint to Claude Code using Jev. The checkpoint turns a compact change summary into a typed next action.

What You'll Build

Picture a fresh Claude Code session turning a risky change summary into a typed decision with evidence-aware next steps.

By the end of this project, you'll have:

A verified TypeSafe agent skill in Claude Code that helps you compare a prose-only review with a typed Jev result.
A reusable change-review checkpoint that returns one bounded Choice plus two independent Noul judgments. You can inspect its probabilities. You can also inspect Choice confidence and token usage.
A daily review workflow stored in CLAUDE.md. Fresh sessions use it to gather evidence and recommend the next action while keeping security decisions under human control.
Secret Mission: Add a planning checkpoint that compares implementation directions before coding begins.

Are there any prerequisites?

You need an existing macOS project in Claude Code plus access to the TypeSafe System One API. Skill setup and session key export are included.

Before We Start

A useful Jev checkpoint starts with a real project and one recurring change-review decision. This commitment gives every later experiment a practical target.

Install and Verify the TypeSafe Skill

Your checkpoint needs Claude Code to understand TypeSafe's current Jev workflow. The official skill supplies that guidance inside the session.

The API key must reach the same Claude Code process. This step keeps the credential inside one fresh shell.

In this step, get ready to:

Export the TypeSafe API key for one Terminal session.
Install the official TypeSafe marketplace plugin.
Verify the loaded skill in Claude Code.

Export the API key for one shell

An environment variable gives programs launched from one shell access to a value. Closing the shell removes this session-scoped export.

Keep the credential local

Handling an API key deserves a careful pause. This setup makes the credential available inside one Terminal shell.

Claude Code inherits the key without needing the real value in chat or project files.

Use macOS search to find Terminal.
Select Terminal to open a fresh shell window.
Replace your-key-here with your real TypeSafe API key in the command below.
Export the key for this shell by running the edited command:

export TYPESAFE_API_KEY="your-key-here"

What does this command do?

The export command sets TYPESAFE_API_KEY in the current shell environment. A Claude Code process launched from this window inherits it.

The command returns to the prompt without printing the key. That quiet response is expected.

Keep this Terminal window open for the rest of the step.

Shell not returning to the prompt?

Compare the opening quotation mark with the closing quotation mark.
Remove any line break that entered the command with your key.

Ask for help without sharing the credential: Help me check why my TYPESAFE_API_KEY export is not returning to the prompt.

Install the official TypeSafe skill

A Claude Code plugin packages extra instructions for the assistant. The marketplace identifies the official source for the TypeSafe plugin.

Install the official marketplace plugin by running these commands:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

What do these commands set up?

The first command adds typesafe-ai/skills as the marketplace source.
The second command installs typesafe@typesafe-ai from that marketplace.

Both commands should finish without a failure.

That is the setup in place: Claude Code can now load the TypeSafe skill.

Plugin installation stopped?

Confirm that your Mac has internet access.
Compare the marketplace path with typesafe-ai/skills.
Compare the plugin identifier with typesafe@typesafe-ai.
Rerun the two installation commands after correcting either value.

Get help with the installation output: Help me diagnose my TypeSafe plugin installation.

Verify the skill in Claude Code

A process started from a shell inherits its environment variables. Starting Claude Code here makes TYPESAFE_API_KEY available to that session.

Start Claude Code from this Terminal window by running this command:

claude

Why launch from this window?

This starts Claude Code as a child of the current shell. The interactive session inherits the exported API key.

If Claude Code asks for plugin activation, reload the active plugins by entering this command:

/reload-plugins

What does reloading change?

This reloads active Claude Code plugins without restarting the session. Skip this command when no activation request appears.

Before you inspect the session, make a quick prediction about where the TypeSafe skill appears. Decide whether its direct invocation should load.

Inspect the loaded Claude Code session by entering this command:

/context

What should /context show?

Under Skills, you should see the TypeSafe skill. This confirms that the plugin is active in the current session.

Invoke the TypeSafe skill once by entering this command:

/typesafe:typesafe-ai

What confirms the skill loaded?

You should see the TypeSafe skill load. Claude Code should not report an unknown-command error.

Skill missing or unavailable?

Enter /reload-plugins in the current Claude Code session.
Enter /context again to confirm the TypeSafe skill appears under Skills.
Confirm that Claude Code started from the Terminal shell where you exported the key.

Get help without exposing the key: Help me verify why the TypeSafe skill is unavailable.

Your Claude Code session can now reach TypeSafe guidance with the session-scoped key. Next, you will test what a prose-only review leaves awkward for a repeatable workflow.

Review the Prose-Only Baseline

Your Claude Code session now has the official TypeSafe skill ready. That setup gives you a controlled place to compare review styles.

A normal review gives useful advice through free-form prose. This step tests whether that answer has a stable shape that a repeatable workflow can consume.

In this step, get ready to:

Submit the risky account-email request to Claude without using TypeSafe or Jev.
Inspect the prose response for an unbounded recommendation.
Record why the response shape is difficult for a workflow to consume consistently.

Run the prose-only review

A fair baseline keeps the change request specific while leaving the response format open. This lets Claude reason naturally before you assess how reusable the answer is.

Before you submit the request, predict whether Claude will return advice in a fixed shape every time.

In the Claude Code session from earlier, submit this request exactly as written:

Review this change request without using TypeSafe or Jev. Answer in prose.

Change request: Let signed-in users change their account email. The current implementation updates the email immediately. There is no re-authentication, verification email, audit event, or test covering the change.

Tell me whether it is ready to ship and what I should do next.

What Does This Baseline Test?

The request supplies one concrete identity-related change.
The opening line keeps TypeSafe plus Jev out of this run.
The final question invites advice without requiring a fixed response schema.

Claude should return a readable recommendation about whether the change is ready to ship. Its wording can vary because the request asks for prose.

No Usable Baseline?

Confirm that you submitted the complete request in the active Claude Code session.
Resubmit the exact request if the response invokes TypeSafe or Jev.

Ask for help diagnosing an unexpected baseline response.

You now have a clean baseline. The response shows what a person can understand before you test what a workflow can reliably extract.

Find the workflow gaps

A person can interpret flexible wording from context. A repeatable workflow needs predictable labels with bounded values.

Read Claude's response again.
Locate the recommendation about whether the change is ready to ship.
Identify the phrases that describe risk or urgency.
Check whether the recommendation comes from a fixed list of options.
Check whether the risk language uses a fixed scale.

Why Fixed Fields Matter

Free-form phrases can communicate the same idea with different words. A workflow must interpret each variation before it can choose a route.

Fixed field names give automation stable values to inspect. This makes the shape of the answer as important as the quality of its advice.

Before you check the response field by field, predict whether all four labels will appear in a fixed structure.

Search the response for a fixed choice field.
Search the response for a fixed probabilities field.
Search the response for a fixed confidence field.
Search the response for a fixed noul field.

Your review should have no fixed choice field. It should have no fixed probabilities field.

Your review should have no fixed confidence field. It should have no fixed noul field.

That is the key gap exposed. Claude produced useful advice for a person without producing a stable decision object for a workflow.

Your prose-only baseline is recorded. Next, you will send the same evidence through a bounded Jev checkpoint to compare the response shape.

Run a Typed Jev Checkpoint

Your prose-only baseline captured useful security concerns. Its recommendation still has no fixed value that a workflow can route on.

Now you will use the TypeSafe skill to send the same weak evidence to Jev. Claude Code will receive bounded fields that support a repeatable next action.

In this step, get ready to:

Ask the TypeSafe skill to read the current API documentation.
Run one Jev request containing one Choice question and two independent Noul questions.
Verify the resolved model ID, typed values, applicable probabilities, Choice confidence, and token usage.

Load the live TypeSafe guidance

The TypeSafe skill gives Claude Code the current API shape for System One requests. Reading the live documentation keeps the experiment aligned with the service.

Return to the Claude Code session that inherited your session-scoped API key.
Invoke the TypeSafe skill by entering:

/typesafe:typesafe-ai

What does this command do?

This command loads the official TypeSafe skill inside your current Claude Code session. The skill can then read the live documentation before creating the request.

You should see the TypeSafe skill load without an unknown-command error.

Run the three-question experiment

A structured state gives each question the same compact evidence. Jev evaluates the questions independently within one request.

The TYPESAFE_API_KEY remains in the shell environment from earlier. You keep the real value out of Claude chat.

Before you submit the experiment, which bounded next action do you expect the weak evidence to support?

Submit the complete experiment prompt below in the Claude Code session:

Use the TypeSafe skill to read the current live TypeSafe API documentation.

Run one Jev experiment using the TYPESAFE_API_KEY already exported in this environment.

Use this change request as structured state:
Change request: Let signed-in users change their account email.
Current implementation: The email updates immediately.
Missing evidence: There is no re-authentication, verification email, audit event, or test covering the change.

Ask these three independent questions together:

1. next_action, a Choice with these options:
- proceed: the available evidence shows the change is ready for the normal delivery path.
- add_tests: the direction is acceptable, but test or verification evidence is missing.
- human_review: identity, security, or unclear requirements require a person to decide.

2. requirements_satisfied, a Noul asking whether the supplied evidence shows that the change's stated requirements are satisfied.

3. security_sensitive, a Noul asking whether the change affects authentication, identity, credentials, permissions, or another security-sensitive boundary.

Show the resolved versioned model ID, typed answers, probabilities and confidence where those fields exist, and token usage.

Run one request containing all three questions. Do not implement the account-email change. Do not ask me to paste the API key.

Why use one request?

All three questions receive the same state. Their independent evaluations prevent one answer from becoming evidence for another.

The bounded option criteria also make the result inspectable. Claude can recommend a next action from named values instead of interpreting open-ended risk language.

Claude should return one Jev result covering all three question IDs. Your project code should remain unchanged.

No Typed Result Yet?

Keep your API key out of chat if Claude asks you to provide a credential.
Return to the Claude Code session launched from the configured terminal if the environment credential is unavailable.
Repeat the instruction to run one experiment if Claude only describes a possible request.

Help me diagnose why Claude Code did not return a typed Jev result.

Inspect the typed result

The response shape determines whether another workflow can consume the judgment consistently. Each field has a specific role in that shape.

How Do the Result Fields Differ?

The choice field names the selected next_action option.
The probabilities field shows the Choice distribution across the three options.
The confidence field summarizes the Choice probability distribution.
Each noul value falls between 0 and 1. A Noul answer has no separate confidence field.
The usage section reports input_tokens and output_tokens.

Find the resolved versioned model ID in the response's model field.
Confirm that next_action includes choice, probabilities, and confidence.
Confirm that requirements_satisfied contains a noul value.
Confirm that security_sensitive contains a noul value.
Find the input and output token counts under usage.
Confirm that Claude did not implement the account-email change.

You should see a versioned model ID, three typed answers, applicable probabilities, Choice confidence, and token usage from one request.

That is the key shift complete. Your change review now produces a bounded result that you can inspect without giving the model control over implementation.

Your weak-evidence checkpoint is working. Next, you will test how stronger evidence changes its bounded judgments.

Test Evidence and Escalation

Your first Jev checkpoint in Claude Code gave you bounded values for the risky account-email change. Those values are still model judgments.

A typed result becomes reusable only after you test it with contrasting evidence. An explicit escalation rule keeps incomplete or uncertain cases from being treated as approval.

In this step, get ready to:

Rerun the checkpoint with stronger account-email evidence.
Build a side-by-side comparison of both typed results.
Draft a provisional policy for evidence gathering plus human review.

Rerun with stronger evidence

Jev evaluates the structured state you supply. A controlled comparison keeps the change plus the Choice and Noul questions fixed.

This makes one billed TypeSafe request. The request stays compact because it contains only the evidence needed for the comparison.

Before you run the second request, do you expect every typed value to change when the evidence improves? The result will test that prediction.

In the Claude Code session from earlier, paste this controlled comparison prompt:

Rerun the same three questions with stronger state.

Require recent re-authentication. Send a verification link to the new address. Preserve the old address until verification. Emit an audit event. Include focused tests.

Reuse next_action, requirements_satisfied, and security_sensitive exactly as before. Show the resolved versioned model ID, typed answers, probabilities and confidence where those fields exist, and token usage. Do not implement the account-email change.

What does this prompt control?

The account-email change stays fixed. The evidence becomes the only experimental variable.
The three question IDs stay fixed. Both responses remain comparable.
The final lines request the same observable fields used in the weak-evidence checkpoint.

Why use one request?

Questions in one TypeSafe request see the same state. Jev evaluates each question independently.

Submit the prompt in Claude Code.

Claude should return a second response with a resolved versioned model ID plus typed values. You should also see applicable probabilities plus Choice confidence.

Token usage should appear for the request. The account-email change should remain unimplemented.

Did Claude start implementing?

Stop the response if Claude begins editing project files.
Restate that this request is a decision experiment only.

Help me keep Claude focused on the Jev evidence experiment without implementing the account-email change.

You now have both sides of the experiment. The stronger state produced a second inspectable Jev result.

Compare the typed results

The comparison must report only what the two responses contain. Causal stories would turn observed values into invented model reasoning.

Before you compare the calls, which fields do you expect to move most clearly? The table will make those changes visible.

Paste this comparison prompt into the same Claude Code session:

Compare the weak-evidence and strong-evidence responses side by side. Do not invent an explanation from Jev.

Record the versioned model ID, selected Choice, Noul probabilities, Choice confidence, and token usage for each call. Record whether each typed value changed.

What should the comparison contain?

Each column represents one evidence condition.
Each row uses a field already recorded from both calls.
The final row records whether each typed value changed.

Submit the comparison prompt in Claude Code.

You should see weak-evidence plus strong-evidence columns. Each column should show the versioned model ID plus the selected Choice.

The table should also show both Noul values plus Choice confidence. Token usage should include input_tokens plus output_tokens for each call.

Choice confidence comes from the answer probability distribution. A flatter distribution produces lower confidence.

Each Noul returns a noul value from 0 to 1. It has no separate confidence field.

Are fields missing from the table?

Ask Claude to rebuild the table from the two recorded raw responses.
Check that each Noul appears without a separate confidence field.
Request an explicit changed-or-unchanged entry for every typed value.

Help me compare my two Jev responses without inventing an explanation for the differences.

The comparison is now inspectable. A changed value records model behavior without pretending to explain its cause.

Keep the key off screen

Capture only the side-by-side comparison output.
Exclude any terminal line that could reveal your session-scoped API key.

Draft the escalation policy

A routing policy determines what happens after the typed result arrives. It keeps Jev inside a narrow decision role.

Before you generate the policy, do you expect incomplete evidence to permit automatic approval? The final rules will answer that question.

Paste this policy prompt into the same Claude Code session:

Draft a provisional routing policy.

Keep deterministic checks in code. Make incomplete state trigger evidence gathering. Send security-sensitive or materially uncertain cases to human review. Keep numerical thresholds provisional until they are tested on representative examples from the real project.

What does this policy protect?

Deterministic checks remain executable rules in code.
Incomplete state leads to evidence gathering.
Security-sensitive or materially uncertain cases lead to human review.
Numerical thresholds remain provisional until real-project testing supports them.

What stays deterministic?

Test results plus permission enforcement remain deterministic controls. Jev supplies a bounded semantic judgment over the evidence provided.

Submit the policy prompt in Claude Code.

You should see deterministic checks stay in code. Incomplete state should trigger evidence gathering.

Security-sensitive or materially uncertain cases should require human review. Numerical thresholds should remain provisional until representative project examples validate them.

Does the policy grant automatic approval?

Remove any rule that treats a Jev result as permission to execute a change.
Route security-sensitive cases to human review.
Mark every numerical threshold as provisional.

Help me revise my Jev routing policy so deterministic controls plus human approval keep final authority.

Your checkpoint now turns uncertainty into an explicit route. Code plus people keep final authority.

Your evidence test now has an explicit safety route. Next, you will make the checkpoint repeatable in fresh Claude Code sessions.

Persist the Daily Workflow

Your Jev checkpoint now responds to contrasting evidence with bounded decisions. You have also defined when uncertainty should trigger evidence gathering or human review.

Future Claude Code sessions need the same guidance before this experiment can become a daily workflow. A project instruction file keeps the checkpoint available while preserving its advisory role.

In this step, get ready to:

Preserve your existing project instructions while appending the Jev review policy.
Confirm a fresh Claude Code session loads the policy and TypeSafe skill.
Review one realistic risky change through the persisted checkpoint.

Add the Jev policy to CLAUDE.md

A project-level ./CLAUDE.md gives each fresh Claude Code session the same workflow guidance. The policy defines when to use Jev while keeping security decisions under stronger controls.

Return to the Claude Code session from earlier.
Ask Claude to read ./CLAUDE.md before making changes.
Ask Claude to preserve every existing project instruction.
Ask Claude to append the following section exactly:

## Jev decision checkpoints
- Use Jev for bounded semantic judgments over supplied evidence, not deterministic checks ordinary code can perform.
- Read current TypeSafe documentation through the TypeSafe skill before creating or changing API requests.
- For risky or ambiguous changes, send only relevant requirements, change summaries, and test evidence as structured state.
- Ask independent questions against the same state together; start with next_action, requirements_satisfied, and security_sensitive.
- Report resolved model ID, typed values, probabilities, confidence where available, and token usage.
- Gather more evidence or request human review when state is incomplete or the decision is materially uncertain.
- Never treat Jev or CLAUDE.md as a permission boundary, security control, or replacement for tests and human approval.
- Never paste or commit TYPESAFE_API_KEY.

What does this policy establish?

The opening rules reserve Jev for bounded judgments over relevant evidence.
The reporting rule makes every model decision inspectable.
The final rules keep tests and human approval in control.

Ask Claude to save the updated ./CLAUDE.md file.
Ask Claude to display the final ## Jev decision checkpoints section.
Confirm every previous project instruction still appears above the new section.

You should see your original project guidance followed by the new Jev policy. The final line should protect TYPESAFE_API_KEY from chat and committed files.

Did Claude replace your existing instructions?

Ask Claude to restore the previous contents of ./CLAUDE.md.
Ask Claude to append the Jev section after the restored instructions.

Help me restore my project instructions before appending the Jev policy.

✔️ Awesome, I've got everything!

Your existing project instructions remain intact. The Jev policy now appears at the end of ./CLAUDE.md.

ⓧ I'd like to double check the full code

Keep your existing project instructions above this section. Compare the appended portion character for character.

## Jev decision checkpoints
- Use Jev for bounded semantic judgments over supplied evidence, not deterministic checks ordinary code can perform.
- Read current TypeSafe documentation through the TypeSafe skill before creating or changing API requests.
- For risky or ambiguous changes, send only relevant requirements, change summaries, and test evidence as structured state.
- Ask independent questions against the same state together; start with next_action, requirements_satisfied, and security_sensitive.
- Report resolved model ID, typed values, probabilities, confidence where available, and token usage.
- Gather more evidence or request human review when state is incomplete or the decision is materially uncertain.
- Never treat Jev or CLAUDE.md as a permission boundary, security control, or replacement for tests and human approval.
- Never paste or commit TYPESAFE_API_KEY.

Verify a fresh session loads the workflow

A fresh session proves your policy survives beyond the experiment that created it. Claude Code must load the project file before it can follow the workflow.

The TypeSafe skill must also remain active. Its guidance supplies the current request pattern whenever Claude creates or changes a Jev call.

Exit the current Claude Code session.
Switch back to the macOS Terminal shell from earlier.
Start a fresh Claude Code session by running this command:

claude

What does this launch prove?

Launching from the same shell gives the fresh Claude Code process access to the session-scoped TYPESAFE_API_KEY. The key remains outside your project files.

Before you inspect the new session, which two sources do you expect Claude Code to load?

Inspect the fresh session's loaded context by entering:

/context

What does this check?

The context view shows which skills and memory files are available to the current session. It confirms whether the persisted workflow can guide this new conversation.

You should see the TypeSafe skill under Skills. You should also see ./CLAUDE.md under Memory files.

Where Does Enforcement Live?

Claude Code reads ./CLAUDE.md as behavioral context. The file guides future sessions.

Tests remain the executable control layer. Permissions remain a separate safeguard.

Human approval remains responsible for sensitive decisions.

Missing the skill or memory file?

Confirm the fresh session was launched from the same terminal shell that contains the exported key.
Confirm ./CLAUDE.md is stored in the selected project's top-level folder.
Confirm the TypeSafe plugin remains active in Claude Code.

Help me diagnose missing Claude Code context without exposing my API key.

Run a real risky-change review

The persisted workflow matters when a fresh session applies it to a real project decision. This final check asks Claude to gather compact evidence before making one bounded Jev request.

Select one realistic risky or ambiguous change from your chosen project.

Before you submit the change, do you expect the available evidence to support a next action or trigger more evidence gathering?

Run the persisted workflow by pasting this prompt into the fresh Claude Code session:

Review this risky change from my project using the Jev decision checkpoint in ./CLAUDE.md.

Change: [[RISKY_CHANGE="describe one realistic risky change from your project"]]

Gather only relevant requirements, change summaries, and test evidence as structured state. Use the TypeSafe skill to read current documentation. Ask next_action, requirements_satisfied, and security_sensitive together in one Jev request. Show the resolved model ID, typed values, probabilities, confidence where available, and token usage. Recommend a next action. Do not claim Jev generated an explanation. Do not implement the change.

What does this prompt test?

The prompt tests whether a fresh session follows the persisted review pattern. It limits the request to evidence that affects the decision.

The three questions share one state while remaining independent. Claude uses their typed results to recommend the next action.

Claude should show the compact evidence set before its recommendation. You should then see typed next_action, requirements_satisfied, and security_sensitive values from one Jev request.

The result should include the resolved model ID. It should also include probabilities, available confidence, and token usage.

Claude should recommend a next action from the typed evidence. Its explanation should remain Claude's interpretation of the result.

Did Claude skip the persisted workflow?

Check that /context lists both the TypeSafe skill and ./CLAUDE.md.
Confirm your review prompt asks for all three starting questions in one request.
Confirm the prompt requests the resolved model ID and token usage.

Help me diagnose why my persisted Jev review did not return the required typed fields.

That closes the loop. Your checkpoint now survives a fresh Claude Code session.

Risky reviews now return inspectable Jev evidence before Claude recommends a next action.

Frame your validation screenshot around the typed result and recommended action.
Keep your API key and sensitive project details outside the screenshot.

Secret mission

Add a Jev Planning Checkpoint

Move your Jev workflow earlier, before implementation begins. You will add a conditional planning Choice that compares two real approaches after deterministic constraints are checked. You will keep the rule only when the result improves the plan.

Clean Up Your Resources

Future live requests to Jev through the TypeSafe System One API incur usage-based costs. The choices below cover keeping, pausing, or removing the workflow.

Cost warning

Future TypeSafe API calls continue to incur usage charges. Jev 1.13 is listed at $0.042 per 1 million input tokens. Output tokens are free.

Resources you used:

The official TypeSafe plugin installed in Claude Code.
The TYPESAFE_API_KEY environment variable exported in the current macOS Terminal shell.
The ## Jev decision checkpoints section appended to ./CLAUDE.md.

Keep everything running

No action needed. Choose this if you plan to keep using the checkpoint for change reviews or implementation planning.

Leave the TypeSafe plugin enabled in Claude Code.
Keep the ## Jev decision checkpoints section in ./CLAUDE.md.
Keep the current Terminal shell open while you continue making live Jev requests.
Use live requests selectively because each call adds input-token usage.

Pause - I'll come back to this later

Pause the workflow without deleting the plugin or project policy. The ./CLAUDE.md instructions remain available for later.

Enter /plugin in the current Claude Code session.
Select the Installed tab.
Select the installed TypeSafe plugin.
Disable the selected plugin from the Installed tab.
Exit the current Claude Code session.
Close the current macOS Terminal window to remove the session-scoped TYPESAFE_API_KEY.

Your workflow is now paused. The project policy remains ready for a later session.

Delete - I don't want to use this again

Remove the workflow when you no longer want Jev involved in this project. Your existing project instructions stay in place.

Ask Claude to remove only the ## Jev decision checkpoints section from ./CLAUDE.md.
Review ./CLAUDE.md to confirm the existing project instructions remain.

Your original project guidance remains intact. The reusable checkpoint policy is now gone.

Enter /plugin in the current Claude Code session.
Select the Installed tab.
Select the installed TypeSafe plugin.
Uninstall the selected plugin from the Installed tab.
Check the Installed tab to confirm the TypeSafe plugin is no longer listed.
Exit the current Claude Code session.
Close the current macOS Terminal window to remove the session-scoped TYPESAFE_API_KEY.

Your API Key Stayed Private

The TypeSafe API key existed before this workflow. This project kept it outside chat and project files.

Closing the Terminal removes the environment state created during this project. This cleanup does not revoke your pre-existing TypeSafe API key.

Nice Work!

You made it! Your Claude Code workflow now uses Jev to return bounded review decisions while tests, deterministic checks, permissions, and human approval remain in control.

You've learned how to:

Use the official TypeSafe skill inside Claude Code to run a typed checkpoint that reports the resolved model ID, probabilities, available confidence, and token usage.
Replace free-form review prose with one Choice plus two independent Noul judgments. You also compared weak evidence with strong evidence using the same structured state.
Carry the checkpoint into fresh sessions through ./CLAUDE.md while keeping deterministic checks, tests, security controls, and human approval authoritative.
Secret Mission: Tested a conditional planning checkpoint that compares real implementation approaches with one bounded Choice. It requests missing evidence when the supplied state cannot support a direction.

Ready to quiz yourself?