Blog

Validating AI Order Data in C# With IntentSharp

An AI response can be valid JSON, deserialize into a C# object, and still be unsuitable for the next step in your application. An order quantity can be missing. A stock code can have the wrong format. Your application needs to decide which values it accepts and what happens when an answer fails those checks.

This walkthrough uses IntentSharp’s order-extraction example to show that boundary. The example uses scripted model responses, so the results demonstrate checking and retry behavior rather than model accuracy.

Start with the order your application needs

The example extracts a purchase request with four fields: Contact, Sku, Quantity, and DeliverBy. Quantity is an int?, allowing the result to represent a value that was not supplied.

Consider these two emails:

Hi, this is Dana from Northwind. We’d like 40 units of SKU A-1192 delivered by 2026-11-15.

Hi, Dana from Northwind again. Please send the A-1192 belts by 2026-11-15; I will confirm how many tomorrow.

Both messages describe an order, but only the first gives a quantity. The application should retain that distinction.

Put executable checks and limits on the call

In the following excerpt from the worked example, client is an initialized IntentSharp client and email is the current input string. OrderRequest is the example’s result type; this excerpt is not a complete program. The quick start covers client setup.

The quantity check rejects null, zero, and negative quantities. The SKU check requires one uppercase letter, a hyphen, and four digits. These checks execute in the application process.

The call, with its checks and limits
// The rules and the limits are options on the call. The parse,// the checks, the retry with the findings and the attempt log are// the call's own.var options = new AIRequestOptions{    MaxAttempts = 3,    MaxModelCalls = 4,    Timeout = TimeSpan.FromSeconds(20),}.Require<OrderRequest>(o => o.Quantity is > 0,    "Quantity must be a positive number.").Require<OrderRequest>(o => Regex.IsMatch(o.Sku, @"^[A-Z]-\d{4}$"),    "Sku must look like A-1192."); var order = await email.AIAsync<OrderRequest>(    client, "Extract the purchase request from this email.", options);

MaxAttempts allows up to three attempts for this request. MaxModelCalls imposes a separate ceiling of four model calls, and Timeout supplies a 20-second time budget. Those limits bound the work; they do not guarantee a successful answer or set a dollar spending cap.

Inspect a failed check followed by a passing attempt

For the first email, the scripted first answer contains A1192 instead of A-1192. It fits in a string, but fails the SKU format check. IntentSharp sends the finding into the retry, and the next scripted answer passes.

Output: Email 1
Email 1:  Attempt 1 passed: false    [Validator] attempt 1: Sku must look like A-1192.  Attempt 2 passed: true  Success: true, after 2 attempts  Value: OrderRequest { Contact = Dana (Northwind), Sku = A-1192, Quantity = 40, DeliverBy = 2026-11-15 }

This gives the application more than a deserialized object: it can inspect which attempt passed and why the earlier attempt failed.

Treat exhausted retries as a result to handle

For the second email, every scripted answer leaves Quantity null. Each attempt fails the positive-quantity check. After the third attempt, the call returns an unsuccessful result.

Output: Email 2
Email 2, which gives no quantity:  Attempt 1 passed: false    [Validator] attempt 1: Quantity must be a positive number.  Attempt 2 passed: false    [Validator] attempt 2: Quantity must be a positive number.  Attempt 3 passed: false    [Validator] attempt 3: Quantity must be a positive number.  Success: false, after 3 attempts  FailureSummary: Quantity must be a positive number.

The application can use Success, Issues, and Attempts to choose its next step. For this order, a sensible application decision is to request the missing quantity or route the request for review before creating a sales order or fulfillment action. That routing remains application code; the example does not perform those downstream actions.

Match the checks to the decision

A passing check establishes only the condition it evaluates. The SKU expression checks format, not whether a product exists. The quantity rule checks for a positive number, not whether that number appeared in the email. A model could invent a positive quantity and pass that particular rule.

For a workflow that needs an existing product, check the extracted SKU against an authoritative product catalog. For a quantity that must be supported by the input, add an appropriate source-verification or human-review step. More retries do not supply information that the customer has not provided.

The useful design habit is to name the conditions required for the next business action, make the enforceable ones executable, and give failed requests an explicit path. IntentSharp supplies the typed-call, checking, retry, and attempt-reporting behavior in this example; the application still owns its business decision.

Try the worked example

Read the IntentSharp validation and retry walkthrough to inspect the code and both outcomes together.

IntentSharp is a commercial .NET library. You can evaluate it free for 30 days on development and test systems; after that, any business use needs a paid license, including development, and production use needs one from the first day. Personal use and coursework stay free. I create and sell IntentSharp through C2Consultants LLC.

Delete the retry loop from your next call.

dotnet add package IntentSharp