Paradox

A software time machine for developers. Generate, test, and compare alternate implementations, choose what goes live, and restore your original code and saved state.

Comment

Inspiration

Paradox was inspired by Schrödinger's cat and the concept of superposition: multiple possible outcomes exist before one is selected.

We applied that idea to a practical development problem: How do you explore alternative implementations without sacrificing the application that already works?

AI coding agents can generate code quickly, but deciding whether to adopt it still requires inspecting changes, running tests, comparing behavior, and preserving a recovery path.

Git tracks source history, but it doesn't automatically preserve running application state, database contents, and validation evidence together.

We wanted developers to explore different software futures, understand their tradeoffs, and deliberately choose which implementation becomes reality.

In Paradox, observing a future doesn't activate it.

What it does

Paradox is a software time machine for developers.

It lets developers generate, inspect, compare, activate, and restore alternative implementations through persistent, branching timelines.

Our Studio has three interconnected workspaces:

  • Explore: Create and navigate branching software futures, inspect their status and ancestry, and interact with the actual running application.
  • Architect: Examine system components, relationships, and supporting API evidence, distinguishing observed information from documentation and inference.
  • Analyze: Compare actual code changes, test results, validation checks, and execution logs before making a decision.

Our real-world demonstration: NASA wildfire data

We built a working analytics application using 1,198 frozen NASA FIRMS VIIRS fire observations.

Starting from Original, Paradox creates two alternative model implementations:

  1. Model A: Linear regression.
  2. Model B: Engineered ridge regression.

Both alternatives use the same frozen dataset and chronological evaluation split.

Paradox records their actual model metrics, code differences, test results, and timeline ancestry while Original remains available.

We then demonstrate a controlled security regression:

  1. Create an implementation with an input-validation defect.
  2. Execute a regression test that genuinely fails.
  3. Preserve the failed generation's evidence without adopting that failed attempt.
  4. Create a hardened child of the defective implementation.
  5. Verify that invalid input is rejected while legitimate functionality continues working.
  6. Restore Original's code and saved SQLite notebook state without deleting the experimental futures.

Important: This workload estimates contemporaneous fire radiative power (FRP). It is not a wildfire-spread forecast or emergency-response system.

How we built it

Frontend: React, TypeScript, Vite, and React Flow

We built Paradox Studio with React, TypeScript, Vite, and React Flow.

The branching timeline displays actual persisted records and parent-child relationships. Developers can inspect and compare futures without silently changing the active application.

The preview connects to the running application rather than displaying a static screenshot or simulated interface.

Backend: Python, FastAPI, and SQLite

Our Python/FastAPI engine coordinates generation, validation, timeline persistence, activation, and restoration.

SQLite stores timeline and snapshot metadata. Snapshots preserve application code and database state together.

We use SQLite's online backup API to capture consistent database snapshots rather than relying on raw file copies.

Each future can therefore retain its own implementation and saved application state.

Validation: experiments must prove themselves

Generated candidates pass through compilation, tests, application boot, and HTTP checks before adoption.

A failed validation attempt does not become a successful timeline. Instead, Paradox retains its execution logs, failure stage, and evidence for inspection.

Here's a short excerpt from our actual validation pipeline:

# engine/generations.py — test-validation gate

evaluation["tests"] = test_counts(report)

require_test_success(
    result,
    evaluation["tests"],
    expected_tests
)

passed(
    "tests",
    started,
    f"{evaluation['tests']['passed']} passed"
)

Generating code is not the same as proving that code works.

Restoration: code and data together

Paradox snapshots both application code and SQLite state.

When restoring a previous timeline, the engine checks that the requested snapshot belongs to that timeline and restores the saved workspace through a staging directory.

The application returns to the selected saved state while the other timelines and their validation evidence remain available.

This is fundamentally different from restoring source files alone.

Factory Droid SDK integration

We integrated the Factory Droid SDK as a genuine code-generation provider.

Our adapter uses @factory/droid-sdk version 0.10.0, with restricted tool access and shell execution disabled in the configured Droid tool set.

In a separate historical SDK-backed run, Factory Droid changed a working feed application's ranking implementation and added eight regression tests.

The recovered execution evidence includes:

  • A genuine SDK session transcript and generated patch.
  • 26 passing tests, with no failures or errors.
  • Six successful validation checks.
  • JUnit test results, execution logs, checksums, and offline verification instructions.

Primary evidence: Inspect Factory Droid Run 3 — SDK session, patch, tests, and validation logs

Implementation: Factory Droid SDK adapter

The evidence was recovered from a sanitized export, not provider-signed proof. The publication documents its provenance limitations and redactions.

The recorded NASA demonstration uses our separate deterministic Scripted provider for reproducibility. We do not represent those NASA futures as Droid-generated implementations.

Built with Cursor

Cursor Composer was a major part of our implementation workflow, contributing to real Paradox Studio functionality and interface development.

Local Cursor development records associate thousands of Composer-authored edits with the project, including these verified commits:

We used Cursor to implement actual application functionality, not merely generate documentation or presentation materials.

Designed with Figma Make and Figma Slides

We used Figma Make to develop Paradox's redesign reference and carried its branding, interface concepts, and visual language into the functioning React Studio.

The final design connects three workspaces:

  • Explore: Visual branching timelines and future selection.
  • Architect: System-level inspection and supporting evidence.
  • Analyze: Side-by-side comparisons, code changes, validation results, and logs.

The redesign preserves actual generation, authentication, application preview, activation, and restoration behavior.

Figma Make prototype: Paradox Software Time Machine

Figma Slides presentation: Paradox — Design-to-Product Workflow

Our Slides presentation documents the design workflow, visual system, prototype-to-product transition, and implementation evidence. The Devpost gallery also includes the progression from Figma Make concept to working Studio, alongside the unified design across Explore, Architect, and Analyze.

Open source and reproducibility

Our NASA demonstration source is publicly available.

The NASA branch contains the frozen dataset, provenance information, model implementations, security regression tests, Scripted generation recipes, and supporting documentation.

It was published directly on top of the engine and Studio commit used for the recorded demonstration, preserving the submitted demo baseline.

Challenges we ran into

  • Separating inspection from activation: Viewing timelines, code differences, or evaluation evidence must not change what is live.
  • Restoring code and data together: Recovering source without the associated SQLite state would produce an incomplete restoration.
  • Handling failed generations honestly: A failed test must remain a failed attempt, not become a misleading successful future.
  • Preserving ancestry: The hardened implementation must descend from the actual defective implementation.
  • Making security failures measurable: Our intentionally unsafe version returned HTTP 200 for invalid input when HTTP 422 was expected.
  • Maintaining trustworthy evidence: Measured results, documented architecture, inferred behavior, and unavailable capabilities must be distinguishable.
  • Integrating design without sacrificing functionality: The Figma redesign needed to preserve genuine application operations instead of substituting mock interactions.

Accomplishments that we're proud of

We implemented and demonstrated the complete lifecycle of a software future:

Generation → Validation → Inspection → Comparison → Activation → Restoration

Verified NASA demonstration results

Stage Result
Model A 21 tests passed
Model B 21 tests passed
Unsafe implementation 22 tests passed
Security regression 23 passed, 1 failed
Hardened implementation 24 tests passed
Invalid input before fix HTTP 200
Invalid input after fix HTTP 422
Valid input after fix HTTP 200
Restoring Original Code and SQLite state restored
Persisted history Five successful timelines preserved

Both model alternatives passed all six validation checks.

The deliberately failing security regression did not create an adopted timeline. The hardened child passed the same previously failing regression and all six checks.

Measurable model improvements

Our model alternatives were evaluated against the same held-out NASA observations.

Model RMSE (MW) ↓ MAE (MW) ↓
Original 24.37 8.36
Model A — Linear 22.25 8.40
Model B — Ridge 21.73 7.99

Model B reduced RMSE by approximately 11% relative to Original.

Importantly, Model A improved RMSE while slightly worsening MAE. Paradox exposes that tradeoff instead of reducing every generated change to a success badge.

Additional accomplishments include:

  • A genuine Factory Droid SDK generation with 26 passing tests and six successful validation checks, supported by publicly inspectable recovered execution evidence.
  • A Figma-inspired interface integrated across Explore, Architect, and Analyze.
  • Real code and data restoration while preserving experimental histories.
  • A publicly available NASA demonstration branch with reproducibility instructions.

These are scoped demonstration results, not claims of universal repository compatibility, exhaustive security testing, or production-ready support for every application stack.

What we learned

Code generation is only the beginning.

Developers need to understand what changed, determine whether it improved behavior, evaluate tradeoffs, and know they can safely recover.

Our NASA model comparison demonstrated why objective evidence matters. One implementation improved RMSE but worsened MAE, while another improved both. Developers should be able to see those distinctions before choosing what goes live.

We also learned that failed experiments can be valuable outcomes. Our security regression intentionally failed, and Paradox correctly refused to adopt the failed attempt.

Finally, we learned that interface design needs to reflect actual software state. A branching graph is only meaningful when its nodes, relationships, validation outcomes, and actions correspond to real application behavior.

What's next for Paradox

We're continuing Paradox beyond Cal Hacks with four planned milestones:

  • M1 — Imported-project onboarding: Support selecting local repositories, compatibility checks, and explicit authorization.
  • M2 — Secure AI generation: Extend real Factory-backed generation to imported projects with execution isolation, validation, and recovery.
  • M3 — Future Workbench: Introduce deeper source inspection, side-by-side comparison, debugging, and controlled iteration.
  • M4 — GitHub integration: Add authenticated repository discovery, project import, and exporting changes through Git workflows and pull requests.

These are development priorities, not features we claim to have completed during the hackathon.

Our long-term vision is to make software alternatives easier to explore, safer to evaluate, and more deliberate to adopt across algorithms, APIs, data systems, and full-stack applications.

Paradox lets developers explore what their software could become without losing what already works.

Built With

Share this project:

Updates

Submission history