The problem worth investigating
A single answer style is weak. Definitions, tutorials, interviews and debugging benefit from different response policies.
This innovation is treated as a falsifiable engineering hypothesis. The goal is not to prove that an advanced technique is impressive; it is to determine whether it produces a measurable improvement over a simpler control.
Experimental architecture
- 01State encoder
Instrumented independently so the experiment can reveal which stage contributes value. - 02Action catalog
Instrumented independently so the experiment can reveal which stage contributes value. - 03Policy statistics
Instrumented independently so the experiment can reveal which stage contributes value. - 04Exploration controller
Instrumented independently so the experiment can reveal which stage contributes value. - 05Reward collector
Instrumented independently so the experiment can reveal which stage contributes value. - 06TD update
Instrumented independently so the experiment can reveal which stage contributes value.
Algorithms under study
Markov decision process
Hypothesis. Provides a formal way to model state, action, transition and reward for sequential decisions.
Risk. The Markov assumption and state design can be unrealistic if important history is omitted.
Evidence. Policy value, transition coverage and state-ablation performance.
Q-learning
Hypothesis. Learns action values from reward without requiring a model of environment transitions.
Risk. Reward design, exploration and state representation can cause unstable or misleading policies.
Evidence. Average reward, policy stability, regret and action-level helpfulness.
Epsilon-style exploration
Hypothesis. Epsilon-style exploration is included because it addresses a specific measurable part of the system rather than being added as decoration.
Risk. The component must be compared with a simpler baseline and removed if it adds complexity without measurable value.
Evidence. Task-specific quality metric, latency, reliability and failure-case analysis.
Reward shaping
Hypothesis. Reward shaping is included because it addresses a specific measurable part of the system rather than being added as decoration.
Risk. The component must be compared with a simpler baseline and removed if it adds complexity without measurable value.
Evidence. Task-specific quality metric, latency, reliability and failure-case analysis.
What data the experiment needs
- Intent — recorded with enough context to reproduce and audit the result.
- Complexity — recorded with enough context to reproduce and audit the result.
- Confidence — recorded with enough context to reproduce and audit the result.
- Feedback — recorded with enough context to reproduce and audit the result.
- Action history — recorded with enough context to reproduce and audit the result.
How CortexLab decides whether the idea survives
- Average feedback reward
- Policy stability
- Action diversity
- Per-intent helpfulness
Results should be compared against a control, segmented for failure cases and repeated across enough observations to avoid promoting noise into product behavior.
What can go wrong
Wrong reward
Optimization can improve the metric while making the actual experience worse.
Overconfidence
Small or biased samples can make experimental gains look more certain than they are.
Distribution shift
A policy that works on past users may degrade as topics, traffic and behavior change.
Next research milestones
- 01Contextual bandits
- 02Offline policy replay
- 03Eligibility traces
- 04Long-horizon session rewards
Questions still open
- Which simpler baseline must this beat before deployment?
- How should uncertainty be calibrated and communicated?
- What evidence would make us reject the idea?
- How do we prevent reward hacking or accidental optimization of engagement alone?
- Which decisions must remain human-reviewed?