Trust and safety

This page covers what Valor may do on his own accounts, how a task is stopped and corrected, what leaves Valor's machines, and how a new limit is added. Each section links to the detail on Alignment and Rules.

Authority

Accounts, effects and the ceiling

Valor acts as himself on his own accounts: his own email, GitHub and chat accounts. He never acts as Tom, who built Valor and runs Yudame, and holds none of Tom's accounts.

The kernel, Valor's deterministic core outside the model, holds the credentials, and one broker performs every effect made with them. Each effect has a class:

read: no effect.
propose: reversible, such as a branch or a draft.
act: irreversible, such as a merge, a send, a payment or a deploy.

Every task has a ceiling, the highest effect class it may use. A child task's ceiling is never above its parent's, and the broker refuses anything above it. Inside the ceiling nothing waits for Tom's approval, and every act that leaves is reported to him. Spending is metered and shown, and never stops a task. Effect classes and ceilings

A turn runs as the machine's user, so an account reached through the keychain or a logged-in session acts outside the broker, the ceiling, the stop and the ledger. Tom has accepted this. Known limits

Source: docs/mission.md · docs/architecture.md, Effect classes · core/broker.py · docs/architecture.md, Limits

Corrigibility

Stop and correction

Corrigible means capable of being corrected. An agent's incentive to allow shutdown is fragile, so Valor doesn't depend on the model wanting to be stopped or corrected. Both live in kernel code.

A stop writes one row to the ledger, the append-only record of everything Valor does. By reading that row, the gateway refuses every later model call and the broker refuses every later effect, for the task and every task under it. The turn's processes are then killed. An effect already sent can't be called back. How stopping a task works

A correction from Tom is a numbered ledger row with who gave it, how and when. Every turn renders the corrections in force as it starts, so one given now reaches tasks already running. The persona asks Valor to comply first and never argue a standing correction again. How corrections reach running tasks

Source: README.md, What corrigible means here · docs/architecture.md, Stop · core/corrections.py · docs/persona.md, Take correction

Data

What leaves Valor's machines

Valor's record of his work stays in Postgres on his own machines: who asked for what, what was done, what it cost and what Tom corrected. Some of the work leaves:

Each model call goes to the model provider, Anthropic by default, through the kernel's gateway, which records it.
Classification calls, such as triaging a request, go to Jev, a hosted model, with an open-weight model on OpenRouter as the fallback.
Messages pass through Telegram, Slack and email, and code goes to GitHub.

This means the model provider sees every prompt it answers.

Source: docs/data.md · docs/tech-stack.md

Governance

How a new limit is added

A new check, gate or denial (a guard) must name the mission item it serves and an incident that already happened without it, and needs Tom's grant in the plan file that adds it. A bug fix never adds one. Each guard is ledgered with a ninety-day expiry; one that never fired is listed for Tom and deleted unless he keeps it. Six guards are in force. The governance paragraph

Source: CLAUDE.md · core/guards.py

Pages in this section

Philosophy: the mission and the question every mechanism is judged against.
Alignment: stop, bounds, corrections, self-improvement and known limits in detail.
Rules: the governance paragraph and the ten hard rules, word for word.

NextPhilosophy →