Sacred Forecast — TiboReset

The hero separates the resolved reset, active reset policy, Reset Watch Score, and calibrated next-36-hour probability.
Max-channel diagnostics show timing, policy, live-signal readiness, and negative penalties without double counting.
The Data Lab separates the resolved event, active Watch model, policy state, calibrated forecast, and audit record.
The calibrated trend preserves the resolved 98% reset event while separating the active forecast for the next cycle.
Forecast-moving and Screened out tabs keep active evidence visible while preserving irrelevant and expired posts for audit.

Inspiration

For the past two weeks, I have been building with Codex from Thailand, often until four or five in the morning.

I repeatedly faced the same practical decision: should I spend my remaining Codex capacity on another large agent run, protect it for critical work, or queue the task because another reset might be approaching?

Public clues existed, but they were scattered across short posts, milestone announcements, operational replies, policy statements, and previous reset events.

I did not want to build another token counter. I wanted an explainable system that could answer three different questions without collapsing them into one misleading percentage:

Does official evidence still support continuing resets?
How elevated is the current situation operationally?
What is the modeled probability of an official reset announcement within the next 36 hours?

That became Sacred Forecast, also called TiboReset.

What it does

Sacred Forecast is a two-model, three-view forecasting system for Codex reset planning.

It deliberately separates:

Reset Policy
Reset Watch Score
Calibrated next-36-hour probability

These outputs answer different questions and are never presented as interchangeable.

Reset Policy

Reset Policy reports whether current official evidence supports the continuation of future resets.

For example, an official statement such as:

“The resets will continue.”

can activate the policy state because it supports the existence of an ongoing reset policy.

However, it does not specify when the next reset will happen.

The product therefore exposes:

policy state
source post
evidence confidence
activation time
evidence age
decay
expiration
withdrawal or contradiction status

High policy confidence does not automatically mean high near-term probability.

Reset Watch Score

The Reset Watch Score is the primary operational-readiness score.

It is displayed from 0 / 100 to 95 / 100, but it is explicitly labeled:

An operational readiness score, not a probability.

The score combines three separate channels:

Timing channel
Reset Oracle v2’s calibrated next-36-hour probability.
Policy-timing channel
Official continuing-reset policy confidence, moderated by cycle maturity and evidence age.
Strongest live-signal channel
The strongest currently active structured signal, such as operational work underway, a reset hint, or a milestone commitment.

The score uses the strongest eligible channel rather than summing correlated evidence.

Conceptually:

Watch Score = max(timing, policy timing, strongest live signal)

Negative evidence is then applied once.

This avoids double counting multiple posts that describe the same situation.

A credible explicit near-term commitment may produce a Watch Score of 95. A completed reset does not remain as an active 98-point score; it resolves the previous cycle and starts a new one.

Calibrated next-36-hour probability

Reset Oracle v2 separately estimates the probability of an official reset announcement inside the next rolling 36 hours.

It provides:

calibrated probability
credible interval
policy-driven and discretionary branches
model version
data cutoff
evidence provenance
configuration hash
deterministic seed
5,000 reproducible simulations
strict walk-forward historical evaluation

The calibrated probability can remain low even when the Reset Watch Score is high.

For example, official evidence may strongly support continuing resets, and the current cycle may be historically mature, while the model still has little evidence that the next announcement will occur specifically within 36 hours.

That difference is intentional.

Live event detection

During the final production development period, Sacred Forecast detected a real official completed-reset announcement published on July 18, 2026 at 03:28 UTC.

The system:

resolved the previous forecast
preserved the official source and timestamp
recorded the reset type
excluded the completed confirmation from the next active forecast
removed transient pre-reset signals from the new cycle
started estimating another future reset

This exposed an important modeling problem.

A confirmed event cannot remain inside the current forecast as if it were still a future possibility.

The product now separates:

Resolved event
Active next-reset forecast

The previous resolved forecast remains visible in history and the Data Lab, but it contributes zero active-cycle points.

How I built it

The application uses:

Next.js App Router
React
strict TypeScript
Supabase Postgres
the official X API
the OpenAI Responses API
GPT-5.6
Zod
Recharts
GSAP
Tailwind CSS
Vitest
Playwright
Vercel

The ingestion pipeline is:

Read a bounded set of unseen posts from the configured official X account.
Use cursoring and deduplication to avoid repeatedly requesting the same posts.
Screen obviously irrelevant posts locally.
Send only candidate posts to GPT-5.6.
Extract structured evidence using a strict Zod-backed schema.
Apply deterministic ambiguity and review-safety rules.
Store the original source, extraction, confidence, uncertainty, review state, and provenance.
Recalculate one canonical forecast snapshot.
Serve the same snapshot to the homepage, charts, API, Latest Signals, inspector, and Data Lab.

The system does not fetch parent threads, additional profiles, or media to make the model appear more informed than it is.

It operates only on the bounded public information available through the configured pipeline.

The role of GPT-5.6

GPT-5.6 does not generate either final metric.

It converts candidate public posts into structured evidence such as:

signal type
reset type
reset intent
operator-intervention strength
operational relevance
timing immediacy
source authority
confidence
uncertainty
review requirement
confirmation state

Examples of distinctions the extractor must make:

“The resets will continue.”
→ reset-policy continuation
“Let me see what I can do.”
→ possible operator intervention, not a reset promise
“Working on the next reset now.”
→ operational work underway
“I will reset limits later today.”
→ near-term reset commitment
“Usage limits have been reset.”
→ completed reset confirmation
“Will the resets continue?”
→ question or review-gated evidence
“No more resets.”
→ negative or policy-withdrawal evidence

GPT-5.6 returns structured evidence only.

Deterministic TypeScript calculates:

Reset Watch Score
Reset Oracle v2 probability
signal readiness
policy timing
recency decay
negative penalties
state transitions

Reset Watch Score design

The original operational model used additive points and later experimented with a fixed policy floor.

That design could make the displayed number look high even when timing evidence was weak.

I replaced it with max-channel evidence fusion.

Timing channel

The timing channel is the existing Reset Oracle v2 calibrated probability.

timing = calibrated probability

Policy-timing channel

The policy channel separates confidence from timing:

policy timing = policy confidence × cycle maturity × policy decay

A strong official statement that resets will continue may produce high policy confidence.

But immediately after a completed reset, cycle maturity is near zero, so the policy statement alone does not force a high readiness score.

As the cycle matures, the policy-timing channel rises monotonically.

Strongest live-signal channel

Each active structured signal is converted into a normalized readiness value using:

operational relevance
reset intent
timing immediacy
source authority
extraction confidence
recency
review state

Only the strongest eligible signal is used.

Repeated or semantically similar posts do not stack without limit.

Final score

The final calculation is conceptually:

raw watch = max(timing, policy timing, strongest signal)

adjusted watch = raw watch × (1 − negative penalty)

Watch Score = adjusted watch × 100

The Watch Score is separately versioned and is not included in the calibrated Brier-score comparison.

Reset Oracle v2

Reset Oracle v2 estimates two possible causes of an official reset announcement.

Policy-driven branch

The policy branch calculates:

P(next pledged milestone inside 36 hours) × P(reset announcement | milestone)

Milestone-arrival pressure is estimated from verified inter-milestone history using a cutoff-safe, recency-aware renewal model.

The reset-given-milestone probability uses a Beta-Binomial posterior updated only from pledged milestones known before the evaluation cutoff.

Discretionary branch

The discretionary branch evaluates structured live evidence through six-hour logistic hazards.

Evidence may include:

direct reset wording
operational intervention
capacity concern
usage incident
milestone commitment
reset hints
delaying evidence
negative policy evidence

Combined probability

The branches are combined as:

P(total reset) = 1 − (1 − policy risk) × (1 − discretionary risk)

The model samples coefficient uncertainty through 5,000 seeded simulations.

Each forecast preserves:

model version
cutoff
probability
credible interval
seed
simulation count
evidence IDs
configuration hash
feature origins

The coefficients are versioned expert priors, not parameters trained on a large historical dataset.

Signal experience

Latest Signals is divided into two accessible tabs.

Forecast-moving

This contains evidence that currently affects policy state, operational readiness, or the calibrated forecast.

Examples include:

active reset-policy continuation
operational work underway
milestone commitments
reset hints
negative evidence
the latest resolved reset event

Each card can expose:

original post text
signal type
confidence
timing immediacy
evidence age
policy status
Watch Score counterfactual
calibrated counterfactual
exclusion or resolution state
original source link

Screened out

This preserves evidence that should not affect the active forecast, including:

irrelevant posts
questions
ambiguous statements
review-blocked evidence
expired transient signals
previous-cycle posts
duplicate or superseded signals

A post appears in only one tab.

Screened evidence remains auditable instead of being deleted.

Historical Memory

The technical archive includes the nearest historical situations.

Values such as:

48 / 100

are cosine-similarity matches between the current feature pattern and verified historical signal windows.

They are explicitly labeled:

Similarity Match — Not a probability

These values are not:

reset probabilities
success rates
calibrated forecasts
historical accuracy
inputs that directly determine the final score

Historical windows without a verified forward outcome are labeled:

Forward outcome not scored

They are excluded from performance evaluation.

No retrospective probability or outcome is invented when cutoff-safe information is unavailable.

Challenges I ran into

Separating extraction from prediction

Allowing a language model to invent the final percentage would make the product difficult to reproduce, audit, or test.

GPT-5.6 therefore stops at structured evidence. Deterministic code owns every public number.

Distinguishing policy from timing

“The resets will continue” is meaningful evidence, but it does not say when the next reset will occur.

The product needed to represent strong policy confidence without falsely presenting it as a 36-hour probability.

Avoiding double counting

Several public posts may describe the same operational event.

An additive score could incorrectly treat repeated evidence as independent.

Max-channel fusion uses the strongest eligible readiness channel instead of summing correlated posts.

Understanding short contextual posts

A short reply such as “Let me see what I can do” may represent operator intervention, but it is not a reset confirmation or near-term commitment.

The system treats these signals conservatively.

Handling plural and varied reset language

The original deterministic relevance screen recognized “reset” but missed some forms such as “resets.”

That meant a clear statement that resets would continue could be incorrectly screened out before GPT-5.6 saw it.

I expanded the deterministic language handling and added regression tests for plural forms, negation, questions, commitments, and confirmations.

Closing one forecast cycle and beginning another

A completed reset was initially treated as a large active signal.

That was conceptually wrong because the event had already happened.

The final state machine resolves the previous forecast, records the event, excludes completed and pre-cycle evidence, and begins estimating another future reset.

Preventing stale or contradictory views

At one point, the inspector, hero, API, and charts could read different snapshots.

I created one canonical snapshot so every public surface shares the same:

cutoff
evidence
resolved event
cycle state
Watch Score
calibrated probability
exclusions

Preventing historical leakage

For every backtest cutoff, the system reconstructs only the evidence, milestones, and outcomes available at that exact time.

The target announcement post is excluded from strict pre-announcement scoring.

Making the interface mathematically honest

The Hero originally placed the score and /100 denominator inside one tightly tracked element, causing visual overlap for some scores and viewport sizes.

I separated them into non-shrinking sibling elements, removed unsafe metric-cluster scaling, and added explicit bounding-box overlap tests across multiple scores, viewports, and zoom levels.

Accomplishments I am proud of

A production system that detected and resolved a real official reset event.
Clear separation between policy status, operational readiness, and calibrated probability.
A non-additive Watch Score that avoids correlated evidence double counting.
Incremental official-X ingestion with bounded reads, cursoring, and deduplication.
GPT-5.6 structured extraction with deterministic ambiguity and safety gates.
A versioned and reproducible probability model with public diagnostics.
A canonical snapshot shared by the homepage, API, charts, inspector, Latest Signals, and Data Lab.
Accessible Forecast-moving and Screened out evidence tabs.
A public read-only Data Lab exposing model channels, evidence, exclusions, cycle state, uncertainty, and audit records.
A deterministic offline Demo Mode requiring no external credentials.
Responsive production behavior across mobile and desktop.
Explicit visual-overlap tests for Watch Scores from 0 through 100.
Honest labeling of historical similarity and unscored outcomes.
150 automated tests passing in the final production version.

Historical evaluation

The strict pre-announcement evaluation covers June 17 to July 17, 2026.

Measure	Result
Forecasts generated	120
Scored windows	115
Verified announcements	4
Reset Oracle v1 Brier score	0.1522
Reset Oracle v2 Brier score	0.1127
Constant baseline Brier score	0.1320
V2 skill versus constant	+14.63%
Events crossing 30% before publication	2 of 4
Events crossing 50% before publication	1 of 4
Highest observed false-alarm probability	5.1%

Observed lead time included:

19.6 hours above 30% before the 8M announcement
52.2 hours above 30% before the 9M announcement
28.2 hours above 50% before the 9M announcement

The correct interpretation is:

Promising but unvalidated.

Four verified announcements are not enough to establish general reliability.

The Reset Watch Score is an operational readiness score. It has not been calibrated and is not included in the Brier-score comparison.

Historical analog similarity values are also excluded from calibration claims.

How I used Codex

I used Codex across the complete engineering loop:

repository architecture
strict TypeScript implementation
Supabase schema and queries
ingestion pipelines
OpenAI structured extraction
deterministic scoring logic
state-machine design
unit tests
Playwright browser tests
responsive hardening
production debugging
historical backtesting
Reset Oracle v2
Watch Score max-channel redesign
canonical snapshot synchronization
documentation
production deployment
live verification

Codex was especially valuable for repeatedly inspecting the real repository, applying bounded changes, running verification, finding contradictions between model intent and production behavior, and checking the exact deployed commit rather than assuming that an HTTP 200 response meant the latest build was live.

What I learned

Explainability cannot be added after the model is complete.

Every public number needs:

a precise meaning
a defined cutoff
inspectable components
retained evidence
a versioned calculation
a clear statement of what it is not

I also learned that policy confidence, operational readiness, and near-term probability are different concepts.

Compressing them into one number may look simpler, but it hides the most important information.

An observed event must also close a forecast. Continuing to display a confirmation as a prediction of the future creates a technically plausible but conceptually incorrect product.

Finally, presentation correctness matters. A trustworthy model can still lose credibility if its typography overlaps or if a similarity score looks like a probability.

What's next

Collect more prospective data without rewriting the frozen historical evaluation.
Evaluate the Reset Watch Score separately from Reset Oracle calibration.
Add more reviewed negative, delaying, and policy-withdrawal signals.
Expand the verified reset and milestone ledger.
Add more official public-source adapters behind the same bounded interface.
Improve calibration only after substantially more verified events exist.
Continue comparing model predictions with future outcomes rather than retroactively tuning historical results.
Explore user-configurable planning guidance without allowing visitor activity to affect either metric.

Sacred Forecast is an unofficial experimental planning tool.

It is not affiliated with or endorsed by OpenAI or X. Its outputs are not official announcements, guarantees, or promises of account-level availability.

Built With

api
codex
css
gpt-5.6
gsap
next.js
openai
playwrite
postgresql
react
recharts
supabase
tailwind
typescript
vercel
vitest
x
zod