Reliability Isn't a Prompt. It's an Architecture Decision.

Every team shipping LLM features eventually runs into the same problem. Large language models can sound confident even when they're wrong.

In most products that's embarrassing. In mine it can genuinely hurt someone.

I build VyomaVeda, an AI-assisted Vedic astrology platform. Someone opens it at a low moment and reads "Saturn sits in your 7th house, so your marriage will be delayed." If the model invented that placement, I've handed a vulnerable person an unsupported statement about their life. "Sorry, the AI made that up" is not an acceptable answer.

For a long time I did what most teams do. I wrote better prompts. Only use the provided data. Do not invent placements. Be accurate. It worked most of the time, which is another way of saying it failed unpredictably. A prompt is a request. Under load, the model doesn't always honor it.

The decision that actually moved the needle was shifting reliability from prompt engineering into system architecture.

The system now looks like this:

        Chart
          ↓
   Deterministic Engine
          ↓
     Fact Payload   ← the model only ever sees this
          ↓
         LLM
          ↓
 Deterministic Validator   ← code, not another model
          ↓
        User

The model sits in the middle with a constraint on each side. One narrows what it can see. The other checks what it produced. Here's what each does, and, just as important, what it doesn't.

Narrow the evidence surface

This is the counterintuitive one. My engine computes a full birth chart deterministically: planetary positions, divisional charts, planetary periods. A large structured object. The obvious design is to hand all of it to the model and let it write.

I do the opposite. The full chart never reaches the model.

Between the engine and the model sits a step whose only job is fact extraction, with no interpretation. It reduces the computed chart to a compact fact block plus a list of the specific values the model is permitted to reference. Illustratively:

# simplified for illustration
payload = {
    "facts": "...the small set of chart facts relevant to this question...",
    "allowed": {"planets": [...], "houses": [...], "signs": [...]},
}

The model receives the fact block and the user's question, not the chart. Any factual reference it makes should trace to that constrained payload rather than to a full chart it never sees. That sharply limits what it can fabricate, without pretending to eliminate it. And it narrows the model's operating context to a small, deliberately chosen evidence surface, shrinking the blast radius of any single error from the whole chart down to that block.

Keep the prompt, but treat it as a floor

Inside that block the prompt still instructs the model to answer only from the supplied facts. I still write those rules, and they help. But I no longer rely on them as the guarantee. Everyone already knows prompts alone aren't enough. So the prompt is the floor. The enforcement is separate.

Validate the structural references in code

After the model writes its answer, deterministic code, not another model, checks the factual references in that answer against the list of values the payload actually permitted. Any chart reference that doesn't trace back to a supplied fact is removed before the response reaches the user.

Be precise about what this does and doesn't do. It validates structural claims: the planets, houses, signs, and dates a sentence names. Those are a closed, enumerable set, so they can be checked mechanically. It does not verify that the interpretation is correct, wise, or well-judged. The validator confirms a sentence only refers to facts the system computed. It says nothing about whether the meaning drawn from those facts is good.

That boundary is the whole design:

Deterministic computation produces the facts.

The LLM narrates those facts.

Validation checks structural references.

Evaluation measures interpretation quality.

The result isn't a model that stopped hallucinating. It's a pipeline that prevents many unsupported factual claims from reaching the user, and constrains an important class of hallucinations: fabricated placements. Confident fabrication still happens inside the model. It's just far less likely to survive to the response.

The pattern generalizes past astrology

Any system where an LLM narrates over real data can apply the same shape:

1. Constrain the input. Give the model the smallest slice of ground truth the task needs, extracted by deterministic code. Don't hand it the raw store and hope it stays in bounds.
2. Constrain the instruction. Write the guardrail prompt. Treat it as a floor, not a guarantee.
3. Validate the output. Check the structural references against the same ground truth, in code. Strip what can't be traced to a provided input.

The honest part

This narrows a specific, checkable failure mode. It is not a general reliability guarantee, and it isn't free.

• You build twice. Once to compute the truth, once to check the narration against it. The validation layer is real software with its own tests and its own failure modes.
• It's deliberately conservative. Occasionally the model writes something legitimate that falls outside the permitted set, and the gate removes a sentence that was actually fine. I accept that tradeoff on purpose: a missing sentence is recoverable, an unsupported verdict is costlier. Other domains may tune it differently.
• It only covers what you can enumerate. Structural references are checkable. Tone, empathy, and whether an interpretation is sound are not caught by this mechanism and still require evaluation.
• Enforcement earns its place in code. I moved specific rules out of the prompt and into deterministic checks after observing the model skip them as prompt text. If a rule matters, measure whether the model follows it. If it doesn't, that rule belongs in code.

None of this makes the model smarter.

It reduces the likelihood that the model's mistakes reach a user in a form that looks authoritative.

Prompt engineering is still useful. But reliable AI systems increasingly lean on architectural constraints, deterministic components, and explicit validation rather than on model behavior alone.

Prompts are instructions. Architecture is enforcement. The systems I trust most don't depend on the model behaving well. They constrain what it can see and check what it produced, so the errors that matter most are far less likely to reach the people who rely on them.