Module builtin 

Source 1: policies compiled into the binary, immutable.

plan/policy.md: “Things unsafe to admit into public existence. An application that does not want agents using it opens a pull request against didbot asking to be denied as a client; that denial ships in the binary.” This is where that PR lands: builtin_policies returns a fixed Vec, and the only way to change what it contains is to edit floor/ and ship a new build. There is no config path, no record, no admin surface that can add to or remove from this list at runtime – that is the whole point of “immutable.”

A built-in applies to every account on every deployment and cannot be turned off. So it is only for a rule no operator would ever want an agent to break. Anything an operator might reasonably want differently is the operator’s own record.

A built-in is a record

Each one is the bot.did.policy record an operator would write, kept in floor/ beside this crate and read at startup by the same crate::records reader, split into statements by the same crate::set::declarations, and compiled by the same crate::compile against the same engines. So a built-in can be copied into an operator’s repository unchanged, the refusal an agent reads is the statement’s own reason, it reports on a dashboard the way an operator’s record does, and a change to an engine that breaks a built-in breaks this crate’s tests rather than a deployment. floor/README.md says what each one is for and where its numbers come from, and builtin_records hands the records out for a dashboard or a test to read.

What a built-in gets that an operator’s record does not is its applicability: a record from the operator is routed to every write and filters on the collection inside the evaluator, while a built-in names the exact collections it reaches, so a write anywhere else never pays for it. That is plan/policy.md’s “a policy gating common writes should be cheap and in-process”, applied to rules every write on every server would otherwise consult. A built-in that reaches every collection, such as a client denial, says so with Scope::Any.

Structs

Builtin 🔒

One built-in: its record as written, the collections it reaches, and how stale its evaluator’s view may be.

BuiltinPolicy

One statement of one policy compiled into the binary, under the id a report calls it by: builtin/{name}/{statement}/{action}, the same {key}/{statement}/{action} shape an operator’s record is registered under, with the source in place of a record key.

Constants

BUILTIN_REVISION

A builtin’s nominal revision: 0, always. A builtin is not an observation of anything – it ships with the binary and has no author writing successive edits for didbot_policy::Revision to order, so there is nothing for this value to compare against. It exists only because didbot_policy::PolicyDeclaration always carries one, for plan/policy.md’s “record which policy version admitted each write”.

DECLARED_AI_PREFERENCE

The floor rule that honours a declared AI preference. See plan/ai-preference.md.

WRITTEN_AT 🔒

The createdAt a built-in’s record carries when its file leaves it out, the way the recommended catalogue’s files do.

Functions

builtin 🔒

The built-in record is, reaching collections.

builtin_policies

Every policy this build ships compiled in. Fixed at compile time – see this module’s doc comment.

builtin_records

Every built-in, as the bot.did.policy record it is written as.

builtins 🔒

The built-ins this binary ships. See ships_exactly_these_builtins for the list as a reviewer reads it, and floor/README.md for what each one is for.

loaded 🔒

builtins, plus the records this crate’s own tests exercise the machinery with. Those records exist only in the test build.

narrow 🔒

Narrows a write’s applicability to the collections a built-in reaches, so the tree routes it nowhere else. Leaves every other subject shape alone: a client denial at sign-in has no collection to narrow.

record 🔒

The record source holds.