What Jev could mean for Technical Writers

AI can produce documentation drafts quickly. But hard problems remain, such as deciding which product changes deserve documenting in the first place. When a product changes, some, but not all, of those updates need a documentation update. Someone has to make that call, find the source material, identify the affected content, and involve the right people.

That work creates a backlog. If those are items aren’t cleared from the backlog promptly, it can cause a ripple effect: poorly maintained source material gives customers, support teams, and AI assistants poor answers.

Jev is a new type of AI model that might help with that decision-making work.

What Jev is designed to do

Jev comes from TypeSafe AI, which describes it as a “System One Model”. The term refers to fast, intuitive decision-making, rather than slow, deliberate reasoning.

Unlike a conventional large language model, Jev is not designed to write an answer in prose. It takes unstructured information and returns a pre-defined, structured decision with a confidence score.

For example, a documentation system could give the model a pull request summary and ask for this result:

{
"documentation_update_needed": true,
"affected_areas": ["authentication", "configuration reference"],
"change_type": "new capability",
"confidence": 0.91
}

The potential outputs are set in advance. The system does not need to interpret a paragraph of AI-generated text before deciding what to do next.

TypeSafe AI says Jev is built for classification, extraction, scoring, and workflow routing. It also claims low response times and type-safe outputs.

Jev is in early access, so documentation teams should test those claims against their own content and decisions. TypeSafe AI’s announcement explains the model’s approach.

The problem is not a lack of text

Generative AI tools can produce draft text. But documentation teams do more than write. They triage, verify, route, prioritise, test, and maintain.

Consider a product team that closes 50 engineering tickets in a fortnight. A Technical Writer needs to know:

• Which tickets change the customer experience?
• Which documentation pages are affected?
• Which tickets can be ignored?

A LLM can make a judgement, but it normally returns free-form text. That creates another task: checking whether the answer is complete, consistent, and based on the right evidence.

Jev’s proposition is narrower. You will be able to ask it to make one defined decision, return a known set of values, and say how certain it is.

Triage the product changes before they become documentation debt

The clearest use case is change-impact triage.

A documentation workflow could pass release notes, completed tickets, pull request descriptions, or feature specifications to Jev. The model could decide whether a documentation update is needed, identify likely product areas, and assign a confidence score.

High-confidence cases could create a task in the documentation backlog.

Low-confidence cases could go to a Technical Writer for review.

The model helps the team find the changes that need attention. That should help minimise the build up of documentation debt.

Find problems across a large documentation set

Jev could also help teams inspect an existing documentation set.

Many organisations have hundreds or thousands of pages. They might not know which pages use retired product names, describe old UI labels, lack an owner, or cover features that no longer exist.

A model could review pages in batches and return structured labels such as:

A high-confidence finding can enter a prioritised cleanup queue.

A low-confidence finding is a prompt for a person to investigate, not a reason to rewrite a page automatically.

This could give documentation managers a better view of the material they own.  It could also provide evidence for a content maintenance programme, rather than relying on a general sense that the documentation is getting old.

Use it as a check on AI-assisted documentation

There is another obvious use: checking documentation created with generative AI.

A structured decision model could check defined points before the draft reaches an editor:

• Is every prerequisite present?
• Does the text make a claim not supported by the supplied source?
• Does it use an approved product name?
• Does it tell the reader to use a retired feature or workflow?
• Does the procedure contain an action that needs testing?

The same approach could check content before it enters a RAG system or becomes source material for an AI assistant. If the source documentation is inaccurate, the assistant will reproduce the error at scale.

Start with one repeated decision

1. Choose a decision that currently happens in a triage meeting, spreadsheet, or backlog review.
2. Define the permitted answers.
3. Gather a sample of decisions already made by experienced Technical Writers.
4. Compare the model’s answers with the team’s answers.

For example:

“Does this completed engineering ticket require a documentation update?”

The output could be:

Decision: yes / no / needs review
Affected product area: selected from an agreed list
Reason for review: selected from an agreed list
Confidence: 0 to 1

Measure the missed changes, false alarms, and review time.

Jev’s promise is it could help Technical Writers spend less time finding the work, and more time making the information clear, accurate, complete, maintained, and useful.

This is the type of solution we’ll be including in our upcoming Managing documentation projects with AI course.

Note: The initial draft was written with the help of ChatGPT, and the image was generated by ChatGPT.