A reading is a decision, and only a person settles it
See a requirement go from INCONCLUSIVE to PASS or FAIL depending on which reading of 'executed' a person settled, and watch a proposal fail to unseat that decision.
Between ordinary language and executable state there are several kinds of representation, and the chapter’s point is not that one is better but that moving down the ladder forces choices the reader cannot avoid. This example covers the part that can be enforced: a word’s reading is a declared decision bound to the words that prompted it, checks run only on what a person has settled, and an option’s name cannot be allowed to override its definition.
Run it
git clone https://github.com/ernanhughes/project-language.git
cd project-language
git checkout 329660f679a5a87831f91fe1430c20ac9360dda8
npm ci
npm run example:ch11No model is called. The job-queue trace is constructed, and the selector used in the last probe is a deliberately defective simulation, not a model.
Expected outcome
Until a person settles the reading, the check is INCONCLUSIVE — never a pass:
...
R1: INCONCLUSIVE not checked: executed not settled by a person
R1 with a model's proposal on file: INCONCLUSIVE (a proposal is not a decision)
R2 (depends on no reading): PASSThe same requirement then passes or fails depending on which reading is settled, and the run says what that means:
...
attempt FAIL executed more than once, reading "executed" as attempt: J1 (2), J3 (2)
completed job PASS every job executed at most once, reading "executed" as completed
external effect FAIL executed more than once, reading "executed" as effect: J1 (2)A later proposal does not unseat the decision, and a confirmation belongs to the reading it was given for:
...
person settled "effect", then a model proposed "completed": in force = effect (settled)
confirmed for the "completed" reading: confirmed
after the reading changed to "effect": unasked (stale: your earlier answer was about a different reading)Only a person settles
A model may propose a reading. It may not settle one, and it may not confirm that a translation kept the person’s intent:
/** Anyone may propose a reading. The proposal carries the binding it was made against. */
export function propose(d: Decision, optionId: string, by: Actor, reason?: string): Resolution {
return { decision_id: d.id, option_id: optionId, status: "proposed", by, binding_sha256: bindingHash(d, optionId), ...(reason ? { reason } : {}) };
}
/** Only a person settles a reading. */
export function settle(d: Decision, optionId: string, by: Actor, reason: string): Resolution {
if (by.type !== "human") throw new LadderError("NOT_A_PERSON", `only a person settles an interpretation; got ${by.type}`);
if (reason.trim() === "") throw new LadderError("NO_REASON", "settling needs a reason");
return { decision_id: d.id, option_id: optionId, status: "settled", by, binding_sha256: bindingHash(d, optionId), reason };
}And the resolution in force is the latest, except that a proposal never unseats a settled or deferred decision:
export function inForce(d: Decision, history: readonly Resolution[]): { resolution?: Resolution; stale: boolean } {
// Walk the history in order. A person's settling or deferring stays in force against any later PROPOSAL (a model asking
// again, or suggesting another reading): a proposal is not a decision and must not unseat one. Only another settle or
// defer replaces it. A proposal does replace an earlier proposal, and stands when nothing has been decided.
let latest: Resolution | undefined;
for (const r of history) {
if (r.decision_id !== d.id) continue;
if (r.status === "proposed" && latest && latest.status !== "proposed") continue;
latest = r;
}
if (!latest) return { stale: false };
if (latest.option_id && latest.binding_sha256 !== bindingHash(d, latest.option_id)) return { stale: true };
return { resolution: latest, stale: false };
}The check itself refuses to answer when the reading is open:
export function check<Trace>(req: Requirement<Trace>, trace: Trace, decisions: readonly Decision[], history: readonly Resolution[]): CheckResult {
const chosen: Record<string, string> = {};
const blocked: string[] = [];
let stale = false;
for (const id of req.depends_on) {
const d = decisions.find((x) => x.id === id);
if (!d) {
blocked.push(id);
continue;
}
const { resolution, stale: s } = inForce(d, history);
stale ||= s;
if (resolution?.status === "settled" && resolution.option_id) chosen[id] = resolution.option_id;
else blocked.push(id);
}
if (blocked.length > 0) {
return {
requirement: req.id,
verdict: "INCONCLUSIVE",
reason: stale ? "STALE_BINDING" : "UNSETTLED_INTERPRETATION",
readings: chosen,
blocked_on: blocked,
detail: `not checked: ${blocked.join(", ")} not settled by a person`,
};
}
const r = req.holds(trace, chosen);
return { requirement: req.id, verdict: r.ok ? "PASS" : "FAIL", reason: "CHECKED", readings: chosen, blocked_on: [], detail: r.detail };
}Mechanism and limitations
Documented: the four enforceable rules are listed in the header comment of
core/ladder/src/index.ts, together with the separations the module refuses to
collapse: intent preservation, checkability and implementation conformance are
not the same thing, and neither is type conformance or semantic correctness.
Observed: the run above. R1 was INCONCLUSIVE with no history and still INCONCLUSIVE with only a model’s proposal; R2, which depends on no reading, passed. Under “completed job” the requirement passed while the customer was charged twice; under “attempt” it failed. A person’s settlement survived a later model proposal, and a confirmation recorded for one reading was reported as unasked and stale once the reading changed.
Not shown. The chapter’s own questions are not answered here. Nothing ranks the rungs of the ladder, and the six-axis comparison is not implemented. The reported finding about option names comes from a probe run only against a deliberately defective simulated selector: it shows the probe works, not what any real model does. Translation relations are caller-supplied, and a person can rubber-stamp the wrong meaning. Whether people find the mediation worth the labour is the chapter’s open question and is untested.
Understand this example
Copy this prompt into your AI tool. No code runs here.
Apply this example
Copy this prompt into your AI tool. No code runs here.