2. Read the decision🔗

The valid case records a short chain, in this order:

event-1 freezes the protocol: metric synthetic_delta, unit ratio, threshold 0.001, strict comparison, and cost cap 10.00 cpu_s.
event-4 records 0.002 ratio for the same metric and run.
event-5 records 2.50 cpu_s, below the stated cap.
event-6 cites the observation and records pass under the local exact_v0 rule.
event-7 cites that assessment and records the promote decision.

The threshold is strict because the protocol combines direction: "gte" with inclusive: false: 0.002 > 0.001. Slean also checks that references exist and that the assessment and decision do not precede their evidence. pass is the assessment's verdict; promote is a separate decision. A human override needs a reason and does not become a pass.

The 10.00 cpu_s cap applies to this frozen protocol across all its runs. Each recorded cpu_s amount counts, including one with partial coverage. A second run that adds 7.51 cpu_s after the first run's 2.50 cpu_s is rejected as cost_cap_exceeded; another cost unit is recorded without conversion.

You can freeze the reading at the decision itself:

lake exe slean replay examples/valid.json 7

This replay uses only the first seven events. event-8 through event-10 therefore cannot retroactively change that prefix result. The previous chapter's agent view then projects what that audience may see.

A case can be valid but undetermined. Compare the view of the case without a measurement:

lake exe slean view examples/unknown.json agent

Its observation has status: "unknown" and value: null; the decision is defer. null means “no measurement available,” not zero. The technical-error.json case also retains a null value and a deferred decision, with a distinct technical-error status.

Next, read the AND and OR gates to see how recorded dependencies extend the journal without recalculating that decision.