Overview

This checkpoint applies Codewhale’s working mental model to a repository edit: identify the exact provider and model route, the effective authority, the execution boundary, and the evidence behind the claim. It distinguishes tool, test, diagnostic, lifecycle, snapshot, and verifier evidence; keeps unknowns explicit; and extends the same questions to providers, extensions, workers, and persistence. The result is a reusable way to judge a task without treating a label, passing command, or saved record as proof of correctness.

Learning outcomes

A trustworthy Codewhale judgment is the intersection of route, authority, execution boundary, and evidence, not one strong-sounding label.
Tool results, diagnostics, receipts, snapshots, and verifiers answer different questions and cannot substitute for one another.
Unknown capability, absent OS containment, or insufficient verification should narrow the claim rather than be filled with confidence.

Keywords

CodewhaleRouteAuthorityEvidenceVerificationBoundary

The Working Mental Model: Route, Authority, Evidence

Codewhale becomes easier to judge when its route, authority, execution boundary, and evidence are considered as one chain. This checkpoint applies the ideas already established to a small repository edit: identify the model route, follow the Runtime turn, determine which policy layers can narrow the action, identify the actual sandbox or lack of one, and then separate what the resulting records prove from what they merely report. The outcome is a reusable way to inspect a task without treating any single label as a complete explanation.

One edit, four questions

Suppose a developer asks Codewhale to change a configuration value and run the relevant tests. The first question is route: which provider and exact model will receive the request, and are the model’s capabilities known for this route? A hosted model, a compatible gateway, and a local runtime may all use the same terminal harness, but they can differ in context limits, wire protocol, authentication, and auxiliary features. A model name alone does not settle those facts.

The second question is authority: what is the session allowed to do? Plan can inspect the repository and research but cannot mutate files or run shell commands. Work can enter the ordinary action path. Operate may coordinate independent work in the background, but it does not escape the same approval, repository, shell, and sandbox boundaries. Ask, Auto-Review, and Full Access affect how eligible calls are approved; they do not replace mode, typed permissions, repository law, or worker policy.

The third question is execution boundary: what actually contains the action? A native file tool may enforce workspace-aware paths. A shell call may run under macOS Seatbelt, opt-in Linux Bubblewrap, an external backend, or no Codewhale OS wrapper at all. The answer depends on the host and configuration. A logical workspace-write posture is not proof that a native wrapper was selected, just as Full Access is not proof that all operating-system restrictions have disappeared.

The fourth question is evidence: what can be established after the call? A tool result can show that a command settled. A diagnostic can show that a configured checker observed a condition after an edit. A receipt can show a lifecycle state. None of these automatically proves that the change satisfies the developer’s requirement. The operator must keep execution facts, verification facts, and domain judgments separate.

These questions are independent enough to prevent a common mistake. A person may know the route but not the authority, know that a command was allowed but not the sandbox, or see a successful test without knowing whether the intended file was changed. A trustworthy judgment is the intersection of the four, not the strongest-sounding one among them.

Published by DeepMox

FAQ

What are the four parts of Codewhale’s working mental model?

The four parts are route, authority, execution boundary, and evidence: they identify the inference path, permitted action, actual containment, and support for the resulting claim.

What should happen when a Codewhale capability is unknown?

An unknown capability should remain labeled as unknown, so the operator narrows the task or claim, inspects further, asks a person, or stops rather than inferring a guarantee.

How should Codewhale evidence be matched to a claim?

Match the record to the question: use tool results for settled calls, diagnostics for checker observations, events or receipts for lifecycle, snapshots for restoration, and independent verifiers for stronger completion claims.

Previous11 minCodewhale: Permission vs Sandbox

Next11 minCodewhale: Provider Routing Beyond Model Names

Codewhale: Route, Authority, Evidence

The Working Mental Model: Route, Authority, Evidence

One edit, four questions

FAQ