feat(mandate): namespace constraint types, gated behind schema 1.2

[Levaj2000]

The last open item from the Verifiable Intent review. A mandate could express exactly one bound, spend_limit, as a bare field with no type discriminator, so adding a second kind was never a one-line change: there was nothing to dispatch on, and every consumer would have had to infer a bound's kind from which keys happened to be present.

The namespace

MandateDocument.constraints carries Constraint entries with a dotted type of at least two segments. Two segments is what makes it a namespace rather than a bare word: spend.ceiling and someone else's budget.ceiling do not collide on the unqualified noun. Types from our vocabulary, a standards body's, and a counterparty's can coexist without anyone winning a naming argument first.

Unknown types are rejected at parse, not skipped. Same rule already applied to unknown top-level fields (#531) and unevaluated conditions (#532), and the same one argued upstream in ocsf#1756.

A registered type with no evaluator behind it denies at spend time under mandate_constraint_unevaluable. Naming a type is a promise to evaluate it, and a registry longer than the evaluator is how a vocabulary starts lying about what it enforces. The registry is deliberately narrow for that reason.

The ceiling stays on spend_limit: registered in the vocabulary, refused inside constraints[]. One bound with two encodings is how the two end up disagreeing.

The risk was the signature, not the vocabulary

constraints sits inside the signed payload. Adding it naively would have given every re-serialized 1.0 and 1.1 document an empty list it was never signed over, and every mandate ever issued would have stopped verifying.

_POST_1_1_FIELDS strips it below schema 1.2, extending the gate _POST_1_0_FIELDS already established when spend_limit was added. Default schema_version moves to 1.2.

Document version	constraints in signable bytes
1.0	stripped
1.1	stripped
1.2	present, so the bounds are covered

Both directions are pinned. Absent for old versions, or old signatures break. Present for 1.2, or the namespace is decorative and a constraint could be added or dropped without disturbing the signature.

Tests

Thirteen new. The two parametrized compatibility cases are the ones that earn their place: I removed the version gate and re-ran to confirm both go red, then restored it and confirmed green.

One checks that a constraint added after signing fails verification. It is built with model_construct rather than the normal constructor, because an attacker editing a stored document does not pass through our validator. That also makes the point that the signature, not the parser, is what has to catch it.

Check	Result
Mandate suite	81 passed, 6 skipped
Gateway mandate tests	21 passed
ruff check / ruff format --check	clean

Scope

This lands the vocabulary and the container, not a catalogue of implemented types. EVALUABLE_TYPES is empty on purpose: the next constraint type is now an additive change with a place to go, which was the entire objective.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XyU3PRkgvMxgimkPBC5726

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ai-identity-landing	Ready	Preview	Sep 11, 2026 3:15pm UTC
dashboard	Ready	Preview	Sep 11, 2026 3:15pm UTC