KELLY / Causalea

A governed AI decision engine that turns live evidence into forecasts, proofs, and memory.

Comment

Inspiration## Inspiration

KELLY / Causalea began with one idea: the "25-Second Decision Card".

I wanted a simple way for myself and my wife to make decisions under uncertainty without freezing, spiraling, or pretending I knew more than I did at the time:

The Original Card

When a decision is required and clarity is absent:

  1. State the decision in one sentence.
  2. Name the next 24 hours of action it implies.
  3. Identify the one consequence you would not accept.
  4. If steps 1-3 hold, act. If not, defer for no more than 24 hours and repeat.

Goal: Preserve behavior under stress.

I originally tried to turn that card into a user-friendly app. I had no previous experience coding so I turned to AI Coding Agents.

The project then expanded through a logical chain: decisions require uncertainty estimates - uncertainty requires evidence - evidence requires trustworthy sources - forecasts require settlement against reality - settlement requires replay and calibration - learning requires memory - and memory requires proof and lineage.

That chain became KELLY / Causalea.

What it does

KELLY / Causalea is a governed decision-intelligence system for questions where the answer is uncertain and the evidence may change.

KELLY is the internal engine. Causalea is the public lens into it. The Glass Lab is the transparency console.

The system connects:

  1. Evidence and source intake
  2. Question and hypothesis generation
  3. Forecasting and causal analysis
  4. Scenario and Monte Carlo reasoning
  5. Settlement against later observations
  6. Calibration and replay
  7. Governed memory-cell admission
  8. Proof, lineage, and audit visibility

Users can ask questions, inspect forecasts, explore specialized labs, and follow returned evidence into Glass Lab. Public users can query and audit KELLY, but they cannot directly write its memory, alter GraphState, or redefine ground truth.

The project includes specialized interfaces for forecasting, markets, weather and disasters, policy and economics, betting and odds, science and research, hypothesis generation, memory and lineage, and system transparency.

How I built it

I built this project solo, beginning with no previous coding experience beyond the work I have done during the past month.

I did not manually write the source code. Instead, I used Codex and other AI coding agents as an engineering workforce while I supplied the product concept, architecture, operating law, acceptance criteria, and final decisions.

Codex became the primary structure and coordination layer. I used it to:

  • inspect the repository and live deployments;
  • convert product decisions into executable build plans;
  • define strict file ownership and authority boundaries;
  • generate implementation and test patches;
  • diagnose failures systematically;
  • review changes from other coding agents;
  • create regression smokes and release checks; and
  • keep parallel work aligned with one canonical GitHub repository.

Structured instructions (prompts) produced with Codex also allowed another AI coding agent, Grok, to work on isolated parts of the system without overriding KELLY’s authority model. I rejected placeholder logic and required executable contracts, tests, failure states, and acceptance evidence.

During the Build Week submission period, Codex and GPT-5.6 were used to meaningfully extend and harden the existing project. The session work shared begins on the 12th and still continues now.

This work included the governed decision-card surfaces, canonical probability and scoring rules, Ask KELLY’s grounded routing and streaming protocol, settlement and memory-admission correctness, Neon transaction hardening, deployment parity checks, regression tests, and the judge-facing live demo.

The stack includes Next.js, React, TypeScript, Node.js, Python, PostgreSQL and Neon, Railway, Vercel, Cloudflare R2, Modal, Sentry, Firecrawl, Docker, GitHub Actions, the OpenAI API, Codex, and GPT-5.6.

Challenges I ran into

The hardest problem was not creating one feature. It was keeping a large, distributed system honest.

Major challenges included:

  • preventing public interfaces from mutating KELLY’s memory or ground truth;
  • separating simulations and candidate evidence from settled real-world evidence;
  • ensuring memory writes have settlement, replay, court, and lineage receipts;
  • detecting loops that appeared healthy but were not producing new memory cells;
  • keeping many applications aligned with one canonical engine;
  • avoiding fake “agents are thinking” animations or simulated proof;
  • handling provider timeouts and degraded services without hiding failure;
  • keeping data durable across deployments; and
  • making a complex proof system understandable to a normal user.

One of the most important lessons was that "enabled" is not the same as "working". A route can return 200, a worker can exist, and a database can be connected while the actual learning loop remains stalled. The meaningful evidence is whether receipts are fresh, high-watermarks move, outcomes settle, replay succeeds, and a governed memory birth actually occurs.

Accomplishments I am proud of

I consider this project a great personal accomplishment and I can say that I am proud of it in its entirety.

I am proud that a small decision card became a working multi-application system in roughly one month of solo work.

The project now has:

  • a live public interface;
  • a conversational Ask KELLY experience;
  • specialized domain labs;
  • a read-only transparency console;
  • evidence, uncertainty, settlement, and replay contracts;
  • governed memory and lineage paths;
  • explicit public write boundaries;
  • tests that reject unsupported or fabricated evidence; and
  • a Git-based workflow that allowed multiple AI agents to contribute without becoming independent authorities.

I also have to say I am proud of the discipline connecting the components. That reality is treated as ground truth, important outputs require evidence, and KELLY cannot silently promote an answer into durable memory simply because a model produced it.

What I learned

I learned that useful AI systems depend on much more than model output. They require authority, provenance, uncertainty, observability, recovery, calibration, and durable memory.

I also learned that someone without a traditional software background can direct a substantial engineering project when AI coding agents are given clear boundaries and continuously checked against executable evidence.

Codex accelerated the implementation, but it did not replace product judgment. My role was to decide what the system should be, recognize when its behavior did not match that definition, force ambiguous claims into testable contracts, and keep the build grounded in reality.

I have learned a tremendous amount and I am still learning more each day as I continue cto construct this project.

The operating principle remained consistent:

Evidence first - Proof over claims - Public access as a lens, never a write path.

What's next for KELLY / Causalea

The architecture is now in hardening mode rather than feature-expansion mode.

The next work is to continue improving runtime reliability, deployment parity, memory-loop continuity, long-term calibration evidence, independent evaluation, and the clarity of Glass Lab’s public audit experience.

The long-term goal is straightforward: let people ask difficult questions and receive more than an answer. Show them the evidence, uncertainty, assumptions, falsifiers, settlement status, and proof trail needed to judge that answer for themselves.

Built With

Share this project:

Updates