Soft / routing / verifiable

Not every rule should live in the AI’s context. There are three kinds, and each one needs a different enforcement surface. Putting the wrong type in the wrong place is the most common reason “I added a rule and it still fails.”

Three types: soft guidance (persona, tone, works in context), process routing (skill triggers, action classification, platform orchestration), and verifiable rules (checkable output criteria, output validation). See the canonical table and annotations in wiki/concepts/constraint-taxonomy.md.

Why type decides the surface

Soft guidance works in context because it biases token prediction in a direction the model can hold throughout generation. It never has to detect a precise moment. “Lead with the answer” shifts the whole distribution.

Routing and verifiable rules fail in context because they need a deterministic checkpoint (did this message trigger a skill?, does this output contain the required field?) and a model under task pressure doesn’t reliably self-gate. They’re enforced better by code that runs before or after the model, where the check can actually fire (and retry on failure).

How MemMini routes them

You annotate each rule in the source file; the compile step routes by annotation:

• soft → CONTEXT.md, injected into the model
• routing + verifiable → ENFORCEMENT.md, consumed by your platform’s orchestration or validation layer

On a platform with no orchestration layer, ENFORCEMENT.md is concatenated as a fallback, with the known caveat that in-context compliance on those rule types is low. The annotation is the contract between your source files and whatever enforces them.

Symptoms of misplacement

• Added a rule, still fails → it’s probably routing/verifiable sitting in context. Move it to enforcement.
• Removed a rule, nothing changed → it was already enforced elsewhere; the context copy was decoration.
• More detail made it worse → see Why context rots.

Go deeper

Canonical node, with worked examples: wiki/concepts/constraint-taxonomy.md.