Before Evidence

Before Evidence locks what you said would change your mind before revealing the result, then uses GPT-5.6 to detect when you move the goalposts afterward.

Comment

Inspiration

People often decide what evidence means only after they see whether they like the result.

That creates a familiar pattern: the threshold changes, a new exclusion appears, or confidence moves in a direction that was never justified beforehand.

Before Evidence was built around one simple rule:

You cannot rewrite your standard after seeing the result.

Unlike a decision journal, which records what someone thought, Before Evidence records what they promised would change their mind.

What it does

Before Evidence guides a user through a fixed evidence-evaluation flow:

  1. Write a claim.
  2. Record initial confidence.
  3. Name rival explanations.
  4. Define a prediction.
  5. Define an explicit refutation condition.
  6. Describe the experiment.
  7. Review and seal the commitment.
  8. Reveal predetermined evidence.
  9. Interpret the result and update confidence.
  10. Receive a structured GPT-5.6 audit.

The audit does not decide what the user should believe.

It compares the sealed prior standard, the evidence, and the user’s later interpretation to determine whether the user honored the rule they defined before seeing the result.

How GPT-5.6 is used

GPT-5.6 has two separate roles.

Before the lock

It checks whether the user-authored commitment is understandable, operational, internally coherent, and suitable for later auditing.

At this stage, GPT-5.6 does not see the evidence, rewrite the user’s belief, choose the threshold, or generate the prediction.

After the evidence

GPT-5.6 compares:

  • the sealed commitment;
  • the predetermined evidence;
  • the user’s interpretation;
  • the confidence update;
  • the proposed next experiment.

It returns a structured result including:

  • normalized verdict;
  • evidence relation;
  • discrepancy map;
  • post-hoc threshold or exclusion flags;
  • confidence calibration;
  • surviving rival explanations;
  • next-experiment assessment.

In the demo scenario, the user registers a 10% activation threshold and 55% confidence. The evidence later shows an 18% lift, but the user lowers confidence to 35% using a new concern that was never registered. GPT-5.6 identifies the update as INCONSISTENT.

How Codex was used

Codex helped turn the product mechanism into a complete production system.

It was used to implement and harden:

  • the Next.js application;
  • server-enforced immutable locking;
  • evidence isolation before lock;
  • Postgres persistence;
  • deterministic input validation;
  • structured GPT-5.6 schemas;
  • provider failure and retry states;
  • canonical SHA-256 record fingerprints;
  • JSON and Markdown exports;
  • deterministic record verification;
  • responsive UX;
  • accessibility improvements;
  • adversarial tests;
  • GitHub Actions;
  • Vercel deployment.

The majority of the core implementation was completed in Codex session:

019f809f-fc71-7730-bd09-1ba64242d9f6

How it works technically

The core flow is:

CASE → COMMITMENT → VALIDATION → REVIEW → LOCK → EVIDENCE → INTERPRETATION → CONFIDENCE UPDATE → GPT-5.6 AUDIT

Important integrity rules are enforced on the server:

  • the commitment becomes immutable after sealing;
  • predetermined evidence is unavailable before the lock;
  • the client cannot replace the stored commitment or evidence;
  • the audit uses the server-owned record;
  • exports can be checked against a canonical SHA-256 fingerprint.

The application uses Next.js, TypeScript, PostgreSQL, OpenRouter, Zod, GitHub Actions, and Vercel.

Challenges

The hardest part was not generating an AI response. It was defining clear boundaries around what the model was allowed to do.

GPT-5.6 needed to be useful without becoming an authority that rewrites the user’s beliefs.

Other challenges included:

  • preventing evidence leakage before lock;
  • enforcing immutability on the server rather than only in the interface;
  • distinguishing semantic inconsistency from simple disagreement;
  • handling provider failures without corrupting the record;
  • making a dense structured audit readable on desktop and mobile;
  • producing a verifiable record without overstating what a fingerprint proves.

Accomplishments

The final product includes:

  • a complete end-to-end working flow;
  • server-enforced commitment locking;
  • predetermined evidence isolation;
  • two meaningful GPT-5.6 roles;
  • structured discrepancy and calibration analysis;
  • persisted sessions and local history;
  • record export and verification;
  • provider model metadata;
  • responsive desktop and mobile interfaces;
  • 56 passing automated tests;
  • passing CI;
  • a public production deployment.

What I learned

The strongest use of AI was not asking the model to generate an answer.

It was giving the model a narrow responsibility inside a system with strong constraints.

Before Evidence works because GPT-5.6 is combined with server-owned state, predetermined evidence, explicit user commitments, structured schemas, and testable invariants.

Potential impact

Before Evidence is designed for people who interpret experiments and important decisions without wanting to quietly move the goalposts afterward.

Possible use cases include:

  • product experiments;
  • research and analysis;
  • investment decisions;
  • hiring evaluations;
  • policy decisions;
  • personal decisions with explicit evidence thresholds.

The product does not claim to eliminate bias or determine truth.

Its purpose is narrower and more practical:

make post-hoc changes to the standard visible.

What’s next

The current submission intentionally uses one fixed scenario to prove the mechanism clearly.

Future work could explore carefully designed domain-specific cases while preserving the same core law: define the standard first, lock it, reveal fixed evidence, and audit the update.

Built With

Share this project:

Updates