Decision Receipt
Next Best Action/ How to negotiate
Technical Trace
Evidence

Inspiration

As we brainstormed ideas for the Build Week Hackathon, we started with a simple question: What is today's AI still missing?

Every AI demo seems to begin with someone asking a question. Very few stop to ask whether it was the right question to begin with.

The more we explored it, the more we realized that many important decisions fail long before anyone asks for an answer. They fail because the evidence is incomplete, assumptions go unchallenged, or the real decision hasn't been identified yet.

That led us to a different question: What would it take for a recommendation to deserve someone's trust?

That question became askTARS.

We believe decisions are not simply made. They emerge as evidence is gathered, verified, challenged, and revised. Instead of rushing to an answer, askTARS helps people arrive at a decision they can understand, defend, and improve.

What it does

askTARS is a diagnosis-first decision engine.

Rather than immediately answering a question, askTARS first diagnoses the decision that actually needs to be made. It gathers information from documents, conversations, and trusted sources, separates verified claims from assumptions, and refines its understanding as new evidence arrives.

Every recommendation is accompanied by a Decision Receipt that shows:

what askTARS knows
how each claim was verified
what assumptions remain
the calculations behind the recommendation
why it reached its conclusion
what information would change the outcome

For Build Week, we demonstrate the approach using a vehicle purchase-versus-lease decision. The user photographs a dealer worksheet, askTARS extracts the offer, verifies key financial details, identifies information it cannot confirm, and demonstrates how changing the expected ownership horizon from 72 months to 36 months flips the recommendation, along with exactly why.

Although the demo focuses on automotive decisions, the underlying reasoning framework is designed to support any domain where evidence, tradeoffs, and uncertainty matter.

How we built it

We deliberately separated language understanding from decision execution.

Language models interpret documents, understand natural language, identify ambiguity, and propose diagnostic hypotheses.

Deterministic services verify claims, perform every financial calculation, apply business rules, preserve provenance, and produce reproducible recommendations. No financial calculation shown to the user comes from model-generated arithmetic.

Rather than treating conversations as disposable text, askTARS maintains a structured decision state consisting of claims, evidence, provenance, assumptions, and assessments that evolve as new information arrives.

The automotive demonstration is implemented as a thin domain module on top of a domain-neutral reasoning framework.

OpenAI models were used throughout the project:

GPT-5.6 SOL for product design, architecture, and implementation planning
TERRA for software development, debugging, testing, and iterative implementation
LUNA for documentation, Git workflows, project management, and supporting engineering tasks

Challenges we ran into

The hardest challenge was architectural. We had to decide what the language model should do, what should remain deterministic, and what information had to be verified before it could influence a recommendation.

Those decisions shaped the architecture far more than any individual feature.

We also ran into a practical engineering challenge. During long implementation sessions, Codex occasionally drifted from the original design and requirements. Thorough code reviews and architectural reviews became essential for catching regressions and keeping the implementation aligned with the intended behavior.

Accomplishments that we're proud of

We're proud that askTARS produces recommendations that evolve as evidence changes rather than treating them as fixed answers.

We're proud that every recommendation can be inspected through a Decision Receipt, making the reasoning, supporting evidence, assumptions, and calculations fully reproducible.

We're proud that the domain-specific automotive logic is implemented as a thin layer over a reusable reasoning framework designed for many different kinds of decisions.

What we learned

We expected document extraction to be the hardest part of the project. It wasn't.

The hardest part was deciding which responsibilities belonged to the language model and which belonged to deterministic software.

Once those responsibilities became clear, the system became easier to reason about, easier to debug, and ultimately easier to trust.

We also learned that simplifying the product made it stronger. As we removed features and focused on a single decision, the underlying architecture became much easier to understand.

What's next for askTARS

The vehicle demonstration is only the beginning.

Our long-term vision is a reasoning framework that helps people, and eventually autonomous agents, navigate complex decisions across many domains.

Future work includes richer evidence gathering, reusable decision playbooks, long-lived Decision Streams that connect related decisions over time, collaborative multi-agent reasoning, and a growing library of reusable decision intelligence.

Our goal isn't to build another assistant.

It's to build systems that earn every recommendation.