The Ascent: One Evaluation Cycle

Each evaluation cycle is called The Ascent. The name remains from the original training era, but the current meaning is broader: every cycle tests whether a component deserves authority, whether a governor improves a deterministic control, and whether a claim belongs in Canon.

This page walks through the public mechanics. It intentionally omits implementation details that would expose private construction, thresholds, prompts, or execution logic.

Stage 1 — Market State

The cycle begins with a sanitized market-state packet. The packet contains only the inputs needed by the relevant subsystem and preserves the no-lookahead boundary. The public architecture describes the separation of powers, not the private feature recipes.

Stage 2 — Engine Output

Deterministic engines generate auditable target outputs. These outputs are recorded before any governing layer modifies, sizes, vetoes, or contextualizes them.

The active architecture treats engines as the trading substrate. The LLM tribunal must be compared against that substrate, not credited for changes that could have been made by code.

Stage 3 — Governance Pass

The King, Prophet, and Sentinel receive only the authority their role allows:

The King considers allocation and sizing intent.
The Prophet provides verified context and structured counsel.
The Sentinel reports regime and capital-danger posture.

A governor does not win by sounding convincing. It wins only if the recorded result improves against the deterministic control on the same decision rows.

Stage 4 — Action or No Action

The executor converts approved intent into final action under risk constraints. It may also withhold action. Execution authority is deliberately separated from signal generation and model reasoning so each layer can be audited independently.

Stage 5 — Result Ledger

After the decision window, the outcome is recorded. The system keeps separate fields for raw engine target, governor recommendation, final executor action, and realized result.

This separation prevents attribution errors. If a model changed a decision, the ledger can evaluate that change directly. If code would have made the same decision, the model does not receive unearned credit.

Stage 6 — Canon Update

The Prophet may propose a claim. The Scribe can turn that claim into a verification instrument. Python tests it against the recorded tablets. Only claims that pass become Canon.

Rejected claims are also retained. A failed idea is useful if it prevents the system from spending cycles rediscovering the same failure later.

The Point of the Ascent

The Ascent is not about protecting any single model, subsystem, or story. It is about preserving a process that can replace its own assumptions.

The initial system is dictated by the founder. The final system is forever evolving, shaped by evidence alone.