How to Verify a Tempora Forward Call Before Window Close

Why the audit path exists

A research-firm framework is only as credible as its audit path. The Tempora framework publishes forward calls under the discipline documented in Falsifiable astrology: every call carries a named entity, a dated window, an observable signal and an explicit falsifier condition, the call is published before the window opens and the outcome is reconciled on the same public surface after the window closes regardless of whether the call met.

The framework is designed for the reader who does not take its claims on trust. The whole point is that the reader can check. This article walks through the specific steps for doing that, from the tracker surface where active calls are listed to the reconciliation note at window close.

Step 1: Find the call on the tracker

Active and recent forward calls are listed on the public tracker page. The tracker shows each call's entity (which national chart or natal point), the dated window, the live status (active, closed, reconciled) and a link to the source article that documents the methodology behind the call.

The tracker is the index. A reader can scan the listed calls, see which windows are currently active and click through to the source article for any individual call. Closed windows with their reconciliation outcomes remain on the tracker indefinitely. The framework does not retire closed calls regardless of whether they met or missed; the public record is permanent.

If a call referenced in conversation, on social media or in an external article cannot be found on the tracker, that is a signal worth pausing on. The framework's discipline is to publish every forward call on the tracker before the window opens. A call existing in private discussion but not on the tracker is outside the framework's published surface and should not be treated as carrying the framework's audit guarantees.

Step 2: Read the window and the falsifier

Once the call is located, the two elements the reader must read first are the dated window and the falsifier condition.

The dated window. The call states the specific months during which the predicted event must occur. The window is typically narrow (a month, a few months, a season) rather than broad. A wide window dilutes the call by raising the prior probability of the event occurring within it by chance. A narrow window is the framework's commitment to a specific time-bounded prediction.

The falsifier condition. The falsifier states what would have to happen or not happen for the call to fail. For a call of the form "leadership transition in country X in window W", the falsifier is "absence of any leadership-transition event meeting the published criteria during window W". For a call of the form "financial-system crisis in market Y in window W", the falsifier is "absence of a crisis meeting the published threshold within the window". The falsifier is the reader's test condition for whether the call met.

Both the window and the falsifier are locked at publication. The framework cannot retroactively widen the window or relax the falsifier. If the source article has been edited after publication, the edit history is visible at the article's source and the original statement at publication time is the binding terms of the call.

Step 3: Read the source article

The source article is where the call's reasoning lives. It documents the calibrated signature driving the call (Saturn opposing natal Moon, Mars-Rahu conjunction, Rahu return, dasha-sandhi etc.), the lift figure for that signature on that chart and the mechanism the framework reads as connecting the astronomical configuration to the observable signal.

Three elements the reader should extract from the source article.

The driving signature. Which calibrated signature is firing in the window. The framework documents nine principal signatures in the calibration corpus and the source article names which one is active. The article also notes whether secondary signatures are simultaneously active, which strengthens the framework's confidence in the call.

The calibrated lift figure. The lift is the ratio of how often the signature scores above its activation threshold on confirmed historical event dates compared with how often it scores above the same threshold on a Monte Carlo random-date baseline. Lift figures range from 1.12x (weak) to 5.46x (strong) across the calibrated corpus. The framework only publishes forward calls where at least one strong signature (lift greater than or equal to 1.5x) is active in the window. The methodology behind the lift figures is documented at Calibrated lift astrology.

The mechanism. The article explains how the astronomical configuration is read as connecting to the observable signal. This is the interpretive layer on top of the calibrated computation. The reader can evaluate whether the mechanism is plausible, whether the framework's reasoning is internally consistent and whether the call carries the rigour the framework claims.

Step 4: Cross-check the calibration weights

The calibrated lift figures published in the source article are derived from the framework's calibration corpus. The underlying weights are stored at data/results/calibrated_weights.json in the public repository and the calibration engine regenerates them from the historical event corpus.

A reader who wants to verify the published lift figure can open the weights file and check the entry for the relevant chart and signature. The file is structured as a JSON map from (chart, signature) pairs to numerical lift values. The article's published lift figure should appear in the weights file for the chart and signature the article names.

The methodology behind the weights is documented at Calibrated lift astrology. The Monte Carlo baseline runs 300 randomised draws per signature class and the lift is the ratio of historical-event scores to baseline scores. The calibration engine code is in the repository and can be re-run independently by any reader with the computational tools.

A material discrepancy between a published article and the weights file is something to flag. The framework's intention is for the two to be consistent. The article was timestamped at publication and is the binding statement for the forward call; the weights file is the engine's working state. If the two diverge, the right channel to surface the discrepancy is via the tracker discussion or the contact surface on the site.

Step 5: Monitor the test condition during the live window

Once the call is on the tracker, the source article is read and the calibration is cross-checked, the reader can move into live monitoring during the window itself.

The test condition is the observable signal stated in the source article. For a geopolitical call, the observable might be a leadership transition (resignation, ouster, sudden replacement), a military escalation event (cross-border incident, declaration of conflict, significant deployment) or a constitutional event (referendum, emergency declaration). For a markets call, the observable might be a top, a bottom, a defined drawdown threshold or a volatility regime shift. The article specifies which.

The reader monitors public news sources, market data or other observable evidence during the window. The test condition is locked in advance and cannot be retroactively widened or narrowed. The reader's job is to ask, as the window runs, whether an event meeting the published threshold has occurred.

Three reading rules during live monitoring.

The threshold is the published one. If the article says "a leadership transition meeting the criterion of a head-of-state change", the reader holds the framework to that specific criterion. A minor cabinet reshuffle does not meet the criterion. The framework's discipline is that the criterion does not move.

The window is the published one. If the window is January to March 2027 and the relevant event occurs in May 2027, the call has missed regardless of whether the configuration that drove the call was still loosely in effect. The framework commits to dated windows and dated windows close.

Partial hits are partial hits. Some calls meet the spirit of the call but not the precise letter. A market drawdown that approaches but does not reach the published threshold. A leadership transition that occurs but in an adjacent jurisdiction. The framework documents these as partial hits in the reconciliation note and the reader can evaluate the partial reading on its own terms.

Step 6: Wait for the reconciliation note

After the window closes, the framework publishes a reconciliation note within a defined lag (typically 30 days). The note appears on the tracker and is linked from the source article. The note states whether the call met, partially met or missed, with a documented walk-through of the outcome against the published terms.

The reconciliation note is the framework's commitment to owning the outcome. Misses are documented as misses on the same public surface as hits. The reconciliation log lives at the tracker indefinitely as part of the framework's public record. The discipline is the same regardless of outcome: hit or miss, the note publishes within the lag.

The reader's verification path closes here. The call was published before the window opened. The window ran. The reconciliation note documents the outcome against the published terms. The reader can audit the entire chain from tracker to reconciliation and form an independent view of whether the framework met its own published standard for the call.

What the aggregate audit looks like

Beyond any single call, the tracker shows the framework's aggregate running record. Each closed window appears with its reconciliation outcome marked. A reader can count hits, partial hits and misses directly from the tracker. The aggregate hit rate is computed from the same public data the reader can audit.

The aggregate is the deeper test. A single call can hit or miss for reasons unrelated to the framework's underlying calibration (the baseline probability of any individual call is non-trivial). The aggregate over many closed calls is where the framework's claimed predictive lift is or is not demonstrated. The framework's posture is that the aggregate test is the binding one and that it should be allowed to run for many closed windows before the framework's net record is evaluated.

The reader who wants to evaluate the framework rigorously will track the aggregate over time and form a view based on the public record rather than on any individual hit or miss. The tracker is the right surface for that long-running evaluation.

What this audit path does not cover

Two limits worth stating explicitly.

Individual chart work. The audit path described here covers Tempora's forward calls on national charts and other public natal points. Individual chart work delivered through Kaal Imprint at /kaal operates under the same methodology and the same calibrated framework but is not published on the tracker as a forward call. The Imprint output is reproducible against the Tempora framework (the same birth data produces the same dated moments under the same calibration) but is not part of the public forward-call audit path.

Private practitioner readings. The framework does not deliver private chart readings over WhatsApp or other private channels (see Why Tempora won't read your chart over WhatsApp). Any chart reading delivered outside the public forward-call surface or the Kaal Imprint product is outside the framework's audit guarantees. A reading attributed to Tempora that does not appear on the tracker or run through the documented product surface is not under the framework's published discipline.

The reader's posture

The right reader posture for the framework is informed scepticism with a willingness to check. The framework publishes the audit path precisely so that scepticism can be operationalised. The reader who wants to evaluate the framework should: find the calls on the tracker, read the source articles for the mechanism and the calibrated lift, cross-check the weights file where the lift figures sit, monitor the test conditions during live windows and form a view from the public record of reconciled outcomes.

The framework is not asking for trust. The framework is asking for the reader to do the audit and form a view from the audit. The credibility of the work rests on the audit being possible and on the reconciliation being honest. The framework's posture is that both conditions are met and the audit is open to any reader who wants to do the work.

Frequently asked questions