How I Built an AI Interpretation Pipeline Without Letting the LLM Control the Rules

When I started building an AI-powered I Ching application, one architectural question became important very quickly:

What should the AI actually be allowed to decide?

My answer was: much less than I originally thought.

I’m building Quick I Ching, an application that combines traditional I Ching casting methods with AI-generated interpretation.

The interesting part was not simply connecting an LLM to a prompt.

The real challenge was separating deterministic product rules from probabilistic AI output.

The basic architecture

A simplified version of the flow looks like this:

User question
      ↓
Safety / eligibility checks
      ↓
Deterministic casting
      ↓
Structured hexagram data
      ↓
AI interpretation
      ↓
Output validation
      ↓
Successful result

The LLM is deliberately placed fairly late in the pipeline.

It does not decide the underlying hexagram.

It does not decide whether a generation should consume a paid credit.

It does not decide whether certain high-risk questions should be processed.

Those are application rules.

1. Keep deterministic rules outside the LLM

An I Ching reading contains structured information:

• the primary hexagram
• six lines
• moving lines
• the resulting hexagram when applicable
• the casting method
• contextual information supplied by the user

That information should already be correct before it reaches the model.

The AI receives a structured representation and is responsible for interpretation, not for reconstructing the underlying state.

This dramatically reduces an entire class of errors.

Instead of asking the model:

“Figure out the hexagram and explain it.”

the application can effectively tell it:

“Here is the verified state. Interpret this state.”

That distinction turned out to be one of the most important architectural decisions in the product.

2. Don't let AI control billing

Another problem appears when AI generation costs money.

A naive credit system looks like this:

Start request
→ deduct credit
→ call model
→ hope generation succeeds

I didn't want that behavior.

A generation can fail, time out, produce incomplete output, or fail validation. Charging the user simply because a request started would couple billing to infrastructure behavior rather than delivered value.

So the flow is closer to:

Reserve generation
→ generate
→ validate
→ success: consume credit
→ failure: release it

The important state transition is successful delivery, not “API request sent.”

3. Validate the output after generation

A successful HTTP response does not necessarily mean a successful AI result.

The generated interpretation can still be unusable.

For example:

• required sections may be missing
• the response may be truncated
• structured facts may conflict with the verified casting result
• content may repeat unexpectedly
• the interpretation may contain internal inconsistencies

So generation is followed by another application-controlled step:

LLM output
   ↓
Structural validation
   ↓
Consistency checks
   ↓
Accept / reject

If the result fails the required checks, it should not be treated the same as a valid completed reading.

This also makes the credit system easier to reason about: quality failure is a failed job, not a successful purchase.

4. Put safety checks before expensive generation

Some categories of questions should not simply be forwarded to a generative model.

In this application, higher-risk topics such as medical, legal, or investment decisions are handled before the interpretation job begins.

That means the system can stop the workflow without:

• generating an answer
• consuming a generation credit
• pretending that a disclaimer fixes the underlying product problem

Again, this logic belongs to the application rather than the model.

The principle I ended up using

The architecture can be summarized with one rule:

Use code to determine what is true in the product. Use the LLM to interpret what the product has already determined.

That boundary has made the system easier to test, easier to reason about, and much less dependent on prompt behavior.

It also changed how I think about building AI products generally.

The LLM does not need to be the application.

It can be one component inside a much more deterministic system.

Quick I Ching is where I've been applying this architecture in production, and I'm continuing to refine the boundary between structured application logic and generative interpretation.

I'd be interested to hear how other developers are drawing that boundary in production AI applications.