Software Asset Management · IT Procurement
Check Software License Justifications Before Procurement Review
A request such as “I need software for work” leaves a procurement reviewer with little to assess. Use this example to check for a stated work purpose and project reference before starting the approval process.
Updated · Examples verified with jev-1.13.0
The problem
Software license requests often arrive with vague justifications. A procurement reviewer needs a stated purpose and project reference before checking budget, entitlement and approval rules. This example checks whether the submitted text supplies those two details so the application can request missing information first.
How TypeSafe helps
Send the justification text as state and ask v_01 whether it includes a concrete purpose and a specific project identifier. The primary example supplies both details, while the vague and empty examples do not. Your application can use the returned Noul probability to separate requests that are ready for procurement review from requests that need more information. Choose that threshold using your own labeled examples, then check project records, budget and approval rules separately before granting a license.
- Input
- The 'justification' field submitted in the procurement form.
- Decision
- Noul: Does the justification state a concrete work purpose and include a specific project identifier?
- Next action
- Send sufficiently complete requests to procurement review; ask the requester for more detail when the justification is incomplete.
Three verified examples
These responses were returned during a previous API verification. New probabilities can differ.
Standard Justification Check (primary)
Expected behavior: The justification contains a clear software purpose and a recognizable project identifier, warranting a high probability of 'true'.
Input
{
"justification": "I need the Adobe Creative Cloud license to complete the UI assets for Project X-402."
}Previous verification response
jev-1.13.0 ·
{
"model": "jev-1.13.0",
"answers": {
"v_01": {
"type": "noul",
"noul": 0.98
}
},
"usage": {
"input_tokens": 359,
"output_tokens": 23
}
}Vague Justification Check (alternative)
Expected behavior: The justification is generic and lacks a specific project identifier, yielding a low probability of 'true'.
Input
{
"justification": "I need software tools for my daily work."
}Previous verification response
jev-1.13.0 ·
{
"model": "jev-1.13.0",
"answers": {
"v_01": {
"type": "noul",
"noul": 0.04
}
},
"usage": {
"input_tokens": 348,
"output_tokens": 23
}
}Empty Justification Edge Case (edge case)
Expected behavior: The empty justification contains neither a purpose nor a project reference, so the expected probability is low. The application can ask the requester to fill in these details.
Input
{
"justification": ""
}Previous verification response
jev-1.13.0 ·
{
"model": "jev-1.13.0",
"answers": {
"v_01": {
"type": "noul",
"noul": 0.02
}
},
"usage": {
"input_tokens": 339,
"output_tokens": 23
}
}Try online
Start with a verified example, edit the request, then ask Jev. A live request is sent only when you press Try online.
Expected behavior: The justification contains a clear software purpose and a recognizable project identifier, warranting a high probability of 'true'.
Use non-sensitive test data. Live input goes to typesafe.pro and TypeSafe. Anonymous requests use the gateway’s free rate limit.
Probability that the answer is yes
Near 1 is a strong yes. Near 0 is a strong no. Around 0.5 means uncertainty. Noul has no separate confidence value.
import jsonfrom urllib.error import HTTPError, URLErrorfrom urllib.request import Request, urlopenBASE_URL = "https://api.typesafe.pro"payload = { "model": "jev-latest", "state": { "justification": "I need the Adobe Creative Cloud license to complete the UI assets for Project X-402.", }, "questions": { "v_01": { "type": "noul", "instructions": "Does the justification state a concrete work purpose and include a specific project identifier? Check only whether these details are present, not whether a project is active or a license is approved.", "criteria": { "true": "Request contains clear intent and specific project ID", "false": "Request is vague or missing identifiers", }, }, },}request = Request( f"{BASE_URL}/v1/systemone", data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"}, method="POST",)try: with urlopen(request, timeout=20) as response: result = json.load(response)except HTTPError as error: raise SystemExit(f"API returned HTTP {error.code}") from errorexcept URLError as error: raise SystemExit(f"Connection failed: {error.reason}") from errorprint(json.dumps(result["answers"], indent=2))Limitations and review
- A project identifier in text does not establish that the project exists or is active. Check an authoritative project registry separately.
- This request checks the completeness of a justification. It does not establish entitlement, budget availability or procurement approval.
- A single Noul answer does not identify which detail is missing. Separate questions can check purpose and project reference individually.
Set thresholds against your own examples before relying on an automated decision.