Concept

Why the answers are checkable

An auditable agentic architecture, which in practice means one thing: every tool returns the rule it applied and where that rule comes from. A model cannot compute a birth chart, so it guesses, and nobody can check a guess.

Astrology is the case study here, not the point. The point is a shape that works for any rule-based domain, anywhere the answers follow stated rules from citable sources: compute the thing exactly, then hand back the rule you applied and where that rule comes from, so a person who knows the domain can check your reasoning instead of trusting your output.

That matters more when the caller is an agent than when it is a person. A person reading a screen can notice that an answer feels wrong. An agent assembling a reply from 221 tools has no such instinct, and it will state whatever the tool returned with the same confidence either way. So the provenance has to travel in the payload.

Three properties, and one that is missing

1. Rule-level provenance

A tool does not only return a verdict. It returns the rule behind the verdict and the class of source that rule rests on.

All 78 event house groups carry a source class, and 51 are quoted from the page they come from.
Every invented number carries a label saying it is an ordering convention, not doctrine, and that it is not comparable with a number from another tool.
get_paradigm_panel tags every claim corpus, classical, disputed, later, derived, unsourced or unattributed, and returns unattributedClaimCount, which is how many claims in that reading rest on nothing anyone has verified.

That last one is the test of whether provenance is real. A system that reports its own gaps is one you can audit. A system that reports only its strengths is marketing.

2. Intermediate calculation traceability

Every figure is computed in this codebase, from the VSOP87 and ELP2000 series upward, with no third-party astrology library anywhere in the engine. That is not purity for its own sake. A pre-made result cannot be traced: you cannot say why a number is what it is, you cannot check it against a printed page, and when it disagrees with the source you cannot tell which side is wrong.

The same rule applies inside a response. When a significator fails a condition it is demoted and the planet that superseded it is named, rather than being dropped where nobody can see it went.

3. Controlled tool execution

The reading plan is data, not advice. set_birth_profile returns the tools to call for this question, the minimum number of calls before answering, and the waves they run in, computed from a dependency graph rather than described in prose. The Claude Code plugin enforces the floor with a hook. See expert reading patterns for what the waves look like in practice.

4. Deterministic replay, which is not built

Note

The engine is deterministic and its tests assert byte-identical output on repeated runs, which is the precondition for replay. But nothing yet records a reading and re-runs it against a later version of the engine. Until that exists, the claim is determinism, not replay, and this page says so rather than letting you assume otherwise.

What this buys a caller

You can cite instead of assert. Your product can show the user why, in the vocabulary a practitioner already uses.
You can tell systems apart. The system field on every tool says whose method produced a claim, so a Parashari result is never presented as a KP one. See KP / Vedic / Jaimini / Tajik.
You can see disagreement instead of averaging it away. Where two traditions answer differently, the panel returns both arguments and names how they differ. It never votes, because a tally would present incommensurable claims as commensurable ones.
You can find the weak spots. The unattributed count tells you which parts of a reading are least supported, before a user relies on them.

PreviousMCP protocol basics NextWhy Krishnamurti Paddhati