After Ticket Trust & Risk Engine

Explainable, deterministic shadow-mode risk signals for safer ticketing BNPL decisions—without changing existing checkout outcomes.

Comment

Inspiration

After Ticket did not begin as a Build Week prototype. It is an existing buy-now-pay-later infrastructure platform designed specifically for the ticketing industry, where checkout is time-sensitive and repayment risk must be handled carefully.

I am a self-taught, AI-native founder without a traditional software engineering background. Before Codex existed, I used GPT as a hands-on product and engineering partner while building After Ticket through Replit. This helped me translate a ticketing-finance concept into a working technology stack spanning APIs, web and mobile product experiences, payment and repayment logic, and operational infrastructure.

For me, OpenAI Build Week represented the next step in that journey: moving from conversational, manually directed AI development to repository-aware engineering with Codex and GPT-5.6.

What I built during Build Week

For clarity, the underlying After Ticket platform existed before Build Week. The Trust & Risk Engine submitted here is the new Build Week layer.

During Build Week, I added:

  • A deterministic shadow-mode decision contract.
  • A pure decision composer for explainable risk recommendations.
  • Two new risk signals: unresolved prior repayment and purchase velocity.
  • Service and route integration with the existing application.
  • A reviewer console with three synthetic scenarios.
  • A public, in-memory live-verification route.
  • Automated tests covering the engine, demo and existing agreement flow.
  • Build Week documentation and a focused merged pull request.

This bounded scope was deliberate. I wanted to add meaningful risk intelligence to a real financial workflow without creating untested customer impact.

What it does

The Trust & Risk Engine separates the customer's effective checkout outcome from a new internal shadow recommendation.

The existing eligibility logic remains authoritative. The new layer observes two explainable signals:

  • PREVIOUS_UNRESOLVED_DEFAULT when a customer has an unresolved prior repayment.
  • PURCHASE_VELOCITY_24H when the observed purchase count reaches a threshold of three within 24 hours.

These signals can recommend an internal review, but they never turn an existing approval into a decline. Every result includes structured reason codes, evaluated rules, observed values and thresholds.

The public reviewer console contains three frozen synthetic scenarios. Reviewers can also run live verification against a fresh in-memory server response generated by the same pure decision composer. No login, production database or customer data is required.

How I built it

GPT-5.6 powered my Codex engineering workflow. It is not used as a runtime risk model and does not make customer decisions.

I used Codex to inspect the existing repository and trace the checkout, eligibility and agreement paths before changing anything. Codex then helped me:

  • Develop a phased implementation plan.
  • Create the deterministic decision contract and pure composer.
  • Integrate the new layer into the existing service and route structure.
  • Build the reviewer-facing console and live-verification route.
  • Add isolated automated tests.
  • Verify that existing checkout and agreement behaviour remained unchanged.
  • Improve the responsive presentation of the public demo.
  • Prepare and document the focused pull request.

The founder-controlled decisions remained explicit: preserve the existing checkout outcome, use shadow mode only, add exactly two signals, set the velocity threshold to three, fail open if the new risk layer encounters an error, and expose no real customer data through the public demo.

Challenges

The main challenge was not simply creating another risk rule. It was introducing risk intelligence into an existing financial platform without accidentally changing checkout outcomes.

A second challenge was providing reviewers with something genuinely testable while protecting customer information and avoiding dependencies on production infrastructure.

I addressed both challenges by separating the effective decision from the shadow recommendation, using a stable deterministic contract and building a synthetic, database-free verification route.

Accomplishments that I am proud of

  • The new risk layer is integrated into a real existing platform rather than an isolated mock-up.
  • The same pure composer drives both server verification and reviewer-facing explanations.
  • All new signals remain non-blocking and explainable.
  • The public demo requires no account, customer data, database or external service.
  • The implementation is fail-open, so a risk-layer error cannot interrupt the existing checkout flow.
  • The merged Build Week pull request records 81 passing automated tests.
  • The new Build Week work is clearly separated from the pre-existing After Ticket platform.

What I learned

My earlier work with GPT showed me that a non-traditional founder can use AI to build far beyond a simple prototype. Build Week showed me how much stronger that process becomes when Codex can inspect a complete repository, follow dependencies, test changes and work within an explicit engineering plan.

I also learned that for a safety-sensitive product, the best first step is not always a more aggressive enforcement rule. A transparent shadow recommendation creates room to measure signal quality, review false positives and calibrate thresholds before customers are affected.

What's next

The next step is a controlled production shadow rollout with privacy-minimized internal review records, monitoring and threshold calibration.

Only after sufficient evidence and explicit review would After Ticket consider enabling enforcement. Additional signals can later be added without changing the stable decision contract.

Built With

Share this project:

Updates