SignalRoom AI

• 

  Territory Central: 94% CRM execution, yet SignalRoom flags a decision-coherence gap requiring investigation.

• 

• 

Inspiration

I spent nearly twenty years working in pharmaceutical field operations.

One thing I learned over that time is that a CRM can record activity correctly and still support the wrong managerial conclusion.

A territory may show high activity completion while the reality on the ground has already changed. HCP access may have become more difficult. A channel may no longer be working as expected. Travel and operational friction may have increased. Competitors may be gaining momentum. A strategic project may look active on paper but have become much harder to execute.

In those situations, the problem is not necessarily execution.

Sometimes the recorded activity, the commercial plan, and the reality of the territory simply stop telling the same story.

That is the problem I wanted SignalRoom AI to explore.

What it does

SignalRoom AI is a proposed Reality Layer for Decision Intelligence.

It is not intended to replace a CRM, an account-planning system, a project-management tool, or the manager.

Its purpose is narrower:

Do recorded execution, field reality, market conditions, operational constraints, strategic priorities, and project status still form a coherent basis for a decision?

The competition demo follows an Area Manager reviewing three synthetic territories.

Territory Central contains the main counterintuitive case:

94% CRM execution — and yet the territory still requires investigation.

Instead of jumping immediately to a cause, SignalRoom compares several possible explanations and separates them into four epistemic states:

• OBSERVED — directly supported by available evidence;
• INFERRED — a reasonable interpretation, but not a demonstrated fact;
• UNKNOWN — something the available evidence cannot establish;
• ACTION — a proposed next step that still requires a human decision.

The application also includes an Epistemic Firewall. Its role is simple: a statement cannot be presented as an observed fact unless the evidence supporting it is actually present and structurally consistent with the claim.

SignalRoom also:

• contextualizes field execution without automatically scoring or blaming employees;
• distinguishes nominal project progress from real-world project viability;
• highlights a Priority–Reality Gap when strategic priorities exceed practical field capacity;
• compares alternative explanatory hypotheses;
• changes its recommendation when the operational situation changes;
• keeps the final decision with the manager.

One of the demo interactions changes HCP availability from Tuesday to Thursday.

The recommendation changes because the field conditions changed — not because an AI simply generated a different opinion.

All data used in the competition demo are synthetic.

How I built it

I built SignalRoom AI as a non-developer domain expert using Codex with GPT-5.6.

This was my first substantial software project built with Codex.

In roughly seven hours, I went from a domain problem shaped by nearly twenty years of pharmaceutical field experience to a tested, deployed software product.

I did not bring software-engineering expertise to the project. I brought the problem: the operational constraints, the managerial edge cases, the situations in which a seemingly correct KPI can lead to the wrong interpretation, and the decisions about what the product should and should not conclude.

Codex with GPT-5.6 helped me turn those requirements into working software through:

• requirements decomposition;
• application architecture;
• deterministic decision logic;
• Epistemic Firewall design;
• adversarial review of assumptions;
• TypeScript implementation;
• automated tests;
• debugging;
• UX iteration;
• production build and deployment.

The project evolved through four stable engineering checkpoints:

• 590c290 — Technical Baseline v1
• 8608691 — Competitive MVP v2
• 3a19479 — Final MVP v3
• 426deec — Final product checkpoint v3.1

The final application uses:

• Next.js
• TypeScript
• Tailwind CSS
• local synthetic JSON
• deterministic decision logic
• Vitest
• Vercel

The final test suite passes 25/25 deterministic tests.

The deployed competition version intentionally does not call the OpenAI API at runtime.

That was a deliberate product decision. The core diagnostic logic is deterministic: given the same evidence, it reaches the same assessment. GPT-5.6 was used through Codex throughout the development and engineering process rather than being added as a generative layer simply for the sake of having an AI call inside the demo.

Challenges I ran into

The hardest challenge was not building the interface.

It was deciding what the system had the right to say.

This is particularly important in a management context.

High CRM execution combined with weak sales does not prove that a field representative is performing poorly.

Rising competitor pressure may be relevant, but it does not automatically prove causation.

A strategic project that is reported as 70% complete is not necessarily 70% viable.

Those distinctions led to the Epistemic Firewall and to the explicit separation between:

• what the evidence directly supports;
• what can reasonably be inferred;
• what remains unknown;
• what still requires human judgment.

The other major challenge was scope.

SignalRoom could easily have expanded into a CRM, a route planner, a market-intelligence platform, a project-management system, or an employee-scoring tool.

I deliberately kept those functions outside the competition MVP.

I wanted to test one idea properly:

Can we check the coherence of a managerial decision before we start attributing causes or reallocating priorities?

Accomplishments that I'm proud of

I am proud that SignalRoom became more than a generated interface.

The final competition version includes:

• a deterministic decision engine;
• evidence-aware hypothesis assessment;
• a structurally verifiable Epistemic Firewall;
• Team Reality without employee ranking;
• Strategic Project Reality;
• a Priority–Reality Gap;
• a deterministic Manager Brief;
• an interactive field-reality scenario;
• 25 passing tests;
• a production deployment.

I am also proud that the project started from a problem I actually knew rather than from a technology looking for a use case.

For me, that distinction matters.

What I learned

The biggest lesson was that AI-assisted software development can allow a domain expert to express knowledge that previously existed mainly as professional intuition.

I knew the situations I wanted to represent.

What I did not know was how to turn them into software architecture, functions, tests, state changes, and a deployed application.

Codex helped bridge that gap.

Codex did not give me twenty years of pharmaceutical field experience.

It gave those twenty years a software interface.

I also learned something else while building SignalRoom: responsible decision intelligence is not only about producing more recommendations.

Sometimes the most useful output a system can give a manager is simply:

The available evidence does not establish that.

What's next for SignalRoom AI

The competition version is deliberately narrow and uses only synthetic data.

A future version could evaluate decision coherence across sources such as:

• CRM and other system-of-record signals;
• market intelligence;
• operational and mobility context;
• structured field observations;
• portfolio priorities;
• strategic-account initiatives.

It could also work across different decision horizons: daily, weekly, monthly, quarterly, six-month, rolling-12-month, and year-over-year.

The long-term idea is not to replace field teams or managers with an automated decision-maker.

It is to give them a more coherent representation of what is actually happening before they make a decision.

Field teams contribute reality. SignalRoom structures the evidence. Managers decide.

Built With

• codex
• css
• github
• gpt-5.6
• next.js
• react
• tailwind
• typescript
• vercel
• vitest