Decide the next step, and replay the decision that was recorded

The chapter separates three things that often get merged: which operation comes next, whether to escalate to a person, and which selector answers. The scheduler here is a deterministic policy over an explicit state, and the run’s last part is the part that matters: the decision that was recorded is replayed, and the facts it rested on are shown.

Run it

git clone https://github.com/ernanhughes/codeai.git
cd codeai
git checkout c1707f793abbd6042dce7d00b6dde34f2dbf33cc
PYTHONPATH=src python examples/applied_ai/ch28_scheduler.py

CodeAI has no runtime dependencies, so nothing needs installing. Python 3.11 or later. No model is called and nothing leaves the machine.

Expected outcome

The same task state, under two policies, reaches different places:

1 nothing proposed  [t-gated ]: CALL      <- proposals=0 check_owed=False accept_grant=False complete=False
1 nothing proposed  [t-full  ]: CALL      <- proposals=0 check_owed=False accept_grant=True complete=False
2 candidate exists  [t-gated ]: CHECK     <- proposals=1 check_owed=True accept_grant=False complete=False
2 candidate exists  [t-full  ]: CHECK     <- proposals=1 check_owed=True accept_grant=True complete=False
3 check passed      [t-gated ]: ASK_HUMAN <- proposals=1 check_owed=False accept_grant=False complete=False
3 check passed      [t-full  ]: STOP      <- proposals=1 check_owed=False accept_grant=True complete=False

After acceptance the two policies separate completely — the gated policy still asks a person, and the full policy completes:

acceptance [t-gated ]: refused (acceptance_not_granted:review-gated)
acceptance [t-full  ]: completed
4 after acceptance  [t-gated ]: ASK_HUMAN <- proposals=1 check_owed=False accept_grant=False complete=False
4 after acceptance  [t-full  ]: STOP      <- proposals=1 check_owed=False accept_grant=True complete=True

And the replay is the part with teeth: reprojecting the task now says STOP, but replaying the recorded decision says CHECK, and the run shows what that decision rested on:

decision 2 as recorded : CHECK
reprojecting the task  : STOP
replaying decision 2   : CHECK (policy epistemic-v3)
facts it rested on     : sha256 7954c184c63b, 3 events

The policy is explicit state, not a guess

The scheduler’s inputs are the state of the process, and its output is a typed decision with a reason for each axis. The two policies in the run are accept_grant false and true, and the difference is one declared flag.

The replay rule is the important part: a decision is replayed against the policy version and the facts it was made from, not against whatever the state happens to be now. Reprojecting the task is a different question from replaying a decision, and the run keeps them apart.

Mechanism and limitations

Documented: the decision procedure is decide_next_step and its POLICY_VERSION in src/codeai/scheduler.py; the policy state is src/codeai/process_state.py; the example is examples/applied_ai/ch28_scheduler.py.

Observed: the run above. Four states, two policies, and the same recorded decision replayed to CHECK while a fresh reprojection of the same task said STOP. The replay reported the policy version it was replayed under and a fingerprint of the three events the decision rested on.

Not shown. The scheduler here is a deterministic policy over an explicit state; the chapter’s open question is whether a model-based router would choose better, and that experiment is not run here — the falsifier is that the deterministic bet must not be displaced. The ladder, the spend calculation and the declared prices are policy, not measurement. The fact fingerprint is an integrity marker over the recorded events, not proof that they describe the world.

Canonical source and the CodeAI scheduler .