A profile names a capability class rather than a vendor model

declared status!declared status: advisory Projected into the worker's instructions. Whether a worker honours it is not observable from outside. Documentation, not enforcement.

recorded evidence○recorded evidence: not run Not judged: only a guaranteed claim is held to a recorded run. how evidence is recorded

Mapping a class to a concrete model is left to whoever runs the worker. Majordomus never selects or invokes a model.

grep -h '^capability:' .ai/repo/profiles/*.yaml
grep -rnE 'claude-|gpt-|gemini-' .ai/repo/   # nothing

Detail rendered from docs/claims/capability-class.md.

From the statement to the proof

1. 1 · the public statement

   A profile names a capability class rather than a vendor model

   Made on Policy, Profiles.

2. 2 · the canonical claim

   capability-class!declared status: advisory in docs/CLAIMS.yaml

   Defined in read it on this site · share/skeleton/profiles/deep-work.yaml

3. 3 · the implementation

   lib/update.sh · majordomus update

4. 4 · the test and the scenarios

   Test: test/cases/03_update.sh

5. 5 · the recorded runs

   ○recorded evidence: not run how evidence is recorded

Verify it yourself

The test runs in a disposable temporary repository and asserts the behaviour, not a string in the source.

bash test/run.sh 03_update

Where this claim is used

Related claims same implementation

• ○declared status: guaranteed Provider instruction files are generated from the one policy, deterministically
• ○declared status: guaranteed Every generated instruction file carries its own stamp, and a hand edit is detected
• ○declared status: guaranteed A projection can own only the region between its markers, leaving the rest of the file untouched
• ○declared status: guaranteed A hand-edited instruction file is never silently overwritten
• ○declared status: guaranteed The always-loaded instruction file has a line budget with a failing check
• !declared status: advisory Capability class, reasoning effort, output verbosity, context and verification are five independent axes
• !declared status: advisory Escalating reasoning effort after repeated blocked attempts is recorded rather than assumed
• ○declared status: guaranteed Provider instruction files are thin bootstraps that point at the AI layer and carry no rule of their own

The moments this answers

• → watched the strongest model, at maximum effort, rename a variable Capability, reasoning depth, context size and verbosity collapse into one habit — everything on — because nothing ever named them separately.
• → let a fast, cheap session make a decision the whole codebase now lives with Capability is dialled down for cost and nothing distinguishes the tasks where that is prudent from the ones where it is expensive.
• → could not say why one provider was used for that work and another for this Provider and model selection is made implicitly, per session, and recorded nowhere, so it cannot be reviewed or repeated.