Home > FAQs > The sentinel blank

What is the sentinel blank in OpenCues?

The sentinel blank is the in-editor write surface for your personal data file. Type set sentinel jobTitle Founder _ in any host and the field lands in ~/.cues/IDENTITY.md; remove sentinel jobTitle _ deletes it. It's the one shipped blank whose job is mutation of your own config, which is why it's also the most defended.

What you type

Two trigger phrases, keyword-bound: set sentinel <key> <value> _ to add or update and remove sentinel <key> _ to delete. The blank allows up to 16 words between the keyword and the _, so multi-word values work naturally (set sentinel signOff Best from sunny London _). For an unusually long value, the CLI equivalent (opencues identity set) has no such limit.

Every write passes one validator

All mutations route through a single chokepoint, validateSentinelWrite, which enforces:

Key shape: keys must match [A-Za-z][A-Za-z0-9_-]*, which structurally refuses path traversal and shell metacharacters.
Value shape: control characters are refused, as defence-in-depth against smuggling sequences into YAML or into prompts in raw mode.
Caps: 256 characters per value, 64 fields total (the capacity cap applies to adds, not updates).
Token collision: firstName and first_name both derive to the token [FIRST NAME], so the validator refuses the second rather than letting it silently shadow the first.

Failures paint visibly into your buffer as [err] <detail>, never silently and never as a crash: [err] IDENTITY.md is full — 64/64 fields defined tells you exactly what to do next.

A spec-reserved name, deliberately locked down

The name sentinel is reserved in the open standard's blank spec, with unusually strong MUSTs for conformant runtimes: the trigger is keyword-bound only (no LLM intent classifier may ever route to it), ambient page context (labels, placeholders, aria) must never influence what gets written, and a third-party pack can never silently shadow the name (the built-in registers first). The reasoning is straightforward: a blank that writes to your identity file is the last place you want a hostile web page or a hallucinating classifier to reach. The full threat model is in the repo's security audit.

One design footnote: blanks can opt into exposing their live value as ambient context (as-context:), and the sentinel blank pointedly declares as-context: off. It's the write surface for IDENTITY.md; the read surface is the file's own frontmatter. Exposing the writer as context would be a meaningless self-reference, so it's off by construction.

Where it fits

Writing is half the loop; reading is the other. The fields you store power identity context: my email _ resolves, drafts sign off with your name, and in the default safe mode the values are substituted on your machine after the LLM responds. The sentinel blank just means you can maintain those fields without leaving whatever you were typing.